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