[virt-tools-list] [virt-manager PATCH RFC 3/4] virt-manager: OVMF support

[Gerd Hoffmann]

  Hi,

> > Then libvirt / virt-manager can pick it up and put it into a menu, with
> > the "expert" entries being hidden by default (simliar to "OS type"
> > selection, where you initially find the common ones only and have to
> > pick "show all options" to get a full list).
> 
> This is nice, but probably a lot of work.

Indeed.  Expecting the user to edit /etc/libvirt/qemu.conf is less work
but also less user friendly.

> In addition, it doesn't cover the case when the user wants to specify an
> ad-hoc OVMF build (binary + varstore template). In my mind that's a
> *primary* use case, unlike SeaBIOS. SeaBIOS is *very* mature, while OVMF
> is just entering the mainstream.

Well, nothing stops me editing the domain xml directly, or drop a file
pointing to 

/home/kraxel/projects/edk2/Build/OvmfX64/DEBUG_GCC48/FV/OVMF_{CODE,VARS}.df

to /etc/libvirt/firmware.d/ for a more comfortable way to pick it.

> I'm probably not very good at suggesting things that concern the long
> term, and/or require technical insight into virt-manager or libvirtd. I
> can only focus on how I want to use OVMF right now, and how I imagine
> users curious about OVMF would use OVMF right now. I'm fine with all and
> any suggestions that provide a superset of that functionality; people
> certainly need to correct me when I'm short-sighted.
> 
> I'd like two easy options for the user, in virt-manager:
> - "use the OVMF stuff that my distro provides as a builtin",

Problem here is that "OVMF stuff that my distro provides" doesn't exist
in fedora land.  So the easy way ("it is the job of the fedora packager
to populate /etc/libvirt/qemu.conf with defaults sensible for the
distro") is out ...

cheers,
  Gerd