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