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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
