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

[Cole Robinson]

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'. 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! :)

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

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.

I'd prefer this to not be in the new VM wizard, since I think most people
won't know what choice to make, so we should take it out of the common path.
There's also potential problems, like does windows XP install on pure UEFI?

If there are people out there that want to always default to UEFI maybe we
could add a global preference for them to set, but that could come later if we
decide it's needed.

So, thoughts on that?

Assuming that's okay, some clarifying questions:

- What is the optimal config for UEFI? The template based NVRAM? From a
management perspective that certainly sounds simplest.

- Will the OVMF package be shipping an NVRAM 'template'?

- Would we want a CSM option in that list (or UEFI + BIOS, or some other name)?

- Also, further down the line, will we ever use UEFI by default? Maybe for
certain OS versions? Just something to consider?

- What's the minimum qemu version we should target with this stuff as well? Is
the pflash stuff new?


And some minor implementation bits to consider:

- For existing VMs, we can show the firmware field in VM Details -> Boot as a
readonly label

- Make sure to hide the UEFI UI on archs that don't support it

- We should also come up with a virt-install convenience option, like '--boot
uefi' or similar. But of course keep the fine grained options as well.

- People that need advanced config, like pointing to custom nvram, or custom
ovmf, we should point them at virt-install and virt-xml. In fact if developers
want to switch back and forth between different uefi configurations, virt-xml
is far more optimal then poking around in virt-manager UI anyways.


Thanks,
Cole