Re: [Xen-API] grub/cmdline

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

[Bringing Tim into the conversation]

On Wed, Nov 15, 2006 at 08:10:59PM +0000, John Levon wrote:

> 
> What are grub/cmdline's semantics? It appears to be undocumented.
> 
> I'm trying to work out what changes are needed for the bootloader changes I'm
> making. The current .py changes I'm making after discussion with Tim Deegan
> are:
>  
> use_bootloader (new: if set, use a bootloader. == 1 is implied if bootloader 
> is
> set, or if kernel is not set)
> bootloader/bootloader_args (as before, default to pygrub if use_bootloader is
> set)
> 
> As far as I can work out, if boot_type is 'kernel_internal', then this
> corresponds to setting use_bootloader to 1. It's not clear how
> bootloader_args is represented in the API - is it?
> 
> Currently it seems that 'bootloader' is returned when get_boot_method is
> called, but the API docs says it's an enum of boot_type? Well actually it
> returns '' now.

I was looking at this again just the other day.  Here's where I got to --
let's see how it fits in with what you've got:


vm has three mutually exclusive groups: "grub", "external", and "hvm", with
the fields

vm.grub.cmdline

vm.external.kernel
vm.external.args
vm.external.initrd

vm.hvm.boot

Grub means "parse the grub config file inside the guest, and boot
appropriately".  grub.cmdline is _supposed_ to be a way of specifying "select
this particular label from the config file" or "append these parameters to the
kernel command line before you boot" or mixtures of the two.  Is that feasible
with one string?

External means "take the specified kernel from dom 0, and give it the given
args and initrd".

HVM means "run hvmloader and boot using a BIOS", with hvm.boot specifying the
order of boot devices.

Kernel_internal is unnecessary.

How does this fit with your thinking?

> Presumably when 'xm create' is implemented in terms of 'xm new', then the
> defaults described above would be implemented in xend only.

I'm not sure what you mean by that.  Could you elaborate?

> Is the API document being updated to reflect the code changes and vice versa?

That's the intention!  If there's confusion, asking here is definitely the
right thing to do -- there are lots of things that are unimplemented still,
and still some things (like booting) that are unclear in the docs too.

Cheers,

Ewan.

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