[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH 0/3] domUloader
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. Attachment:
pgphd7wQ2Uorj.pgp _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |