andrelop's blog

It’s no secret for those who follow me on Twitter/identi.ca that I have been toying with virtualization technologies for some time now.

I have been using Xen in production for some time and, apart from not thinking it’s the way to go for future virtualization, it’s quite usable right now, specially if you are going to use Debian Lenny as the dom0, as it now has a more modern kernel than the dreaded 2.6.18 we Xen users were forced to keep using.

However, I have been keeping my eyes on KVM as well, as I always liked how much simpler and well integrated into the Linux kernel it is. I’m even subscribed to the KVM development mailing list, even not understanding most of the things the developers are talking about there. It’s no problem for me, I just want to know what’s being worked on and what’s on the pipeline.

As a KVM fan, I’m also using it intensively as a tool for prototyping servers. It’s easy enough to set up a new Debian server to test things on and learn new technologies, as well as troubleshoot problems without intefering with production environments.

Althought KVM is not as good as Xen when it comes to performance, it’s quickly improving every single day. And, for those of you who still believes KVM is only about full virtualization, I’m happy to say that it has come a long way and paravirtualization has started to infiltrate KVM land as well.

Today, KVM already sports paravirtualized clock (pvclock), paravirtualized memory management unit (pv MMU) and VirtIO drivers. Actually, it seems that KVM these days is the biggest user of VirtIO, maybe only loosing the leadership to Rusty’s lguest.

By using VirtIO’s disk and network drivers (virtio_blk and virtio_net, respectively, and its associated modules), KVM can deliver a much improved I/O experience than when using QEMU’s emulated drivers. For this reason, it’s always preferable to use VirtIO drivers whenever possible when setting up your KVM guests.

During the Etch lifetime, one will need to do some tricks in order to use VirtIO when using Etch as a guest under KVM. However, when preparing Lenny’s d-i, the developers were smart enough to add to it virtual disk detection support. What it means is that now, starting with Lenny, d-i will recognize that it’s being given a VirtIO block device and automatically load the needed kernel modules to support it.

Also, the disk detection and partition modules (partman et all) were modified to show a detected virtual disk (i.e. /dev/vdX) and let the user partition it, as well as grub-installer was changed to allow GRUB to be installed onto a virtual disk’s MBR,  effectively making d-i a really powerful virtualization aware installer.

Here you can see Lenny’s d-i showing a detected virtual disk, named “vda” :

lenny-vdisk-partitioning-english

Brazilian Portuguese readers could see the version using brazilian portuguese texts on the screen here. Sure, d-i also received a lot of improvements and special support for installing Lenny as a Xen domU was added as well, but I haven’t played with it yet, so I won’t comment on that right now.

And, hey, one can even use virt-install and virt-manager to deploy KVM guests under Lenny And you know what gives me even more confidence that KVM will be a first class citizen inside Debian ? The fact that Steve Kemp is toying with the idea to change his xen-hosting.org project so it would become a new kvm-hosting.org project.

Maybe I’m praying for the preacher here, but Steve is very well well know for being the author of xen-tools and xen-shell, as well as being the creator of a number of other nice free softwares. And, judging by the comments on his post about the future kvm-hosting.org project, it seems that Steve maybe will need to update xen-tools and xen-shell to account for KVM or create a new set of tools dedicated exclusively to KVM based on his past experience creating the current tools for Xen.

Good times ahead for those of us who are surfing the Debian Virtualization wave, indeed