| |||||||||||||
KVM, QEMU, and kernel project managementKVM, QEMU, and kernel project managementPosted Mar 24, 2010 0:19 UTC (Wed) by bronson (subscriber, #4806)In reply to: KVM, QEMU, and kernel project management by drag Parent article: KVM, QEMU, and kernel project management
Great comment Drag.
The reason why Virtualbox and all these other guys (including OpenVZ and Linux-Vserver) are not on every desktop yet is because they all require reading reams of documentation to do even the simplest things.
Why can't a guest be a single file? HW configuration, disk images, etc, all in one large file. Why can't that file be stored anywhere on my filesystem and be opened the way I open all other files?
...$ qemu ~/vms/ie6.kvm
Or even -- gasp -- double click on it.
If I want to clone the guest? cp -r. When the clone boots, the VM notices if it's using a duplicate mac and tells how I can correct it. Why on earth should I have to dig around for virt-clone or equivalent?
If I want to migrate a guest from one machine to another? Shut down the guest, scp guest.img example.com:, fire up the guest on the new computer. There's no need for network daemons or NFS.
Delete a guest? Just rm it! If it's running then its blocks won't be recovered until the file is closed, just like every other file on your filesystem.
Dammit, if I want to run an old copy of Armor Alley, why can't I just scp a single file from a friend and double click on it? Why do I have to click my way through endless guis and google for obscure tools to do any of this?
It's crazy.
Dear qemu/virtualbox/vmware/etc developers, FIRST make the simple stuff simple, THEN add wacky things like COW and live migration, OK? Your tools all feel like they were designed by overcaffeinated VMS dweebs looking for more job security.
Why must libvirt be such a thick shim with such horrible leaky abstractions? Why must it be so difficult to convert a VM from one system to another? Gimp, Photoshop and Inkscape can all share files, why can't KVM, Xen, and Virtualbox? (crazy external conversion procedures don't count of course) And why am I the only person who seems to care?
Today, virtualization on Linux is an absolute mess. If anyone has any explanations for why, I'd love to hear it. (this article hints at one reason of course, but I'm sure there's more to it than what repo stores the userspace code!)
(Log in to post comments)
KVM, QEMU, and kernel project management Posted Mar 24, 2010 2:10 UTC (Wed) by HelloWorld (guest, #56129) [Link]
You're talking out of your ass. Setting up a VM in VirtualBox is pathetically easy, as is exporting it to a single file (go to the file menu, click on "export appliance"), as is opening it ("VirtualBox --startvm foobar" or just use the GUI).
And the reason that VMs are not stored as single files is that that would be a really dumb idea. VirtualBox uses different files for CD images, hard disk images, configuration files and log files, so i can process the configuration file with xmlstarlet, the log files with grep and so on. Grouping files together is what directories are for; stuffing unrelated things in a single file only makes things more complicated than they need to be.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 3:04 UTC (Wed) by bronson (subscriber, #4806) [Link]
If by "setting up" you mean installing from installation ISOs, then setting up VMs is pathetically easy in all Linux VM systems. You'll notice I didn't complain about this.
I didn't know about export appliance. Glad to hear it, that's a step in the right direction. Not sure why "export" is needed at all though. My whole point is that VMs are usually just a bunch of files, so why can't I manipulate them like files? And, can any other system import VirtualBox appliances?
You mention "VirtualBox --startv foobar"... That's exactly what I'm talking about.
Why --startvm? Why not "VirtualBox foobar"? I'm happy if that brings up the console, then I can hit "Start"?
Also, foobar isn't a file and can't be treated like a file. No command-line completion, no scp, etc.
As for the value of keeping the config file and disk images separate... Sure, that's very true, in the data center. How often do desktop users want to process config files with xmlstarlet? Right, never. They're all going to use the GUI anyway, so why not make that simple?
If you're still not convinced, here are the downsides: get the files mixed up or out of sync and the errors are impenetrable. Lose a file and your VM is unusable. And there's no single thing to execute or double-click.
If the VM consists of a single file, it can be copied, checksummed, backed up, launched, downloaded from a web page, etc at will. See the Armor Alley reference above.
I never suggested putting the log files in the VM image. Yes, that would be daft.
Does this make more sense?
KVM, QEMU, and kernel project management Posted Mar 24, 2010 4:06 UTC (Wed) by HelloWorld (guest, #56129) [Link]
No, it still doesn't make any sense. On the one hand, you argue that a desktop user doesn't want to manipulate the configuration file with xmlstarlet. On the other hand, you want to use command-line completion and scp in order to mess around with your VMs. Then you complain that "there's no single thing to execute or double-click", but there is. Launch the Virtualbox GUI and you get a list of your VMs. Double click on the one you want to launch and you're done. It doesn't get easier than that. And given that Virtualbox handles all those files automatically and transparently, how would they ever get lost or out of sync? You're just making up problems that don't exist. All your other points are made moot by the "export appliance" feature, you can easily checksum, download or backup those. And of course an exported VM can be imported on another machine, that's the point.
Using the same file for different things is just a bad idea, since it just makes the file format more complex without a real benefit. Keeping different things separate is the POINT of a file system, and it would be stupid not to use it. And a hard disk image and a configuration file _are_ very different things.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 7:35 UTC (Wed) by Los__D (guest, #15263) [Link]
Are you really that daft, or do you just pretend to be?
scp was an example, as in [insert favorite way to copy files between hosts]. Using it to pretend that bronson was contradicting himself is just lame.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 19:26 UTC (Wed) by bronson (subscriber, #4806) [Link]
I suspect you're intentionally missing the point and just want to argue (hm, that would seem obvious given your very first senctence in this discussion). Still, in the off chance that you're serious, some quick points:
Double-clicking on a file in Dolphin/Thunar/Nautilus == desktop win.
"All your other points are made moot by the export appliance feature."
"And of course an exported VM can be imported on another machine."
"Using the same file for different things is just a bad idea."
KVM, QEMU, and kernel project management Posted Mar 24, 2010 19:53 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
>"And of course an exported VM can be imported on another machine."
>By "system" I meant VMWare, Xen, Virt-Manager, etc. Can any other virtualization system >import a VirtualBox appliance? VirtualBox exports in the Open Virtualisation Format [1], which is more or less an industry standard format, and again more or less driven by VMWare. Moving OVF appliances between different virtualisation systems is still a bit shaky but should soon be pretty simple.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 21:02 UTC (Wed) by bronson (subscriber, #4806) [Link]
That is great news! It sounds like an OVF package can be stored as a single unit or a directory of files. That should make everybody happy. :)
The single unit is just a tarfile so performance would be an issue if one were to execute it directly. Still, I agree, as things mature this could become really useful.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 23:00 UTC (Wed) by HelloWorld (guest, #56129) [Link]
If you actually think that double clicking in a custom GUI is painful, you probably shouldn't be using a computer at all.
Your analogy to OpenOffice or vim is completely brain dead. If you want to send an OpenOffice document via email, you *do* have to export it. Yeah right, it's called File -> Save as..., i guess that's what makes it so much easier to use, right? Oh, and speaking of emails: email programs do just the same, they keep a database of your emails so you can read and answer them easily. Do you want to mess around with emails as files? I don't. My emails are buried somewhere deep within ~/.kde, and i don't give a rat's ass about the files they're stored in as long as it works. I guess most desktop users feel the same.
Furthermore, sending VMs via email etc. is just not a common use case. The common use case is that somebody sets up a machine once, say, to use some legacy windows app, and keeps using that as long as he needs it. Also, all the files are there in ~/.VirtualBox, nothing stops you from backing up that directory. It's not rocket science you know. But it seems you just want to whine about how bad the world is anyway, so i don't see a reason to waste further time with you...
KVM, QEMU, and kernel project management Posted Mar 25, 2010 12:28 UTC (Thu) by bronson (subscriber, #4806) [Link]
As with the ssh example, you ignore the point in order to get in a lame insult. Do you feel better now? The point was that custom GUIs tend to be painful, especially when there's a perfectly good alternative.
Save As is not the same thing as Export.
Your email example is actually a good argument wrapped in boring vitriol. The difference is that email involves tens of thousands of messages, whereas desktop users only have a few VMs.
Sending MP3s via email was not a common use case 10 years ago, sending 50 MB PPTs and PDFs via email wasn't common 5 years ago... Limiting design to only serve the common use case would make the future a pretty boring place!
KVM, QEMU, and kernel project management Posted Mar 24, 2010 9:50 UTC (Wed) by till (subscriber, #50712) [Link]
Still with VirtualBox, afaik one has to setup a lot, e.g. adding an ISO to an iso storage and configuring the VM. With KVM one can just create a nice shell alias and boot e.g. Fedora Test release live images with one command:
alias kvm_iso="qemu-kvm -boot d -k de -m 1024 -usbdevice tablet -cdrom"
And when I kill the VM, nothing is left behind (log files, stale configs, ..).
KVM, QEMU, and kernel project management Posted Mar 24, 2010 13:42 UTC (Wed) by HelloWorld (guest, #56129) [Link]
You can completely automate this with the VBoxManage command line tool. It is slightly harder to do, but it can be done.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 14:32 UTC (Wed) by wookey (subscriber, #5501) [Link] Dammit, if I want to run an old copy of Armor Alley, why can't I just scp a single file from a friend and double click on it? To be fair that's exactly how it works these days in wine. Perhaps you don't count wine as 'virtualisation', but from a user's POV it does the same thing: 'runs my Windows programs'. And these days it does it pretty well. I've been doing a lot of building design recently and the world is _full_ of stupid little programs for Windows to spec beams and tanks and do heat analysis and the only easy-to-drive* no-cost 3D drawing package (Sketchup) has no Linux version. Everything I have tried so far works in wine, somewhat to my amazement (sketchup is cranky due to opengl/video hardware options, but it does work). This virtualisation stuff doesn't help me at all because it needs a copy of the host OS and I simply don't have any of those. * And yes I did try Blender first but after about 6 hours I had drawn 3 slightly wonky walls of the garage. In the same time in Sketchup I'd done pretty-much the whole design (house+extension). I love my free software as much as the next man but a) Blender not really technical drawing software - that's not it's heritage and b) Sketchup's interface is _really_ nice, at least for initial more-or-less right models -I'm not sure it's great detailed tech-drawing software either. Bit off-topic there, but I just wanted to point out that download+double-click does in fact now work for lots of Windows software thanks to the marvelous work of wine. I agree that having this work one way or another is an important part of weaning people off Windows. A lot of people have one or two things like this that keep them tied to Windows. And we need critical desktop mass to get drainpipe manufacturers to stop writing Windows-only apps.
|
|||||||||||||