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

[Laszlo Ersek]

On 09/16/14 15:53, 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.

I agree that having to edit /etc/libvirt/qemu.conf is not 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.

Those are different, and I dislike them for different reasons.

(1) Editing the domain XML is fine in general, but not when you are
*creating* the virtual machine. Once you've created a VM in
virt-manager, you can easily customize it with virsh edit, but we're
speaking about selecting the firmware *during* VM creation.

(2) Dropping a file to "/etc/libvirt/firmware.d/" requires the same
privileges as editing "/etc/libvirt/qemu.conf". Assume the user has none
of those privileges.

>> 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 agree completely.

That's why I'm pushing for

> - "I got a binary and a matching varstore template, use these".

Because that's generic. It can co-operate with any firmware builds. It
doesn't matter *why* you are not going with the distro default OVMF
build -- because it's old, or because it had the wrong build options, or
because it doesn't even exist.

It also requires minimal tooling support.

It requires *slightly* more work from the user. Namely, you can add a file

  /usr/share/doc/edk2.git-ovmf-x64-0/README

to your RPM, and explain in one paragraph the two pathnames the user
needs to paste.

When I suggested this option, I specifically had Fedora in mind -- I
didn't forget about it. The option would cover Fedora nicely.

Thanks
Laszlo