On Wed, Dec 03, 2008 at 05:23:35PM +0000, John Levon wrote:
> On Wed, Dec 03, 2008 at 04:50:36PM +0000, Daniel P. Berrange wrote:
> > > This is a regression over previous releases, where -l works for both.
> > > (And that was a good fix, since people *always* accidentally use -l
> > > instead of -c and get very confused. Can it be fixed?
> > That was a bug in a previous release.
> One of those bugs users love
> > We need to have distinct meaning for them, because many distros images
> > & hypervisors will support both kernel+initrd and BIOS based
> > provisioning, so we need to be able to distinguish between them.
> Isn't the correct solution to add another virt type (--hvm-whatever),
> not make life miserable for the users?
> At the *very* least, can't we decide whether to try kernel+initrd based
> upon detected OS type? I have a queued patch that adds 'os_type' to each
> of the OSDistro classes.
Unfortunately it varies based on (os type + hv type + hv version).
eg, Xen 3.0.3 cannot do HVM installs off kernel+initrd, but Xen 3.4.0
can, and any KVM can. We really want to prefer kernel+intrd whereever
possible because it allows 100% un-attended automated kickstarts
without needing a network provisioning server.
Perhaps what we really need is a libvirt capabilities XML extension to
indicate what boot targets are supported. We currently have 4 choices
host bootloader (pygrub), kernel+initrd, BIOS boo, and process init
(container based virt only). Even so we still have a problem with talking
to older libvirt which didn't support this.
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
et-mgmt-tools mailing list