Bug 1295146 - RFE: provide a bios=uefi XML convenience option
Summary: RFE: provide a bios=uefi XML convenience option
Status: CLOSED DUPLICATE of bug 1605127
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2016-01-02 22:17 UTC by Cole Robinson
Modified: 2018-07-27 13:04 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2018-07-27 13:03:24 UTC

Attachments (Terms of Use)

Description Cole Robinson 2016-01-02 22:17:36 UTC
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:


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:


Comment 1 Laszlo Ersek 2016-01-08 20:30:21 UTC
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)


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.

Comment 2 Daniel Berrangé 2016-10-19 11:27:31 UTC
I've got an impl of this idea here


could you confirm that works from virt-manager POV before i merge it.

Comment 3 Cole Robinson 2016-10-19 17:15:38 UTC
I replied on list, but yeah it looks fine from my standpoint

Comment 4 Laszlo Ersek 2016-10-31 12:46:48 UTC
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.

Comment 5 Cole Robinson 2016-11-14 20:27:36 UTC
(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

Comment 6 Kashyap Chamarthy 2018-02-16 10:08:21 UTC
A related QEMU bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1546084 --  RFE: Define and provide firmware (OVMF, etc) metadata format and file

Comment 7 Laszlo Ersek 2018-07-27 13:03:24 UTC

*** This bug has been marked as a duplicate of bug 1605127 ***

Note You need to log in before you can comment on or make changes to this bug.