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