On Thu, Jan 23, 2014 at 05:25:18PM +0100, Laszlo Ersek wrote: > On 01/23/14 15:58, Daniel P. Berrange wrote: > > I disagree that users setting their persistent boot variables form > inside the guest fall in the same category. That feature is an > unalienable part of UEFI. > > > The goal we have is that the XML description should fully describe > > the configuration of a VM. Having a situation where the XML config > > only partially describes the setup, and the rest is delegated to > > a config embedded in the firmware image is not something we wish > > to support. > > I understand. > > > IMHO what we need to tackle here is the inability to properly > > configure the firmware boot order from QEMU / libvirt. ie make > > it possible for users to fully control it via libvirt XML. > > We'd face two hurdles towards this goal. > > - The first is that you'd need to get a basically free-form string > through. Technically it wouldn't be very hard, but it's completely > foreign from the current bootindex concept in libvirt/qemu. > > In UEFI, "bootable device" can refer to something that's just a chunk of > guest RAM for qemu. > > - The second hurdle is that you couldn't *offer* the host-side user sane > choices (device paths for UEFI boot options) beyond a limit. This is > because device paths come to existence by the execution and stacking of > UEFI drivers, and their binding to devices. Ok, I think I understand the problem more now. Would there be any sense in defining an generic <boot dev="config"/> option to indicate that UEFI should try the config settings that the user has defined inside the UEFI config partition ? If we use the strict=on|off setting, the user's config settings are only usable as the very last fallback option, once all the explicitly listed options have been tried. If we had a <boot dev="config"> we would perhaps be able to express ordering such as <boot dev="hd"> <boot dev="config"> <boot dev="cdrom"> without having to invent a impossibly complicated grammer to express all possible UEFI bootable device options ? 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