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@xxxxxxxxxx> >>>>> --- >>>>> 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 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
