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

[Laszlo Ersek]

On 09/16/14 16:41, Cole Robinson wrote:
> On 09/16/2014 07:17 AM, Laszlo Ersek wrote:

>> The easiest way for upstream users to play with *fresh* OVMF right now
>> is to install Gerd's RPMs (and keep updating them)
>> <https://www.kraxel.org/repos/>. The RPM you care about most is
>> edk2.git-ovmf-x64, and the files in it that you care about most are
>>
>> /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
>> /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd
>>
>> These are not "standard" pathnames on any distro I know of or can
>> imagine, and that's not a coincidence -- these files shouldn't conflict
>> with anything anywhere. But, you *do* want to make them easily available
>> for users in virt-manager.
>>
>> One thing you can say is that whoever installs this RPM better modify
>> the "nvram" stanza in "/etc/libvirt/qemu.conf", and then libvirt will
>> "know" about it, both for the (original) purpose of locating the
>> matching varstore template, and for the (proposed) purpose of offering
>> it as an option to virt-manager (in the capabilities XML or elsewhere).
>>
>> The other possibility is a notice for users that they simply navigate
>> virt-manager to the "Customize before install" dialog, where they can
>> freely provide an OVMF binary and its matching varstore template file.
>>
>> We have three guidelines / facts here:
>> (a) Dan convinced me that users should be able to set these values
>> without reconfiguring libvirtd,
>> (b) you're saying that OVMF should be easy to use,
>> (c) the currently easiest way to use *fresh* OVMF (which you really do
>> want to use) is Gerd's RPMs.
>>
>> These together are telling me that you can't *bury* the custom OVMF
>> selection widgets on some obscure dialog. Right now the optimal way for
>> upstream users *is* the custom OVMF selection. It might appear as a nuts
>> n' bolts view, but right now that provides the most direct route for
>> upstream users.
>>
> 
> I agree with your points, but we are talking about different levels of easy.
> 
> Yes, the easiest way to consume bits right now is using gerds custom repo.
> However anyone that will go to that effort will also likely be fine consuming
> a virt-install command off a wiki page. They aren't who we should target with
> virt-manager UI IMO.

Well, if you care for one specific data point :), I absolutely hate
virt-install for anything *else* than scripting. It is fully unusable
interactively. I'd certainly like to continue OVMF development using
virt-manager. I like the GUI and the high level abstraction wherever my
work *doesn't* focus. Just because I work on OVMF I shouldn't be
required to fight virt-install *interactively*. (Virt-install is an
awesome tool for scripting.)

Anyway you know your users, so I'll definitely defer to you. :)

> I'm thinking about the future when a distro is shipping an ovmf package.
> People that want to use VMs + UEFI shouldn't need to know the paths to the
> files, etc. The instructions should be along the lines of 'find the Firmware
> option in the UI and change it to UEFI'.

Okay.

>>> Granted, with that approach libvirt will have to hardcode OVMF paths to
>>> inspect, but that's better for clients, and actually much simpler if other
>>> distros package their bits at different locations, they can just patch libvirt
>>> and well behaved tools should do the right thing.
>>
>> Again, the first components of the nvram list elements in qemu.conf
>> could double for this purpose (so no patching needed), but, again :),
>> DanPB expressily wanted to allow users to work with custom OVMF installs
>> without changing system-wide configuration.
>>
> 
> Right, we aren't taking that option away, I'd just prefer not to expose it in
> the UI. More for us to maintain + test for an audience that would be nearly as
> well served with a virt-install or virt-xml example.

Please expose it somewhere.

Let's assume that the custom firmware binary + varstore template widgets
are indeed useless for end-users, and only useful for developers. In
that case I don't mind at all if the options are buried. But they should
exist on the GUI, somewhere. I think developers should be first class
citizens of your target audience.

> Users aren't forced to edit qemu.conf, only 'forced' to use virt-install instead.

That's correct, apologies if I misrepresented this, it wasn't my intent.
I just don't like virt-install when working interactively :(

> And I'm not forcing libvirt developers to do anything: if the suggestion is
> rejected, then we will cope. FWIW I'm happy to patch libvirt to do what I
> want, time permitting I'll take a crack at it later today + review michal's
> patches.

Understood. Thanks.

> [...] if people
> want to use custom ovmf paths we would not recommend virt-manager, and instead
> point them at virt-install. So the documentation would be:
> 
> - Do you want to use the recommended UEFI config using stock distro packages?
> Create a VM as usual, on the last page select customize before install, go to
> the boot page, select firmware=uefi, finish install.
> 
> - Do you want to use custom UEFI config? Use this virt-install command for
> fedora 20 install: virt-install --name f20 --ram 2048 --os-variant fedora20
> --cdrom $FEDORA-DVD --disk size=10 --boot loader=FOO,loader_type=pflash,nvram=...

I'll clench my teeth and live with that. :)

Thanks
Laszlo