Hi,
one of the troubles with the way xen boots paravirtualized kernels
is that you get the kernel and the initrd from domain 0, whereas
modules that are later loaded are on the domU filesystem.
This is a management headache: You must ensure that the kernel
and initrd you configure in dom0 for domU booting are in sync
with the kernel (modules) in domU.
Jeremy Katz has thankfully created some infrastructure to allow
plugging in bootloaders instead and contributed pygrub.
I extended the infrastructure a bit and added another bootloader.
Unlike pygrub it does not offer a menu and does not parse the
grub menu.lst; it's meant for paravirtualized domains and thus
we accept that the booted kernel is selected differently. By e.g.
a symlink, if one wants to control it from the domU. The bootloader
is called domUloader.
domUloader parses the bootentry (passed via --entry=) and the disk
setup (passed via --disks=). It then sets up loop devices as needed,
scans for partition tables (the exported disks / loop devs can
contain partitions) using kpartx (dm) and sets them up, so the kernel
and initrd can be copied to a temporary location in dom0.
The bootentry may contain a dev: prefix describing the partition
(from a domU perspective!) where kernel and initrd are located,
followed by kernel filename and (optional) initrd filenames relative
to the filesystem on dev:.
The kernel and initrd filename can also be relative to the domU root
filesystem. The domUloader than evaluates /etc/fstab found in the
root filesystem (passed via --root=) to locate kernel and initrd.
Afterwards everything is cleaned up. (We use the destructors, so
python reference counting makes sure this also happens when
exceptions occur.)
Unlike pygrub, it does use any code to understand filesystems or
partitions; the filesystem support comes from the dom0 kernel,
whereas kpartx (from multipath-tools) is used for the knowledge
of partitions and for setting up device-mapper.
More details by calling domUloader.py --help.
An example config could look like this:
bootentry = hda2:/vmlinuz-xen,/initrd-xen
bootloader = /path/to/domUloader.py
disks = ['phy:VG_Xen/LV_dom5,hda,w', 'file:/var/lib/xen/test,sda,w']
...
assuming LV_dom5 has a second partition with a filesystem containing
vmlinuz-xen and initrd-xen in its root fs (the /boot partition).
or
bootentry = /boot/vmlinuz-xen,/boot/initrd-xen
bootloader = /path/to/domUloader.py
root = /dev/hda1
disk = ...
assuming that the root filesystem has an /etc/fstab that points the
way to /boot/vmlinuz-xen. (Does not need to be a separate FS.)
The following three mails will contain
(1) A patch to xend/XenDomainInfo.py, xend/XenBootloader.py and
xm/create.py, making sure that all the needed info is passed
to the bootloader and also stored for reuse on rebooting.
(2) A patch to make pygrub accept the new parameters passed by
XendBootloader.py (but so far pygrub just ignores them ...)
(3) The domUloader.py script.
Patches are against a working copy (8259) on my laptop; if noone
else will, I can create diffs against mercurial tip.
I hope this is useful to someone and can be integrated into the
Xen distribution.
Enjoy,
--
Kurt Garloff, Head Architect, Director SUSE Labs (act.), Novell Inc.
pgpxvOk3X9XRX.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home