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

[Laszlo Ersek]

On 09/16/14 16:44, Cole Robinson wrote:
> On 09/16/2014 10:41 AM, Cole Robinson wrote:
>> On 09/16/2014 07:17 AM, Laszlo Ersek wrote:
>>> On 09/15/14 23:10, Cole Robinson wrote:
>>>> On 09/11/2014 12:56 PM, Giuseppe Scrivano wrote:
>>>>> Signed-off-by: Giuseppe Scrivano <gscrivan at redhat.com>
>>>>> ---
>>>>>  ui/create.ui          | 325 +++++++++++++++++++++++++++++++++++++++++++++++---
>>>>>  virtManager/create.py |  59 ++++++++-
>>>>>  2 files changed, 369 insertions(+), 15 deletions(-)
>>>>
>>>> The UI is fine for a 'nuts and bolts' type view but IMO we should strip away
>>>> some of the power while also drastically simplifying the common case.
>>>>
>>>> I think we should shoot for just adding a simple dropdown with BIOS and UEFI
>>>> options in the VM Details Boot page, and if needed at install time people have
>>>> to go through 'Customize before install'.
>>>
>>> In general, I'm OK with this, as long as all options are available to
>>> the user ultimately, in some view; but it won't be very convenient. See
>>> below.
>>>
>>>> When the user selects UEFI we try to
>>>> give them the optimal config.
>>>>
>>>> To do this the friendly way, we need to hardcode the location for the UEFI
>>>> roms and NVRAM templates. This sucks :) Ideally these would be treated like
>>>> <emulator> and xen <loader> paths, detected and exposed to clients via
>>>> capabilities XML. This 1) gives apps a way to see that UEFI is installed, even
>>>> on remote machines, 2) allows us to specify optimal defaults, and 3) tells us
>>>> that libvirt actually supports all the relevant rom/nvram bits for that
>>>> hypervisor. Triple whamy! :)
>>>
>>> I don't know how <emulator> and xen <loader> paths are interrogated, but
>>> I guess libvirtd could somehow return the first components of elements
>>> in the nvram list, in qemu.conf. That would tell you what OVMF binaries
>>> libvirtd has a matching varstore template for, which basically means
>>> what OVMF binaries libvirtd knows about. You could consider the first
>>> element in that list the "default OVMF choice" on the host.
>>>
>>> Of course I defer to Michal :)
>>>
>>>> #3 there is also important, because we will want to disable the UEFI UI option
>>>> if qemu/libvirt is too old, or if UEFI roms aren't available on the host
>>>> machine, and we will want to do it with an informative warning message or
>>>> tooltip. People will definitely want to try this and we will need to make it
>>>> as clear as possible when the needed bits are missing, which is going to be
>>>> common since ex. Fedora isn't even officially shipping OVMF.
>>>
>>> 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.
>>
>> 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'.
>>
> 
> Also let me clarify that I'm not ruthlessly opposed to the nuts + bolts UI
> with fields for nvram and loader path.
> 
> It's just that long term I'm quite certain we will want the simpler UI of just
> selecting UEFI and virt-manager 'does the right thing', so I'd rather just
> work towards getting that inplace now. Otherwise we might ship the existing
> UI, have it documented in various places, and then we are kinda stuck with it.

I agree that not adding it now, and perhaps adding it later, is safer
than adding it now, and having to remove or rework it later.

Thanks
Laszlo