Xen, Squeeze, and Beyond Summary
Thank you for the conversation on this. I would like to summarize what
people have been saying -- it seems there is still a lot of disagreement
about things out there yet, and I'm not entirely certain about things
yet, but this has been helpful.
I'll include my original email with comments from people posting in this
thread mixed in.
According to http://wiki.debian.org/SystemVirtualization :
"Qemu and KVM - Mostly used on Desktops/Laptops"
"VirtualBox - Mostly used on Desktops/Laptops"
"Xen - Provides para-virtualization and full-virtualization. Mostly used
on servers. Will be abandoned after squeeze."
+ Andrew M. A. Cater: Xen doesn't keep anywhere current in terms of
kernel - if we release Squeeze this year with kernel 2.6.3*, Debian will
have to maintain all the patches/ "forward port" them to 2.6.32 or
2.6.33 as was done with 2.6.2*.
+ Goswin von Brederlow: I think we can all agree that the old style xen
patches from 2.6.18 and forward ported to newer kernels in lenny are
unmaintainable. But the pv-ops xen kernel is shaping up well and that is
what Bastian Banks is working on. They have a proper upstream and follow
the latest vanilla kernel well enough. According to the wiki the plan is
to have pv-ops merge into vanilla with 2.6.34.
+ Olivier Bonvalet: Linux dom0 kernel from Lenny doesn't work at all on
some hardware with recent pv_ops domu. In that case you have to change
to a different version...
The Xen page on the wiki makes no mention of this.
So, I am wondering about our direction in this way:
*** 1) Will a squeeze system be able to run the Xen hypervisor? A Xen dom0?
+ Ben Hutchings: Maybe. Ian Campbell and Bastian Blank are working on it.
+ Bastian Blank: [re hypervisor] Why not? I see packages laying around.
[re dom0] Most likely yes. I'm currently ironing out the obvious bugs.
*** 2) Will a squeeze system be able to be installed as a Xen domU with
a lenny dom0? What about squeeze+1?
+ Ben Hutchings: lenny's xen-flavour kernels (needed for dom0, optional
for domU) are not supportable even now.
+ Bastian Blank: Yes. It should even run on RHEL 5.
+ Olivier Bonvalet: I have a Debian squeeze running on a Lenny Dom0
Xen. Today it seem to works.
*** 3) What will be our preferred Linux server virtualization option
after squeeze? Are we confident enough in the stability and performance
of KVM to call it such? (Last I checked, its paravirt support was of
rather iffy stability and performance, but I could be off.)
+ Marco d'Itri: [regarding KVM stability]: Yes. [regarding my
impressions of KVM being wrong]: You are, KVM had huge changes in the
last year.
+ Andrew M.A. Cater: KVM is shaping up well and appears to be very well
supported by Red Hat.
+ Goswin von Brederlow: [to Cater] But still slower and less secure due
to qemu.
*** 3a) What about Linux virtualization on servers that lack hardware
virtualization support, which Xen supports but KVM doesn't?
Marco d'Itri: Tough luck.
*** 4) What will be our preferred server virtualization option for
non-Linux guests after squeeze? Still KVM?
+ Marco d'Itri: Yes, virtualized Windows works much better in (modern)
KVM than Xen.
*** 5) Do we recommend that new installations of lenny or of squeeze
avoid Xen for ease of upgrading to squeeze+1? If so, what should they use?
+ Ben Hutchings: I would discourage use of the xen-flavour in lenny.
+ Marco d'Itri: It depends. KVM in lenny is buggy and lacks important
features. While it works fine for development and casual use I do not
recommend using it in production for critical tasks. This is where Red
Hat really beats us: RHEL shipped Xen years ago but recently they
released an update which provides a backported and stabilized KVM.
+ Andrew M. A. Cater: New Squeeze - use KVM? New Lenny - whatever you
want, because at this point you have (days until release of Squeeze + 1
year) to find an alternative.
*** 6) Are we communicating this to Debian users in some way? What can
I do to help with this point?
+ Marco d'Itri: Remind people that Xen is dying and KVM is the present
and the future.
+ Samuel Thibault: [to Marco] No FUD, thanks.
-- John
Reply to: