Mailing List Archive

[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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Ewan Mellor wrote:
> [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?
>

What about support for other boot loaders? SLES for example uses
domUloader. How would this be specified? Although moving forward,
particularly with the work John has been doing, I'm thinking we should
just be using pygrub. Not sure why we were using domUloader anyway and
the person with some context behind this decision is not available ATM.

Jim


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

On Wed, Nov 15, 2006 at 06:08:27PM -0700, Jim Fehlig wrote:

> Ewan Mellor wrote:
> >[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?
> >
>
> What about support for other boot loaders? SLES for example uses
> domUloader. How would this be specified? Although moving forward,
> particularly with the work John has been doing, I'm thinking we should
> just be using pygrub. Not sure why we were using domUloader anyway and
> the person with some context behind this decision is not available ATM.

What would that take? As I understand it, domUloader has the same
semantics as pygrub, in that the guest kernel's permanent home is the
guest filesystem, and it is booted non-HVM. Is the difference that domUloader
doesn't parse the grub configuration? What does it do instead?

I wouldn't mind adding support for domUloader necessarily, but it does
seem redundant at first glance, so perhaps it would be better for SuSE
to move to pygrub like you suggest. In that case, I don't think it's
worth it to put the fields into the Xen-API.

Ewan.

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

On Wed, Nov 15, 2006 at 09:44:05PM +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.

> 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?

I can't see how it could. Also, I find it somewhat worrying that this implies
that I can't see the kernel/ramdisk/extra chosen by pygrub when it is used.
Shouldn't I be able to see these no matter what? Imagine a "show me all domains
running linux-2.7.19-security-hole" style things.

> > 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?

Currently this would have to happen in two places: xm/create.py and inside
xend. I presumed that create.py only existed because the .py-backend for xend
'new' operation isn't yet implemented, and xm create because xm new ; xm start

> > 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.

I wish I had more time to follow up on these things, but I'll certainly ask
where confusion/problems arise. Is there a "constant-latest" link for the API
spec? Or maybe even a wiki?

regards
john

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

On Thu, Nov 16, 2006 at 01:32:35AM +0000, Ewan Mellor wrote:

> guest filesystem, and it is booted non-HVM. Is the difference that domUloader
> doesn't parse the grub configuration? What does it do instead?

More generally it's not inconceivable that people might like to use their own
script or something for the bootloader, and I think it's useful to be able to
expose that.

Another thought: your model assumes that only HVM guests can boot entirely
independently. This might not be true in the future (xen grub port, etc.); I
think it needs renaming to not imply HVM.

regards,
john

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

On Thu, Nov 16, 2006 at 01:35:06AM +0000, John Levon wrote:

> On Wed, Nov 15, 2006 at 09:44:05PM +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?

To put it another way, how would a Solaris Xend know that a Linux domU
needed to be booted using pygrub, versus a Solaris domU, that would need
to be booted using Mechanism X?

This discussion would be a lot easier if I knew what Mechanism X is ;-)
What booting interface are you thinking of using?

> > 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?
>
> I can't see how it could. Also, I find it somewhat worrying that this implies
> that I can't see the kernel/ramdisk/extra chosen by pygrub when it is used.
> Shouldn't I be able to see these no matter what? Imagine a "show me all domains
> running linux-2.7.19-security-hole" style things.

I was hoping to reserve the possibility that "grub" didn't mean
"pygrub", it could also mean "real grub, ported to Xen, running inside
the guest". Wherever possible, it seems sensible to avoid parsing the
guest filesystem.

For that reason, I wouldn't expect you to be able to find out from
domain 0 what the guest will do when it boots, and so you wouldn't be
able to do what you suggest above (from domain 0).

I presume that for a Solaris dom0, you wouldn't necessarily be able to parse
the guest's ext3 filesystem (for example) and so you would expect to
have that restriction in any case.

> > > 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?
>
> Currently this would have to happen in two places: xm/create.py and inside
> xend. I presumed that create.py only existed because the .py-backend for xend
> 'new' operation isn't yet implemented, and xm create because xm new ; xm start

Yes, we'd be expecting xm to be a parsing and marshalling layer, nothing
more, and certainly nothing in the way of semantically important
decisions like implicit bootloader selection.

> > > 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.
>
> I wish I had more time to follow up on these things, but I'll certainly ask
> where confusion/problems arise. Is there a "constant-latest" link for the API
> spec? Or maybe even a wiki?

xen-unstable has the spec now -- that's the canonical latest version.
It's in docs/xen-api.

Ewan.

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

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.

> xen-unstable has the spec now -- that's the canonical latest version.
> It's in docs/xen-api.

d'oh - thanks!

john

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

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Ewan Mellor wrote:
[snip]
>> What about support for other boot loaders? SLES for example uses
>> domUloader. How would this be specified? Although moving forward,
>> particularly with the work John has been doing, I'm thinking we should
>> just be using pygrub. Not sure why we were using domUloader anyway and
>> the person with some context behind this decision is not available ATM.
>>
>
> What would that take? As I understand it, domUloader has the same
> semantics as pygrub, in that the guest kernel's permanent home is the
> guest filesystem, and it is booted non-HVM. Is the difference that domUloader
> doesn't parse the grub configuration? What does it do instead?
>

Looks like your latest proposal will support domUloader, i.e.

vm.pv.bootloader
vm.pv.entry
vm.pv.kernel
vm.pv.ramdisk
vm.pv.args

domUloader does get kernel/ramdisk from guest filesystem but does not
parse the grub configuration, instead relying on input parameters. E.g.
a legacy config file entry for domUloader might be

bootloader = '/usr/lib/xen/boot/domUloader.py'
bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen'

The bootloader params could be stuffed in vm.pv.entry or sprayed across
entry, .kernel and .ramdisk.

> I wouldn't mind adding support for domUloader necessarily, but it does
> seem redundant at first glance, so perhaps it would be better for SuSE
> to move to pygrub like you suggest. In that case, I don't think it's
> worth it to put the fields into the Xen-API.
>

Well, I wasn't thinking of guests that may not even have grub installed
like netware. So we will need to stay with domUloader.

Even for SuSE linux guests it appears domUloader is better approach - at
least those with reiser fs. I've been told the user-space tools for
reiser suck and hence pygrub has never worked well with such images.

Jim


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

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.

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.

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.

regards
john

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

On Mon, Nov 20, 2006 at 04:46:42PM -0700, Jim Fehlig wrote:

> Ewan Mellor wrote:
> [snip]
> >>What about support for other boot loaders? SLES for example uses
> >>domUloader. How would this be specified? Although moving forward,
> >>particularly with the work John has been doing, I'm thinking we should
> >>just be using pygrub. Not sure why we were using domUloader anyway and
> >>the person with some context behind this decision is not available ATM.
> >>
> >
> >What would that take? As I understand it, domUloader has the same
> >semantics as pygrub, in that the guest kernel's permanent home is the
> >guest filesystem, and it is booted non-HVM. Is the difference that
> >domUloader
> >doesn't parse the grub configuration? What does it do instead?
> >
>
> Looks like your latest proposal will support domUloader, i.e.

Yes, that's another reason that I came around to John's way of thinking ;-)

> vm.pv.bootloader
> vm.pv.entry
> vm.pv.kernel
> vm.pv.ramdisk
> vm.pv.args
>
> domUloader does get kernel/ramdisk from guest filesystem but does not
> parse the grub configuration, instead relying on input parameters. E.g.
> a legacy config file entry for domUloader might be
>
> bootloader = '/usr/lib/xen/boot/domUloader.py'
> bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen'
>
> The bootloader params could be stuffed in vm.pv.entry or sprayed across
> entry, .kernel and .ramdisk.

Yes, you'd just use kernel = "hda2:/boot/vmlinuz-xen",
ramdisk="/boot/initrd-xen" in this example, I think. That seems good to me.

Ewan.

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

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Wed, Nov 22, 2006 at 02:09:34PM +0000, Ewan Mellor wrote:

> > 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?

It isn't that I have something in mind particularly. It's just that, firstly,
the legacy config has 'bootloader_args', and it seems kind of odd to map it to
'entry', and secondly, that we can't really predict how we'll be booting
domains in 10 year's time. I agree it's just a quibble, but I don't see a
problem in using 'bootloader_params' or 'bootloader_args'.

> > 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.

Well, the intention is that given a random domain, xend knows by default how to
boot it, thus making the common case ("boot the default"/"give me grub menu")
the natural default with no extra configuration needed.

regards,
john

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

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api