With KVM proving more and more that it is viable Xensource and VMWare start sandbagging. They call KVM
immature and the wrong approach (see their quotes in CNET article).
Calling KVM is immature is, well, premature and misleading. Xen has a headstart of several years. KVM is today not supposed to be in the state Xen is. Nevertheless, KVM already has hardware virt support, SMP support, support for 64-bit host and guests (despite what the article says), live migration, and more. Xen simply started from the other direction, namely para-virt, hardware virt took them a long time and a lot of help from the hardware vendors. I think para-virt will be done RSN.
immature is not the worst complain. Claiming the hypervisor approach is the only viable option is what should get people worked up. Look at the arguments:
[...] but hypervisors offer better performance, have security advantages, and juggle the competing needs of multiple virtual machines better [...]
In order to [deliver Virtual Infrastructure], you need the separate hypervisor layer.
These are bogus claims. And you have realize where they come from. VMWare’s ESX is a kernel on itself, one which only few people work on (compared to something like Linux). Device drivers will always be a nightmare unless/until devices get their own PCI devices (once DMA can be virtualized). Nevertheless, ESX is a full OS by itself. Plus, ESX has the service console a Linux OS. The service console of course has to have some control over the hypervisor.
For Xen the situation is similar. Here the hypervisor, after the mistakes of the 1.x series, don’t have device drivers included and use a privileged domain, a complete OS.
This means, both Xen and VMWare do not have less code. I’d say they even have more code that is part of the privileged code base. Certainly a Linux installation hosting KVM domains can be scaled down to only have the kernel, kqemu, and the service console.
As for specific security support, Xen has in theory shype or whatever will come out of it. Like SELinux, it’s based on Flask. But it still is a separate code base. And if shype is actually moved out of the hypervisor itself and into a separate domain you have to worry about even more interfaces to worry about. I haven’t seen any security features of this caliber even mentioned for VMWare. With KVM, the SELinux policy governing the kernel can also handle the KVM module. It’s after all part of the same kernel. One implementation, one policy.
As for performance, let’s wait until KVM actually has been optimized. Ingo did some work on a para-virt network driver and the results are simply great. It’s just that performance tuning hasn’t been a focus. In theory there is absolutely no reason why the KVM approach should be any slower.
As for better scheduling with a hypervisor: that can only be a joke. Especially for Xen, the privileged domain (Dom0) has to be scheduled without the hypervisor having any insight into the Dom0 kernel. How can this be better? For VMWare we have a simple-minded OS serving as the hypervisor. The Linux kernel has support for all kinds of situations, including NUMA machines, many processor machines, HT and multi-core processors etc. And it’s an O(1) scheduler which sooner or later will make a difference even for hypervisors.
And then there are the advantages the KVM solution has. For instance, ever tried to run Xen on a laptop while on battery? It’s almost not worth it since power management does not exist. The machine will always run at full power. VMWare has the same problem. This is not only an issue for laptops. Cooling is a major issue in data centers. Maybe even a bigger issue with increasing density.
NUMA has already been mentioned, but there is also the memory allocation issue as part of the problem. Xen has nothing of it, I bet VMWare neither or something simple. The Linux kernel can provide KVM with all kinds of support, as the performance on big NUMA machines like SGI’s Altix shows.
In short: neither Xen nor VMWare have any real advantages which cannot be surmounted by giving KVM more time to catch up, i.e., grant it the same time to develop the features. On the other hand there are device driver issues which VMWare will never be able to muster. Xen is not included into the mainstream kernel and even with paravitr_ops interface will be lagging because it needs synchronization.
So why do these companies (and Xensource makes this statement as a company) make such statements? The answer should be not surprising: they have a lot or all to lose. KVM can be the one-in-all solution, unlike any of the others. Xensource and VMWare want to get on your system by providing a hypervisor which then can be used with all kinds of OSes. But: they are in ultimate control. The idea that there suddenly is a virtualization solution which does not need any hypervisor must be absolutely frightening to them. So, they try to suppress this no technology from the start.
Don’t believe the propaganda. Try KVM once it Fedora 7 is out. I expect it to be updated over the lifetime of Fedora 7. Or for the more adventurous people, start using rawhide now and keep using it.