You are viewing udrepper

Ulrich Drepper - Xensource/VMWare start sandbagging [entries|archive|friends|userinfo]
Ulrich Drepper

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Xensource/VMWare start sandbagging [Feb. 26th, 2007|10:07 pm]
Previous Entry Share Next Entry
[Tags|]

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.

But 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.

linkReply

Comments:
From: chemaja
2007-04-22 02:19 pm (UTC)

Interesting, but what about RHEL5?

(Link)

Red Hat is currently pushing the Xen platform in RHEL5.

So say KVM matures greatly in the next year or two -- does RHEL6 then use KVM as the primary virtualisation engine?

Hopefully they use the most technologically superior solution.
From: udrepper
2007-04-22 07:15 pm (UTC)

Re: Interesting, but what about RHEL5?

(Link)

Red Hat is currently pushing the Xen platform in RHEL5.

So say KVM matures greatly in the next year or two -- does RHEL6 then use KVM as the primary virtualisation engine?

Hopefully they use the most technologically superior solution.


It is far too early to speculate about RHEL6 at this point. What you can be sure about is that we will pick the technologically superior option. Compatibility is not really an issue when it comes to KVM. See this talk at this year's OLS. If this works out all Xen guests could work on top of KVM. We just wouldn't need the Xen hypervisor.

Another alternative is something people are considering now: transform xen into a kernel model and thereby adopting the KVM model of using Linux as the hypervisor. This is (of course) not backed by XenSource but I don't consider as the slightest bit of a problem.
From: chemaja
2007-04-23 08:04 am (UTC)

Re: Interesting, but what about RHEL5?

(Link)

Aah, very cool.

I am resting assured with my decision to port our application servers to Xen in the medium term, Ulrich -- thanks.

Looking forward to the evolution of KVM. :-)
From: udrepper
2007-04-23 02:23 pm (UTC)

Re: Interesting, but what about RHEL5?

(Link)

There is one more thing I should have mentioned:

Red Hat's approach to controlling virtualization has always been to abstract out the access. Not in the Xen-specific way XenSource's stuff wants it, of vmware-specific as EMC's tools want you.

With libvirt we have an API which is completely agnostic as far as the virtualization mechanism which is used. If you look at the libvirt in Fedora 7, it can handle Xen, KVM, and UML (as far as I know) already. It's only going to get better.

I.e., if you create any kind of system management for these environment and you use libvirt you can ignore the actual technology used, it'll just work regardless.