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 🙂
andrelop's blog 
I what project Steve Kemp is not working today ? 😛
@Walter Cruz
Indeed. Steve, if for some unknow reason you happen to read it one day, be aware that I’m one of your fans 🙂
Thanks for your commentary, BTW.
haha!
I do have a semi-complete KVM-shell, but the semantics are a little different so I’ve not yet made it public.
The reason that the xen-shell was so neat was because it let you run a few “outside” commands easily – such as “shutdown”, “boot”, “pause”. But it also let you connect to the serial console.
In KVM terms the console usually gets tied to a socket, or to the STDIN/STDOUT of the pty which KVM is launched under.
So having an “attach to console” feature, the most interesting part of xen-shell, is more of a challenge.
Right now I just launch KVM in a screen session, and attach to that. But I guess the more general purpose approach is to use a socket and talk to that via socat, nc, or similar.
Xen-tools I think are less in need of a port. Partly because installing is easier with KVM and VNC, and partly because already virt-manager exists.
Still time will tell .. and thanks for the nice comments 🙂
@Steve
Yes, some things are easier today than back then when you wrote xen-tools, specially considering that today there are tools such as virt-install and virt-manager.
Regarding connecting to the KVM monitor, I usually launch KVM using the -monitor parameter and bind it to a local TCP port so I can telnet to it and give commands from there. Just don’t do a “quit” from inside the monitor or else your KVM guest will be shut down 🙂
I agree that it’s not the most secure way to do it, but as I didn’t knew a safer way to do it, it at least got the job done. But I liked your way of running it from a screen session and attaching to it. I surely will try that way next time I need to launch one of my KVM guests.
Also, I’m looking forward to your KVM-shell. Coming from you, I’m sure this will be neat stuff.
Thanks for commenting and keep up the good work.
As a teaser here’s the init script I use:
http://www.steve.org.uk/Software/tmp/kvm/
It was deliberately written in a way that suited my needs, and could be dropped into /etc/init.d.
I do something similar to you – only I don’t use a TCP-socket I use a unix-socket which is slightly more secure. To shutdown an instance I rely upon APCI and a system-powerdown event which I can send to the socket via socat.
@Steve
Thanks for sharing your init script. I surely will give it a try 🙂 And thanks also for pointing out that the unix-socket way is safer than using a TCP-socket.
Now I have plenty of material to start playing around.
Regards,
This is good. Debian will definitely grow in datacenter environment.
@Ashish Barot
Surely. Growth in the datacenter is always nice. It’s not to say that Debian couldn’t be used in the datacenter already. It’s just that with these kind of features it starts to become a more tasty option for those which weren’t considering it yet.
Personally, I have some Debian servers in a datacenter as well as costumers servers. And some time ago I did some work for a company which had 95% of their servers based on Debian and all of them were hosted in a datacenter 🙂
Debian has a lot (I mean, “really” a lot) of users and a huge part of its users are corporate users. It’s just that these people doesn’t like to go around saying which kind of solutions they use for their infrastructure.
Anyway, thanks for your comments and for your visit. I hope you could come back here again and become a regular visitor.
Regards,
You mentioned that “KVM is not as good as Xen when it comes to performance”.. can you quantify that? Has anyone benchmarked or compared the two performance wise (though I know it’s difficult due to differing scenarios)? I’m very interesting in setting up a server running a several VMs under Lenny and I’m trying to decide whether to use Xen or KVM. 🙂
@Rav
Unfortunately, I cannot quantify it. Everyone trying to adopt a technology like KVM should experiment with it and decide for him/herself if it’s worth it for his/her specific environment/workload.
That said, I have also been looking for serious benchmarks showing KVM performance on real world scenarios, but I had no luck to date.
If you can find something interesting and current (benchmarks based on ancient versions aren’t all that useful today), please let me know. I would be glad to read them if anyone could point me to them 🙂
Anyway, thanks for your comment.
Thanks for such a nice blog. I am new to KVM. I have installed KVM on “Debian GNU/Linux 5.0” (Lenny).
I have also installed the same “Debian GNU/Linux 5.0” (Lenny) as a guest on KVM Host. How do I know whether this guest who is running on VM is using paravirtualization driver (virtio drivers)
I created VM using virt-install.
Your help is more than welcome.
Thanks.
@Hassan
There’re many ways to find out if you’re using VirtIO drivers. I also happen to use Lenny as the KVM host and have ran many guests using Lenny as well.
I can say you that when one uses virt-manager (the GUI tool from the libvirt project) from Debian it already uses VirtIO drivers by default for Lenny guests, both for disks and for networking.
You could just use “ps” from inside the host machine and check out if the KVM processes are using parameters as “model=virtio” for VirtIO networking (its on the “-net” options) and “if=virtio” for VirtIO disks (its on the “-drive” options).
Regards,