Xen, KVM, & Squeeze
Hi folks,
I posed these questions on debian-devel and was told I should be asking
them here. Also, I got some rather contradictory information on -devel
so perhaps this is a good idea. I'll repeat my questions along with the
answers I saw on -devel, and perhaps some light can be shed on it here.
I will happily summarize on -devel.
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: 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.
Thanks,
-- John
Reply to: