[Libvir] [PATCH] Solaris dom0 support

Daniel Veillard veillard at redhat.com
Fri Jun 15 09:31:03 UTC 2007


On Fri, Jun 15, 2007 at 03:20:19AM +0100, Daniel P. Berrange wrote:
> On Fri, Jun 15, 2007 at 02:26:36AM +0100, John Levon wrote:
> > On Fri, Jun 15, 2007 at 01:02:16AM +0100, Daniel P. Berrange wrote:
> > 
> > > > > I'm curious as to what the changes for bootloader / kernel are for ?
> > > > > Surely you always have either a bootloader, or a kenrel present in
> > > > > the SEXPR ? So I'm not sure why its neccessary to disable the check
> > > > 
> > > > No, this is not true, and it's not true in Xen too. This is stuff that
> > > > got merged up in my pygrub changes.
> > > > 
> > > > Basically the logic is something like:
> > > > 
> > > > if there is no kernel specified:
> > > >     if there is no bootloader specified:
> > > >         default to pygrub (for Solaris, this will fill in
> > > >         kernel/ramdisk/extra automatically)
> > > 
> > > Ah ha - this is the key clause I was missing. I didn't realize that
> > > XenD could now default to pygrub. The change in logic makes perfect
> > > sense now. Though I wonder if we should add in an explicit element
> > > for  <bootloader>/usr/bin/pygrub</bootloader> to reflect this default
> > > done by XenD...
> > 
> > What would be the reason for this?
> 
> Well to give some form of indication as to how the guest is being booted.
> Perhaps rather than making up a default path, just an empty <bootloader/>
> element would work. The semantics being launch with the default bootloader
> for the platform. That would avoid having to include any specific path
> info

  agreed too, and adding an XML comment 
  <!-- use the default bootloader -->

would IMHO be even more user friendly.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/




More information about the libvir-list mailing list