KVM, QEMU, and kernel project management [LWN.net]

KVM, QEMU, and kernel project management

Posted Mar 24, 2010 3:04 UTC (Wed) by bronson (subscriber, #4806)
In reply to: KVM, QEMU, and kernel project management by HelloWorld
Parent article: KVM, QEMU, and kernel project management

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?

to post comments

KVM, QEMU, and kernel project management

Posted Mar 24, 2010 4:06 UTC (Wed) by HelloWorld (guest, #56129) [Link] (6 responses)

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] (4 responses)

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.
Double-clicking on some list in a custom GUI == desktop pain.

"All your other points are made moot by the export appliance feature."
I covered this in my previous message. Just imagine if you were forced to store all your OpenOffice documents (or Emacs or Vim or whatever) in a custom database, and were forced to export every time you wanted to attach one to an email or back up to a NAS. As I said, it's is a step in the right direction, but it still sucks.

"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?

"Using the same file for different things is just a bad idea."
Sometimes true, often false. Imagine if you had to store each layer in a separate Gimp file. Or had to keep mp3 data in one file and its ID3 tags in another. It would be horrible. Maybe read again the upsides and downsides I mentioned in the previous message?

KVM, QEMU, and kernel project management

Posted Mar 24, 2010 19:53 UTC (Wed) by mjthayer (guest, #39183) [Link] (1 responses)

>"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.

[1] http://en.wikipedia.org/wiki/Open_Virtualization_Format

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] (1 responses)

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!