On 16.09.2014 13:17, 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 <gscri...@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 :)
I see. Well, in 1.2.7 I've introduced this
virConnectGetDomainCapabilities() API that for given [qemu binary path,
architecture, machine type, virt type] (or any subset of those) returns
what features are supported. Of course, this was due to my hugepages
work so the majority of things is not implemented yet, however, I think
this API can be used to determine if UEFI is supported. In fact, I've
proposed such patch upstream:
https://www.redhat.com/archives/libvir-list/2014-September/msg01030.html
Moreover, since there's a way to pass an arbitrary template file from
which the per-domain NVRAM file is copied, does it make sense to list
master VARS.fd files known to libvirt? It's held in domain XML, so even
the template can be per-domain:
<os>
<type arch='x86_64' machine='pc'>hvm</type>
<loader readonly='yes' type='pflash'>/my/path/OVMF_CODE.fd</loader>
<nvram template='/my/path/OVMF/OVMF_VARS.fd'/>
<boot dev='hd'/>
<bootmenu enable='yes'/>
</os>
#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.
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.
Well, you can even configure libvirt so it knows about no OVMF binary
and use per-domain teplate exclusively.
Michal
_______________________________________________
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
