On Fri, 30 Nov 2007, Daniel P. Berrange wrote:
This is a friendly alert of the major plans we have for Xen kernels
Fedora 9 timeframe...
Thanks for the warning.
Since we first added Xen in Fedora Core 5, our kernels have been
a forward-port of XenSource's upstream Xen kernels, to new LKML. For a
long time we ported their 2.6.16 tree to 2.6.18. Now we do ports of their
2.6.18 tree to 2.6.21/22/23, etc.
Welcome to my world of KLIPS and NETKEY/XFRM and trying to merge that into
one IPsec stack so that problem goes away. Unfortunately, upstream moves
rather independantly. Though having the lwm.net
site, which at least semi
documents API changes, makes the work a bit easier.
At the same time, upstream Linux gained
Xen support for i386 DomU, and shortly x86_64 DomU, and is generally
getting ever more virtualization capabilities.
I am somewhat confused here? Upstream gained xen support but you're forward
porting xen support?
As everyone knows, we have tended to lag behind Fedora's
bare metal kernels by several releases due to the effort required to port
Xen to newer LKML releases. Despite our best efforts, this lag has been
getting worse, not better.
Which is mostly due to XenSource going all "windows centric". Which got worse
when they were bought by Citrix. XenSource (an awful name for a company
relying on closed source code for their enterprise version), has not put in
the sources to keep up to date, probably partially also for not getting
We have taken the decision, that this situation is unacceptable for
We simply cannot spend more time forward porting Xen kernels. Either Xen has
to be dropped entirely, or we need a different strategy for dealing with the
kernels. Since people seeem to use Xen, we have decided not to drop it :-)
Being onf of those people, thank you very much. And to add to that, xen has
been almost exclusively usable for serious deployment within Fedora. It has
always been far superiod to other distro's integration or using xensource
source code itself. I might have cursed a bit on the initrd sillyness, and
the PAE incompatibility, but other then that, all our servers are now fully
xenified and run more stable then ever before as real iron machines needing
physical reboots too often.
So the plan is to re-focus 100% of all Xen kernel efforts onto
LKML already has i386 pv_ops + Xen DomU. We intend to build on this to
I might be mixing up things, but are you saying you are focussing on adding
paravirt to lguest? And replace xen?
Getting all this done for Fedora 9 is seriously ambitious, but it is
long term sustainable option, other than dropping Xen entirely.
I understand that too well.
What this means though, is that Fedora 9 Xen will certainly be going
periods of instability and will certainly be even buggier than normal. F9
may well end up lacking features compared to Xen in Fedora 8 & earlier (eg no
PCI device passthrough, or CPU hotplug). On the plus side though we will be
100% back in sync with bare metal kernel versions & hopefully even have a
lot of this stuff merged in LKML to make ongoing maintainence sustainable.
Short term pain; Long term gain!
I think most deployments are simple paravirts with no other hardware then virtual
disks and virtual network cards. So that might not be as bad as it sounds.
Dan ...on behalf of some very busy Fedora Xen kernel developers :-)
Thanks for all the work on virtualization. Most endusers won't really care
what powers it under the hood, as long as they can simply re-use their
disk images of older fedora releases on newer fedora releases with perhaps
only the addition of the newer kernel modules inside the old disk image.