June 9th, 2010
Yesterday morning, my virtual machine host system gave up the ghost. It was working fine, I did an upgrade on it which included a new kernel, went to reboot it, and it never powered on again. Various tricks up to and including percussive maintenance wouldn’t convince it to come back from beyond the grave. Ah, well – it had a reasonably good run, five years for a Shuttle shoebox ain’t bad.
So off to Netlink I went, for the components for a new virtual machine host box. The case and PSU I bought turned out to be a waste of money as it didn’t quite fit in my cabinet (curse you, wobbly tape measures), and I realized I had an old Shuttle-type case which takes generic mATX motherboards in the basement…so I just used that instead. Its custom PSU has the old 20-pin ATX power connector not the new 24-pin eATX one, but it still seems to work okay; the motherboard manual says this is okay as long as it can supply sufficient power over +12V, which it claims to. The components I went with – Asus M2N68-AM Plus motherboard (I’d have got the M4N68T-M but they were out of stock), Athlon II X2 250 CPU, Kingston HyperX RAM – went together without problems and work fine. The combo isn’t exactly optimized for raw speed (you’d want a motherboard with a newer chipset and DDR-3 RAM for that) but it should be more than fast enough for the purpose, and the motherboard was nice and cheap.
Here I am with my new box, then, and unlike the old one it’s a 64-bit CPU with virt support. And now I work for Red Hat. Naturally, it gets to run Fedora 13 (could’ve used RHEL, but c’mon, where’s the fun in that?!) and use libvirt / kvm. The old box ran Mandriva and VMware Server, so I have some work to put in.
I’m amazed, though, at how much work it turned out not to be! I did a minimal install of F13, installed the ‘Virtualization’ package group, and set up normal network stuff, including key-based ssh login for root (no reason to create a user account on such a system). Know how much work it is to set up an F13 machine to be a virtualization host that you can manage from virt-manager running on another system? EXACTLY THAT MUCH WORK, that’s how much. Just run virt-manager on your other system, add a connection, set Connection to ‘Remote tunnel over SSH’, and enter the hostname. As long as you have key-based login for root, that’s all you need.
Converting my VMware VMs to libvirty qemu/kvm ones turned out to be equally, surprisingly, simple. This doesn’t give optimal performance as it doesn’t use virtio, but it seems more than good enough for my modest needs. Use vmware2libvirt (thanks Ubuntu land for that one) to convert the VMware .vmx file into a libvirt XML machine definition. Use ‘qemu-img convert filename.vmdk -O qcow2 filename.qcow2′ to convert the virtual disk file from VMware to qemu format (this is optional, as it can use the VMware disk image format directly, but it won’t be able to do snapshots then, so conversion is recommended). Both of these steps create new files, so the old VMware machine still exists completely unaltered if you need to go back to it. Edit the .xml file slightly to point to the qcow2 file instead of the vmdk one, and to change the qemu executable from /usr/bin/qemu to /usr/bin/qemu-kvm (on Ubuntu it’s the former, on Fedora it’s the latter). Then import the .xml file into libvirt with ‘virsh -c qemu:///system define filename.xml’ . That’s it: the entire process. If you look at your shiny remotely-connected virt-manager session now, you’ll see the VM all ready to be booted up. Very very neat stuff!
I actually had to do one more step, to set up bridged networking for libvirt, which you only need to do if you need to use bridged networking for your VMs, obviously. That’s simple too – just follow the libvirt wiki instructions, and when using vmware2libvirt , use the -b (interface) parameter to tell it you want to use bridged networking and what interface to use.
With just an hour or so’s work, including all the research, I’ve converted all three of my server VMs from VMware machines running on VMware Server on Mandriva to qemu/kvm machines running on libvirt on Fedora. Huge kudos to all the virtualization folks for their amazing work on this, the libvirt stack is very very impressive these days.
Of course, if you’re wondering where this blog went for the last day or so, the above is the answer Yesterday was all spent in planning and doing the hardware build, today was setting up the software. Sorry for the inconvenience, believe me it’s worse for me than it is for you when this happens!