On 09/16/14 16:41, Cole Robinson wrote: > On 09/16/2014 07:17 AM, Laszlo Ersek wrote: >> 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. Well, if you care for one specific data point :), I absolutely hate virt-install for anything *else* than scripting. It is fully unusable interactively. I'd certainly like to continue OVMF development using virt-manager. I like the GUI and the high level abstraction wherever my work *doesn't* focus. Just because I work on OVMF I shouldn't be required to fight virt-install *interactively*. (Virt-install is an awesome tool for scripting.) Anyway you know your users, so I'll definitely defer to you. :) > 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'. Okay. >>> 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. >> > > Right, we aren't taking that option away, I'd just prefer not to expose it in > the UI. More for us to maintain + test for an audience that would be nearly as > well served with a virt-install or virt-xml example. Please expose it somewhere. Let's assume that the custom firmware binary + varstore template widgets are indeed useless for end-users, and only useful for developers. In that case I don't mind at all if the options are buried. But they should exist on the GUI, somewhere. I think developers should be first class citizens of your target audience. > Users aren't forced to edit qemu.conf, only 'forced' to use virt-install instead. That's correct, apologies if I misrepresented this, it wasn't my intent. I just don't like virt-install when working interactively :( > And I'm not forcing libvirt developers to do anything: if the suggestion is > rejected, then we will cope. FWIW I'm happy to patch libvirt to do what I > want, time permitting I'll take a crack at it later today + review michal's > patches. Understood. Thanks. > [...] if people > want to use custom ovmf paths we would not recommend virt-manager, and instead > point them at virt-install. So the documentation would be: > > - Do you want to use the recommended UEFI config using stock distro packages? > Create a VM as usual, on the last page select customize before install, go to > the boot page, select firmware=uefi, finish install. > > - Do you want to use custom UEFI config? Use this virt-install command for > fedora 20 install: virt-install --name f20 --ram 2048 --os-variant fedora20 > --cdrom $FEDORA-DVD --disk size=10 --boot loader=FOO,loader_type=pflash,nvram=... I'll clench my teeth and live with that. :) Thanks Laszlo _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
