Fri, 16 Feb 2007
Firstly the architectural differences: KVM is a full virtualization
system - it requires pretty new CPU with virtualization support
(Intel VT or AMD-V). With this support, it allows the computer
to be fully virtualized (yes, I even tried to install The Other OS
Which Should Not Be Named under KVM, and it worked). On the
lguest is pretty minimalistic paravirtualization
system, which requires slight modification of both the host and quest
kernel - so it is Linux-under-Linux only.
KVM virtualizes the CPU, but to run a complete guest OS, the whole
computer needs to be virtualized. KVM uses a patched version of
emulates PC with a NE2k compatible NIC, Cirrus Logic VGA card,
IDE drive (with a plain file in the host OS as a backing store), etc.
Qemu itself can work as a full PC (and PowerPC and Sparc too) emulator,
but with KVM, it just provides the necessary virtual components to
the already-virtualized CPU. Qemu supports many file formats
for the disk image (including Xen, User Mode Linux, VMDK and others).
It also has the nice feature that when started with
option, it connects its terminal to the virtual serial port of the
quest system, providing a seamless serial console!
As for architecture, KVM+Qemu runs on IA32 and AMD64, while the
guest system can be 32-bit or 64-bit. The guest system is single-CPU only.
Networking can be done using a shared file (so even an ordinary user
can run his own set of virtual machines, and connect them together),
or with TUN/TAP interface it can communicate with the host OS as well.
lguest is still a proof-of-concept code, but it has some nice
features: it works on older CPUs as well (AMD64 support is being developed
as well, but now it is 32bit only). It can use memory-to-memory communication
between host and quest (so it does not have to emulate the NE2k card,
for example). Subjectively
lguest was faster and more
responsive than KVM. Here are the drawbacks of
its virtual disk is a raw file only, and it even does not support
partitioning, so existing Qemu images did not work. It does not "boot"
the block device per se, instead it starts an external kernel (in form
vmlinux file), which then mounts its root.
I will measure the performance penalty of both virtualization systems, and post it to my blog later.
4 replies for this story:
Abraxis wrote: XEN
Why don't you evaluate XEN at all? It seems to me as most mature Linux virtualization technology (even with guest SMP support).
Yenya wrote: Re: XEN
XEN is still far from being included in the vanilla kernel, so it is not feasible for me to use it now. If the time allows, I might do some tests as well, though.
Yang Yang wrote: Cirrus driver crashed on Windows XP pro
I use qemu/kvm and installed windows xp pro on a disk image. My host os is Debian Linux 3.1, kernel version is 2.6.18. The installation is fine. But when I try to start it the blue screen appeared which show that cirrus driver entering a infinite loop. I can only start windows in safe mode. Strangely enough, if I turn off kvm, only start qemu, it works fine. I googled this but found nothing. Is it a bug of kvm or qemu or should I install a new kernel > 2.6.20?
Yenya wrote: Re: Win XP pro
I don't know, but the docs mention that for Win XP the qemu should be run without an ACPI support. Maybe this is what you need to run it.