This is a proposal for modifying the interface for domU bootloaders (i.e.
something that provides us with a kernel and ramdisk file with which the domain
can be booted). The current interface, as is, has a number of problems,
including:
1) the first disk specified is assumed to be the disk containing the files
2) 'bootentry' is highly pygrub-specific. There is no easy facility to specify
any options for custom bootloaders
3) bootloaders are forced to return configuration params like 'args', since
the code assumes it knows all with regards to image.py
4) users need to configure 'bootloader' by hand. There's little facility for
standard Xen-shipped bootloaders that can be easily chosen in the config
file
In addition, the common case of "just get these files off the filesystem at
this device" is not, IMO, well-covered by pygrub, the only bootloader shipped
so far:
1) Filesystem support requires a C/Python interface which contains a lot of
glue code, typically interfacing a C library to pygrub's internal API
2) Filesystem support needs to be delivered into the correct python
directory, and carefully match the exact internal API used by pygrub
3) There are possibly licensing inflexibilities with the fs-specific python
modules. Not really a big problem with the standard open OS's filesystems,
but I can easily imagine this being a problem with vendor filesystems, or
other operating systems.
4) The concept of "retrieve a file from this fs image" seems to be generically
useful outside of the Xen project context; forcing a Python API for this
functionality seems a lot less general than it should be.
5) IMO, it doesn't make sense to be using grub config files anyway. grub can't
boot domU's natively (typically), and pygrub obviously can't do vice versa.
The config syntax has a lot of things that aren't relevant to the domU case.
At least, the pygrub approach needs to be optional rather than the primary
bootloading method.
This proposal covers three parts: the configuration file changes, the
bootloader interface, and the new 'root' bootloader.
Config file
-----------
Taking a lead from the disk configuration, the 'kernel' and 'ramdisk' options
are extended to the format:
kernel = "method:method-params"
ramdisk = "method:method-params"
If no method is specified, it defaults to 'path'. The path method is a null
bootloader that just sets the output parameters to the file specified, i.e.
these are equivalent:
kernel = "/path/to/vmlinuz"
kernel = "path:/path/to/vmlinuz"
IOW, "path" means a file is on the dom0 fs tree.
The options 'bootloader' and 'bootentry' are removed: the method specification
replaces 'bootloader', and (for the 'grub' method) the method-params replaces
'bootentry'.
In addition, a new option 'bootdisk' is added. This is a method-specific value
that's interpreted as desired by the bootloader method. This is required if not
using the 'path' bootloader.
The ramdisk method, if 'ramdisk' is present, must equal the 'kernel' method.
Bootloader interface
--------------------
The Xen python code parses the 'kernel' value into 'method' and 'params', then
searches for a bootloader handler matching 'method' as follows:
/usr/lib/xen/boot/bootload-<method>
<auxbinpath>/bootload-<method>
/etc/xen/scripts/bootload-<method>
When found, the bootloader is invoked as follows:
-b <bootdisk> -k <kernel's method-param> [-r <ramdisk's method-param>] \
-d <disk1> [ -d <disk2> ... ]
and is expected to return, on stdout, any of these lines:
kernel=/path/to/kernel/file
ramdisk=/path/to/ramdisk/file
extra=...
root=...
cmdline_ip=...
If some of these are omitted, the config file's version is used.
This hopefully is generic enough to deal with, for example, Kurt's mount -o
loop approach, by defining a /usr/lib/xen/boot/bootload-loop script, as well as
a 'grub' method which will be a modified pygrub.
To deal with the most common case, I'd also like to propose a standard 'root'
bootloader:
'root' bootload method
----------------------
A bootloader 'root' should be delivered as /usr/lib/xen/boot/bootload-root. It
will match up a bootdisk entry such as 'sda3' against the disk specifications
passed in and construct a path to the fs image residing on a file or device
node. Once the FS image is located, it will call out to a generic OS-provided
helper called 'readfs' as follows:
readfs -n -i <image> -o /var/cache/xen/boot/<file> <file>
This binary will identify the filesystem and read the file given off it,
storing it in the output cache file specified if it has changed since last
invocation.
After doing this for the kernel and possibly ramdisk, bootload-root will print
the locations of the cached files back to the bootloader handler and quit.
The intention for readfs is to provide a generic utility for grabbing files
from an image without having to loopback mount the filesystem. I want to make
this call out to fs-specific helpers so it's possible to boot domU's of
"foreign" operating systems on foreign file systems. In particular I'm very
interested in getting a readfs package integrated into the big free OS's that
are/will be domain 0 (Solaris, Linux, and the BSDs) with a number of backends
for different filesystems.
I already have a rough prototype of this setup for root/grub bootloaders that
seems to work reasonably.
All comments welcomed,
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home