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

[Cole Robinson]

On 09/16/2014 11:13 AM, Laszlo Ersek wrote:
> 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 don't think that's too uncommon a sentiment :) However I don't really
understand how you mean 'interactively'. virt-install command lines are pretty
much 'write once' as long as you stuff them in a shell script, I wouldn't
recommend writing them by hand over and over.

If you mean you dislike virt-viewer (the graphical interface virt-install
launches) vs. virt-manager, you can pass --noautoconsole to virt-install to
block launching it, and when the command exits, do:

virt-manager --connect $LIBVIRT-URI --show-domain-console $vmname

Which will pop open the virt-manager window for interacting with the VM. Not
saying it's the same level of convenience as doing it directly from
virt-manager, but it gets pretty close IMO. Just writing the working
virt-install command the first time always sucks, ping me if you ever need tips.

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

The problem is, that doesn't scale. Libvirt has a bajillion XML options and
each one is needed by someone. If we stuffed them all in the app it would be
impossible to maintain and test and would be less useful for everyone because
the UI would be cramped and filled with tempting sounding options that most
people won't even know what they are for.

My philosophy is try and keep virt-manager covering the major features but do
so aimed at the 90% use case, and ensure the rest of the people can at least
be facilitated by virt-install/virt-xml.

Thanks,
Cole