On Tue, Nov 21, 2006 at 04:26:52AM +0000, John Levon wrote:
> 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.
What would you want to call it? I was thinking that if you have a bootloader
with a menu, you'd use entry, and if you didn't, entry would be blank. Is
there something else that you'd want to use this field for?
> 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.
I'd intended that this particular case would be a flagged error, and pygrub
would only ever be used if explicitly specified. I don't have a strong
opinion on that -- we could do it your way if you prefer.
> 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.
Yes, I'd prefer the latter too. Let's go with that.
Ewan.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home