Bug 1295146 - RFE: provide a bios=uefi XML convenience option
RFE: provide a bios=uefi XML convenience option
Status: NEW
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-02 17:17 EST by Cole Robinson
Modified: 2017-07-27 10:57 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Cole Robinson 2016-01-02 17:17:36 EST
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
Comment 1 Laszlo Ersek 2016-01-08 15:30:21 EST
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.
Comment 2 Daniel Berrange 2016-10-19 07:27:31 EDT
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.
Comment 3 Cole Robinson 2016-10-19 13:15:38 EDT
I replied on list, but yeah it looks fine from my standpoint
Comment 4 Laszlo Ersek 2016-10-31 08:46:48 EDT
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 15:27:36 EST
(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

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