Ulrich Drepper on hypervisors versus KVM
Posted by Fraser Campbell Tue, 27 Feb 2007 13:05:00 GMT
Ulrich Drepper is lead maintainer of the Linux C library (GNU libc), works for Red Hat and is well known in Linux circles – basically he is one smart cookie.
Last night he has posted a great article entitled Xensource/VMWare start sandbagging.
The article discusses the fact that Linux already has great support for NUMA, SMP, scheduling, hardware drivers, etc. My favorite “As for better scheduling with a hypervisor: that can only be a joke.”.
We can expect the marketing machines to crank out reams of verbage in the next 6 months but I trust Mr. Drepper more than I would trust anything I see coming from the corporate presses.
Linux as the hypervisor just makes sense. Jeff Dike has been pushing the idea for years with UML and UML continues to move forward.
The only slight beef (or question) I have with KVM is why has it diverged from QEMU? More specifically KVM relies on QEMU for it’s device emulation but it also requires hardware virtualization. Now that QEMU’s kernel accelerator is open source could KVM and QEMU not be merged back together to give us one high performing solution that would support both VT and non-VT capable hardware?
Indeed, I agree with most of the points here.
I once said “I want to run guests on Linux, not Linux on Xen.” More broadly, I trust Linux more. Be it real or perceived, I find Linux to be more stable.
As to the re-merging of Qemu and KVM , I agree that on the surface that looks like a very good option. However, I think the design goals of each group may be divergant and it might not work, but i agree it would be a good thing. :D
KVM will eventually get its changes upstream. The 0.8.2 => 0.9.0 was unusually long for QEMU so for a while there was a huge difference between KVM and QEMU so merging was hard.
Now, KVM is against 0.9.0 so merging is much easier. The problem is that because of a bug in KVM , a modified BIOS is required. The BIOS that QEMU uses is actually from the BOCHS project so it’s desirable not to get a proper fix so that QEMU doesn’t have to maintain the changes.
So it’s just an engineering issue. Once it’s sorted out, expect to see KVM patches on qemu-devel.