On Fri, 30 Nov 2007, Daniel P. Berrange wrote:

This is a friendly alert of the major plans we have for Xen kernels in Fedora 9 timeframe...

Thanks for the warning.

Since we first added Xen in Fedora Core 5, our kernels have been based on 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 state-of-the-art 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 included upstream.

We have taken the decision, that this situation is unacceptable for Fedora 9. 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 paravirt_ops. LKML already has i386 pv_ops + Xen DomU. We intend to build on this to add:

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 the only 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 through 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.

Regards,

Paul