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. Daniel -- |: 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 et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
