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