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
|
Home