Dan Magenheimer wrote:
> With RHEL6 beta 2 now available, I am once again trying
> to get a fresh Xen 4.0-testing tree booted "underneath" it.
> (This is for my Xen development machines, no political
> comments please ;-) I'm sure there are some similarities
> between this process and the process under FC13(?);
> any help appreciated.
>
> I have cloned xen-4.0-testing.hg and successfully built
> a full set of Xen "stuff" with "make world". The dom0
> kernel that is installed in /boot is vmlinuz-2.6.31.13
> I used the default config (and default responses to
> the "make oldconfig" that seems to be run by default)
> to build this dom0 kernel.
>
> 1) Is there a better config file to start from for
> building the dom0 kernel? For example, I see that
> CONFIG_SYSFS_DEPRECATED{,V2} are not set, and I
> am fairly confident that this kernel will not boot
> a RHEL6 environment without it.
RHEL6 requires this not to be set, i.e., the redhat .config's have:
# CONFIG_SYSFS_DEPRECATED_V2 is not set
So, general rule of thumb around here: build RHEL6 kernel on
RHEL6(guest). The beauty of a 2.6.32 guest (disk image) is that
it can be a PV guest or an HVM guest, using just two different
xen guest config files (surely simplifies my testing efforts --
far less guest disk images, kernel copy/installs, etc.), of course
only one of them running at any one time, unless you like 'boom'! ;-)
Following that rule:
(a) install/make a RHEL6 xen guest: PV or HVM (although PV is much faster)
on your favorite (working?) dom0/xen host.
(b) install devel pkg & build the variant kernel you want in that guest
(c) ... and for the issue below, in (2):
> 2) What do I use to build the initrd? The standard
> "mkinitrd initrd.img version" yields LOTS of error
> messages and, in any case, I believe that dracut
> should now be used instead of mkinitrd?
(c)... continued....
mkinitrd is a script in rhel6 that invokes dracut with
the proper params to make an initrd.
of course, in mkinitrd fashion, it uses the current
host config to determine what goes into the initrd.
So a PV guest will be better, since it'll include the xen-[blk|net]front
drivers (et. al.) so you can build a -dom0 with needed boot drivers.
> 3) Should I be using a different/newer pvops kernel?
> IIRC, there is an issue with booting >=2.6.32
> pvops dom0 with pre-xen-unstable hypervisors? Or
Not necessarily. Do this all the time: RHEL6-domU on RHEL5-dom0.
... maybe some intermediate versions of xen dont work w/pv-ops kernel,
but it does with rhel5-dom0/xen.
> is that fixed in latest xen-4.0-testing?
good question! curious minds want to know....
> 4) Anything else I should watch out for? E.g. recent
> tool changes due to udev or xencommon or ???
>
> Most of these final steps are black magic to me and
I haven't followed the how-to-build a dom0 from F12/F13,
so don't know the black magic to makde a dom0 from a 2.6.32 base.
I'm sure the magic has to do w/making the dom0 kernel in synch
with xen HV base code (HV calls, defines, etc.), but I believe how that is done
in the
late Fedora trees is quite diff. than how it was done in rhel5 sources
(due to pv-ops kernel design).
> I've been using a recipe on RHEL5uX for them for
> so long, I'm not even sure what to look for if
> (when) the dom0 boot fails... and trial and error
> is not very productive for this kind of thing.
>
> Thanks,
> Dan
>
>
Hope some of the above helps. Good luck!... Don
____________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home