On Mon, Dec 11, 2006 at 04:26:05PM -0700, Jim Fehlig wrote:
> 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.
I'm doing it; I'm nearly done in fact. Watch this space.
Ewan.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home