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

[Laszlo Ersek]

On 09/16/14 18:10, Cole Robinson wrote:
> 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.

I have long-term guests, and occasionally I create ad-hoc guests. I
didn't think of saving virt-install command lines for the ad-hoc guests
in scripts because I need them only occasionally (and then I like to
review the properties). virt-manager would be just right for these
ad-hoc guests, if it offered me the custom UEFI options. :)

Anyway the lesson for me is probably to distill the common properties of
my ad-hoc guests, and put those in a scipt. A "virt-install wrapper" if
you like. Thanks for the suggestion.

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

Yes, I'm aware of this. I like the abstraction that virt-manager
provides in areas where I don't wear my developer hat. I want
virt-manager to expose all the bits in areas where I wear it. :)

In other words, I'm selfish. :) I agree that it doesn't scale.

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

I appreciate your vision.

Thanks,
Laszlo