Re: [Xen-API] grub/cmdline

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

Ewan Mellor wrote:
[snip]
> I'm coming around to your way of thinking.  How about this:
>
> 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.
>
> If the bootloader is pygrub, then the menu.lst is parsed if present, the
> specified entry is selected if that makes sense, and if the the menu.lst is
> not present, the specified kernel/ramdisk is used, or an autodetected kernel
> is used if nothing is specified.  The given args are appended to the kernel
> command line, no matter which mechanism is used for finding the kernel.
>
> hvm means "use the HVM domain builder, hvmloader and boot using a BIOS", with
> hvm.boot specifying the order of boot devices.
>
> How does that sound?
>
> Ewan.
>   
Has everyone agreed on this approach?  I would like to get this scheme 
working with domUloader but see that no work has been done in the code 
to support this proposal.  If agreement has been reached I could begin 
cooking up some patches - unless of course work is already being done.
Jim


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api