On 09/16/14 18:10, Cole Robinson wrote: > On 09/16/2014 11:13 AM, Laszlo Ersek wrote: >> 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 don't think that's too uncommon a sentiment :) However I don't really > understand how you mean 'interactively'. virt-install command lines are pretty > much 'write once' as long as you stuff them in a shell script, I wouldn't > recommend writing them by hand over and over. I have long-term guests, and occasionally I create ad-hoc guests. I didn't think of saving virt-install command lines for the ad-hoc guests in scripts because I need them only occasionally (and then I like to review the properties). virt-manager would be just right for these ad-hoc guests, if it offered me the custom UEFI options. :) Anyway the lesson for me is probably to distill the common properties of my ad-hoc guests, and put those in a scipt. A "virt-install wrapper" if you like. Thanks for the suggestion. >>> 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. > > The problem is, that doesn't scale. Libvirt has a bajillion XML options and > each one is needed by someone. Yes, I'm aware of this. I like the abstraction that virt-manager provides in areas where I don't wear my developer hat. I want virt-manager to expose all the bits in areas where I wear it. :) In other words, I'm selfish. :) I agree that it doesn't scale. > If we stuffed them all in the app it would be > impossible to maintain and test and would be less useful for everyone because > the UI would be cramped and filled with tempting sounding options that most > people won't even know what they are for. > > My philosophy is try and keep virt-manager covering the major features but do > so aimed at the 90% use case, and ensure the rest of the people can at least > be facilitated by virt-install/virt-xml. I appreciate your vision. Thanks, Laszlo _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
