Bug 1295146

Summary:	RFE: provide a bios=uefi XML convenience option
Product:	[Community] Virtualization Tools	Reporter:	Cole Robinson <crobinso>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	berrange, crobinso, dyuan, Frodox, kchamart, kraxel, lantw44, lersek, lmen, rjones, Rondom
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-07-27 13:03:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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:

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 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)

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 Berrangé 2016-10-19 11:27:31 UTC

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 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 ***