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

[Cole Robinson]

On 09/16/2014 09:53 AM, Gerd Hoffmann wrote:
>   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 ...
> 

I'm still working on my reply to laszlo's earlier mail, but one thing I want
to point out is that virt-install is still an option, and in fact much easier
to describe in documentation, etc.

The ideal split IMO is:

- virt-manager only provides an option for using the recommended config using
distro packages, and disables the option with a useful error if no distro
packages available
- everything else we document with virt-install/virt-xml
- editing qemu.conf shouldn't be part of any standard recommendation and only
reserved for people who really know what they are doing

I like the idea of a .d directory, and I'm sure libvirt would find other uses
for sharing .d directory infrastructure, but yeah it'll definitely be a fair
chunk of work to support it, document a public ini format, then expose that
over libvirt APIs (since virt-manager can't depend on reading it directly
since we have to handle the remote machine case).

I think for now it's fine to add a libvirt build option like ./configure
--distro-nvram-default $FD:$VARS or similar

- Cole