Fedora xen - May 2006 - re: Heads-up: Requiring PAE for running Xen

Jeremy wrote:
> As we move forward with Xen enablement, there''s a desire for
> being able to access more than 4 gigs of RAM on 32-bit Xen hosts.  The
> options for handling this are
> 1) Another kernel.  This is bad due to 
>    a) we''re running out of CD space already
>    b) keeping things matched up between the HV and the guest kernels
>    c) migration is worlds of pain with two types of kernels

What about leaving the non-pae kernel out of the core distro and 
distributing it online only via extras?

And document (b) and (c) as known issues which need to be evaluated 
carefully by users before installation.



- James
-- 
James Morris
<jmorris@redhat.com>

On Thu, 2006-05-18 at 16:52 -0400, James Morris wrote:
> Jeremy wrote:
> > As we move forward with Xen enablement, there''s a desire for
> > being able to access more than 4 gigs of RAM on 32-bit Xen hosts.  The
> > options for handling this are
> > 1) Another kernel.  This is bad due to 
> >    a) we''re running out of CD space already
> >    b) keeping things matched up between the HV and the guest kernels
> >    c) migration is worlds of pain with two types of kernels
> 
> What about leaving the non-pae kernel out of the core distro and 
> distributing it online only via extras?
You have to have it in the base set because the installation tree has to
include PAE install bits if you''re going to support PAE hosts.  HV +
dom0 kernel + domU kernel have to match here.

Ignoring that, you''re saying that you want to maintain a second kernel
package in sync with security errata?  It''s insanity.  Also, it will
break down a lot in terms of allowing kernel module packages, etc.

Jeremy

On Thursday 18 May 2006 03:00pm, Jeremy Katz wrote:
> On Thu, 2006-05-18 at 16:52 -0400, James Morris wrote:
> > Jeremy wrote:
> > > As we move forward with Xen enablement, there''s a desire
for
> > > being able to access more than 4 gigs of RAM on 32-bit Xen hosts.
The
> > > options for handling this are
> > > 1) Another kernel.  This is bad due to
> > >    a) we''re running out of CD space already
> > >    b) keeping things matched up between the HV and the guest
kernels
> > >    c) migration is worlds of pain with two types of kernels
> >
> > What about leaving the non-pae kernel out of the core distro and
> > distributing it online only via extras?
>
> You have to have it in the base set because the installation tree has to
> include PAE install bits if you''re going to support PAE hosts.  HV
+
> dom0 kernel + domU kernel have to match here.
>
> Ignoring that, you''re saying that you want to maintain a second
kernel
> package in sync with security errata?  It''s insanity.  Also, it
will
> break down a lot in terms of allowing kernel module packages, etc.
What if the modules were somehow packaged separate from the kernel images?  
The image packages could depend on the correct kernel modules package.

Obviously, this will require a little fine tuning of kernel package names and 
probably making ''uname -r'' report the same thing under the Xen
and non-Xen
kernels.  Or, the kernel image packages could create a symlink with 
the "right" name in /lib/modules/ to the shared modules directory.

Could that trim things down enough to make it sensible to carry PAE and 
non-PAE kernels in Core?
-- 
Lamont R. Peterson <lamont@gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409