For apps to support UEFI right now, they have to jump through some hoops with hardcoding a UEFI path to arch mapping table. See libguestfs code for example: https://github.com/libguestfs/libguestfs/blob/master/v2v/utils.ml#L89 virt-manager uses something similar. It would be helpful if libvirt could provide some XML convenience option to handle arch + uefi + variable mapping for us. I really don't know how it would look but the current solution is definitely suboptimal. Maybe this would involve Gerd's older suggestion of a firmware repo directory that libvirt parses to get info about binaries: https://www.redhat.com/archives/virt-tools-list/2014-September/msg00145.html
I think that Gerd's proposal is good. (I have by now abandoned the idea that virt-manager let me directly specify a firmware binary and a matching varstore template; that's probably an "expert level" option the kind of which virt-manager traditionally leaves to "virsh edit" or virt-install.) The problem with the arch->(fw binary, varstore template) mapping is that it is not flexible enough. Even for the same architecture, you might want to offer different firmware binaries (each with its matching varstore template). It is hard to extract the independent traits of these firmware binaries and offer a (trait1, trait2, ..., trait_n) -> (fw_binary, varstore_template) mapping. Which is why I think Gerd's proposal is great: it doesn't try to formalize this too much, just gives a textual description of what is what. Maybe some of the more common filtering options could be stored as "tags", such as: - if it supports secure boot - what guest arch it is for - if it provides / requires SMM - if it supports IPv6 networking - if it contains HTTP netboot facilities - etc Tags would let us gradually introduce more and more, as the firmware acquires new features.
I've got an impl of this idea here https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html could you confirm that works from virt-manager POV before i merge it.
I replied on list, but yeah it looks fine from my standpoint
Hi, the upstream report in <https://bugs.launchpad.net/virt-manager/+bug/1637693> seems remotely related. Can you guys please take a look there? Thanks.
(In reply to Laszlo Ersek from comment #4) > Hi, the upstream report in > <https://bugs.launchpad.net/virt-manager/+bug/1637693> seems remotely > related. Can you guys please take a look there? Thanks. Sorry I missed this NEEDINFO :/ I replied in the launchpad bug now, but I don't think it's related to Dan's patches, since virt-install/virt-manager aren't using those yet
A related QEMU bug: https://bugzilla.redhat.com/show_bug.cgi?id=1546084 -- RFE: Define and provide firmware (OVMF, etc) metadata format and file
*** This bug has been marked as a duplicate of bug 1605127 ***