On Mon, Nov 20, 2006 at 05:54:36PM +0000, Ewan Mellor wrote:
> vm has two mutually exclusive groups: "pv", and "hvm", with the fields
>
> vm.pv.bootloader
> vm.pv.entry
> vm.pv.kernel
> vm.pv.ramdisk
> vm.pv.args
>
> vm.hvm.boot
>
> pv means "use the PV domain builder, and pass the entry, kernel, ramdisk, and
> args to the specified bootloader".
>
> If bootloader is empty but kernel is specified, then this means take the
> kernel and ramdisk from domain 0. Otherwise, bootloader is a path to the
> bootloading script.
>
> The semantics of entry, kernel, ramdisk, and args are specific to the
> bootloader in use. You get given all those options, and it's up to the
> bootloader to do something sensible, including ignoring some or all of the
> specified options.
I think 'entry' needs renaming as it's only really meaningful for a menu.lst
based method.
Your description above doesn't cover the case where neither bootloader NOR
kernel are set. With my changes, this uses the 'default' bootloader (namely
pygrub). This needs spelling out in the API doc.
Also of interest are what do you see if you have a blank 'kernel' line and you
boot. Do you get back in 'vm.pv.kernel' what pygrub chose for you, or nothing?
Same for others.
I'd actually prefer the latter, because it makes sense for what you put in to
be what you get out, and in the case of 'grubxen' port, it'd be /impossible/
for the domain to report the kernel chosen back out. This should probably be a
informative note in the API docs.
regards
john
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home