On Fri, Aug 22, 2014 at 12:12:52PM +0200, Laszlo Ersek wrote: > On 08/22/14 11:56, Daniel P. Berrange wrote: > > On Fri, Aug 22, 2014 at 11:38:06AM +0200, Laszlo Ersek wrote: > >> On 08/22/14 10:54, Daniel P. Berrange wrote: > >>> On Fri, Aug 22, 2014 at 10:27:29AM +0200, Laszlo Ersek wrote: > >>>> On 08/21/14 11:05, Daniel P. Berrange wrote: > >>>>> So the user has the ability to specify a arbitrary BIOS in the XML, > >>>>> but unless it matches one of the ones listed in the libvirt config > >>>>> they aren't going to be able to start the guest. What can we do > >>>>> about this, as it doesn't really seem like a great position to be > >>>>> in. > >>>> > >>>> I disagree. Users who use virt-manager (for which patches still have to > >>>> be written, to expose this feature) won't put arbitrary strings in the > >>>> <loader> element; virt-manager should offer a minimal choice between > >>>> "BIOS" vs. "UEFI". > >>>> > >>>> Users who are hard-core enough to hack the domain XML by hand are > >>>> expected to provide good values. > >>> > >>> The problem I'm raising is that it is *not* sufficient to merely > >>> provide good values in the XML here. You can't simply deploy a > >>> custom OVMF file and update your XML, because this code is relying > >>> on values in the libvirtd.conf configuration file. > >> > >> If the domain XML spells out both <loader> and <nvram>, then both should > >> be updated manually by the user (if the VM's old nvram is not compatible > >> with the new loader). This would include the user either instantiating > >> the new varstore for the VM, or removing the <nvram> element (so that > >> the new default template can take effect). > >> > >> If the domain XML doesn't spell out <nvram> (either genuinely, or > >> because the user removed that element, see above), then yes, you need to > >> edit /etc/libvirt/qemu.conf. > >> > >> I don't see a problem with that. You won't keep installing OVMF_CODE.fd > >> files in random locations in the host filesystem. You might be > >> developing OVMF and install various ad-hoc builds, but those would go to > >> the same location (same pathname), hence it would have to be added only > >> once to the qemu.conf file. > > > > Well I do see a problem with editing qemu.conf for this, particularly > > when there is a very straightforward way to avoid that need which I > > have outlined here. It is crazy to force these extra hoops onto people > > OK. > > But, if you don't provide a default map in some central config file, for > at least the system-wide OVMF installation(s), how do you save people > from the exact same burden (== manual varstore instantiation), when they > try to create a brand new UEFI virtual machine that uses one of the > system-wide OVMF filesets? Libvirt won't know where to copy the varstore > from. Having a default map in libvirt and in qemu.conf is still acceptable for the common case. I just want to make sure that if the user wants to provide a non-default BIOS in <loader> they can still get the NVRAM automatically created from a template, without having to edit qemu.conf and restart libvirtd. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list