On Thu, Nov 16, 2006 at 02:11:03AM +0000, John Levon wrote:
> On Thu, Nov 16, 2006 at 01:56:18AM +0000, Ewan Mellor wrote:
>
> > > > vm.grub.cmdline
> > >
> > > I'm not too happy with the eternal encoding of "grub" as the only internal
> > > method. It doesn't cover other methods, and, for example, on Solaris, we
> > > won't
> > > be using grub at all.
> >
> > I can understand the concern with naming, but the semantics of "grub"
> > include specifically that the grub config file will be parsed. Think
> > about it from the point of view of the guest, and upgrading of that
> > guest. You want to be able to say "I know that this grub config file
> > will be parsed, and therefore if I change it, the right thing will
> > happen". If the boot method is "unspecified internal method", then what
> > does that mean in terms of configuring the guest?
>
> I don't quite understand what it's supposed to do though. The only thing
> pygrub
> supports is --entry anyway.
>
> I'm suggesting that kernel_internal have things such as:
>
> .bootloader (bootloader path)
> .kernel
> .ramdisk
> .args
>
> For running domains, the last three would be filled in. For created domains,
> they would typically be blank, but not necessarily. The way Solaris uses
> pygrub, they can be non-blank.
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.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home