RE: [Xen-users] RHEL xen vs kvm

[Matej Zary <zary@xxxxxxxxx>]

Well, Xen is "owned" by Citrix, so I assume if Xen was the only one 
virtualization tool in RHEL, whole virtualisation capatibilities would depend 
on "another company" and I guess that's something people in RH didn't find 
acceptable. I don't know the whole story, but many RH customers are approaching 
them with requests to have something like VmWare offerings (not that they are 
not satisfied with VmWare functionality and performance, but it's always viable 
not to depend on single vendor (especially when the pricing is rather steep)). 
It doesn't make me happy that RH is abandoning Xen platform as host system, but 
it has its share of logic. Anyway,  RHEL 6 beta is out, so we can look what's 
new with KVM in RHEL - and Xen guest role is still supported 
(http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Beta_Release_Notes/virtualization.html#id569407
 - as PVM and as HVM with PV drivers). :) In the end, I guess Xen can benefit 
from some of KVM and QEMU improvements and ideas. And the better Xen and KVM 
gets, the better for us all, rigt? :)

Regards 

Matej

-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jeff Sturm
Sent: Thursday, April 22, 2010 4:26 AM
To: Arpan Jindal; Xen List
Subject: RE: [Xen-users] RHEL xen vs kvm

Like others have already said, you've asked this question on a Xen list, and 
you may want to ask on a RHEL or KVM list to get another viewpoint.

 

We use Xen today extensively.  For what it's worth, here are my observations 
and opinions in no particular order:

 

-      If you use a commercial cloud provider like Amazon EC2 or Rackspace 
Cloud, you probably already use Xen (at least the domU) and may not have a 
choice.

-      Xen supports paravirtualization without qemu assistance and without 
hardware support.  This may be an advantage if you are on older hardware, or 
wish to tailor a stripped-down distribution to run as a domU (e.g. you can 
build a Linux paravirt kernel without most hardware drivers, or a stubdom based 
on miniOS).  It's fascinating to me how truly small yet functional a domU can 
be.

-      The Linux kernel is big.  Very big.  I don't have a technical argument 
not to place the hypervisor inside Linux (as in KVM) but find it more 
aesthetically satisfying to separate the hypervisor from the kernel.  The Xen 
hypervisor is quite small, consisting of a text section under 900KB on my 
x86-64 hardware.  (I also wish Linux were smaller but don't see that trend 
reversing soon.)

-      The Xen hypervisor has its own scheduler that runs independent of the 
Linux process scheduler, potentially yielding more flexibility in system 
configuration and optimization.  KVM however relies on the Linux process 
scheduler to switch domains, as I understand it.  (I'll avoid arguments whether 
the Xen or KVM/Linux scheduler is superior for typical workloads.)

-      The argument that KVM is integrated with the kernel and Xen is not is 
becoming moot.  Thanks to new pv_ops kernels and Jeremy Fitzhardinge's efforts 
to merge with the upstream kernel, Xen will soon be as usable with the latest 
kernels as KVM.

-      Red Hat's reasons for embracing KVM seem odd, and possibly a little bit 
of "NIH" syndrome.  With enough work I'm certain KVM can be as good as Xen, or 
better, in terms of features and support.  Whatever problem they had with Xen, 
are we supposed to believe finishing KVM was less effort than merging Xen?

 

In the end I don't know that we needed two hypervisors that are so similar, but 
we have them.  It's going to come down to something like choosing between Intel 
or AMD.  One might have a slight edge over the other at any moment, or be 
somehow more elegant than the other, but both are very capable and you can do a 
lot with them.

 


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users