[Linux, libvirt, kvm, snapshots] Piecing together an open-source equivalent of VMWare Workstation

Well, first, I should mention I've been spending a lot of time in KVM lately; paycheck depends on being able to code on Windows, and I don't have any hardware I want to put Windows on the bare metal of. libvirt+KVM works nicely as a virtual machine, and some parts of its feature set rival that of VMWare Workstation right out of the box. For example, the latest version of Workstation I have access to doesn't support direct access to PCI devices. KVM does (though I haven't played with it). Of course, there are things that Workstation does better than libvirt+kvm, as well. Let's see what's missing:

* Snapshots, full clones, linked clones
* Resize guest display to match viewer viewport. (I had to resort to some XML editing in order to get a video device I could make larger than 1024x768, and that's still not as nice as having the guest framebuffer resize automagically)
* Drag-and-drop between guest and host.
* Application-in-host (Workstation calls this "Fusion", and it's awesome if you need it. I still need to send that fruit basket to the couple developers who wrote that feature.)
* Suspend guest VM.
* Has D3D9 acceleration (for Windows guests on Windows hosts, which wouldn't work for me anyway), which is better than the no-graphics-hardware-acceleration I face with libvirt+kvm. (There is an SDL client, but libvirt's dynamic privilege toying with PolicyKit doesn't manage to get it to work on my system.)

Things that libvirt+KVM does better than Workstation (at least as of the latest version I have access to)
* Will give as many as 16 virtual processors to a guest.
* The VM definition file is XML, and well-documented on their website; manual tweaks are pretty easy.
* Has the ability to not affix a MAC address to a guest. While this causes Windows guests to destroy old NICs and create new ones every time you reboot, it will make cloning much easier.

So let's see what we can do about the things that libvirt+kvm doesn't quite do on it own yet.

D3D9 Acceleration
Not going to happen; host doesn't have Windows. On the other hand, I can put in another video card and give a guest VM direct access to it. I haven't tried it, but it could work, so long as I don't allow the host's X server to use that card.

Susped guest VM
Not going to happen until there's a to specify a file to hold a RAM image, at least. (I could easily see them mmaping that file, too; it seems like a perfectly kosher way to leverage the x86 MMU on 64-bit systems.) No such option exists, currently.

Application-in-host
On Windows and Linux guests both, this requires some awareness of and integration with the guest window manager. There are probably VNC servers that can handle that individually, and there are already VNC servers for both guest operating systems that will serve up individual windows. If you put a VNC client on the host in Listen mode, you could find a way to have every launched application connect to that client. It'd require some real script-fu in the guest, though, and there's also the problem that VNC doesn't support drag-and-drop between clients. (And typically isn't aware of it at all...)

Drag-and-drop between guest and host
That'd require some extension to the VNC protocol, so I can't do that right now. (OTOH, it would be a very, very good general enhancement to the protocol!)

Resize guest display to match viewer viewport

VMWare uses the same core protocol between its viewing interface and its virtualized video card, and its viewing interface supports the viewport and guest triggering each other to resize. (Admittedly, I don't know for certain that the viewport-triggers-guest event is communicated using the same channel.) It seems likely that it could be done, but will require an extension to the VNC protocol.

Snapshots, full clones, linked clones

Some of this is something I might actually be able to do soonish (and I'll certainly be working on it!) Linux has LVM, which, at the very least, will let me take a snapshot of a base volume, and do copy-on-write for maintaining things. I don't know that it will let me take a snapshot of a snapshot, though, or give me simultaneous r/w access to multiple snapshots of the same base view. If it does, that would put it pretty close to VMWare Workstation's capability. If not, it puts me closer to VMWare Server's. VMWare Workstation allows you to take a snapshot after running on a snapshot, which gives you base->snapshot->snapshot, and you can choose to run any of those you like without affecting the others. It also allows you to create a linked clone of any of them, which amounts to creating a snapshot that you can run at the same time as you run a snapshot from that tree. VMWare Server, on the other hand, only has two states for a VM: current snapshot, and current state. In VMWare Server, you can always replace your current snapshot with your current state ("Take snapshot") or your current state with your current snapshot ("Revert to snapshot"), but that's it.

Notice I'm not talking about VMWare Server ESX*; that beast's snapshot model is a little closer to Workstation's.

Out of all of these things, the snapshots and clones are the part I need to work on the most. Right now, snapshots and clones are pretty much the same thing; copy the disk image, copy the XML file, and modify the XML file to point to the copied disk image's location. That gets pretty expensive, diskwise, pretty fast. LVM's copy-on-write should help with that a lot. So would a filesystem with built-in deduplication, but ext4 (what I'm running on right now) doesn't have that. (I can think of a bunch of other reasons a filesystem with built-in deduplication would be awesome, too. Maybe I'll brainstorm on some different performance tradeoff option ideas in the near future.)


--
:wq