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

Cole Robinson crobinso at redhat.com
Tue Sep 16 14:44:57 UTC 2014

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.

- Cole

More information about the virt-tools-list mailing list