[Fedora-xen] FYI: The plan for Xen kernels in Fedora 9

[Daniel P. Berrange]

On Fri, Nov 30, 2007 at 02:44:13PM -0500, Paul Wouters wrote:
> On Fri, 30 Nov 2007, Daniel P. Berrange wrote:
> > 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?

Upstream gained support for i386, DomU Xen support only - that's far from
a complete solution, hence F8 still uses a forward port. This F9 plan is
basically about finishing the upstream Xen to support all the features we
need for Fedora & avoid any more forward porting.

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

No, lguest is just another user of pv_ops. This is explicitly still a Xen
paravirt solution - we'll still have a Xen 3.x hypervisor underneath, with
same Xen 3.0 hypervisor ABI. So F6/7/8 guests should work on F9 host, and
F9 guest should still work on F6/7/8 host. ABI compatability is key because
that's what makes Xen, Xen :-)

lguest (at this time) is still basically a tool for research & development,
not real world production use. 

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

Yep, we're basically prioritizing our work to address most common & important
areas first. Eventually we may get to stuff like PCI passthrough & CPU hotplug
but its longer term low priority stuff.

Regards,
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|