Re: [libvirt] [PATCH virt-manager] details: Add UI for enabling UEFI via 'customize before install'

On 09/22/14 18:37, Cole Robinson wrote: Yes, the pathname is generated and/or the contents are copied in qemuProcessStart() qemuPrepareNVRAM() which I gather are called when you start the VM, not when you define it. (2) I think that minimally the copying from the varstore template must happen at startup. Otherwise, if you lose your varstore file, you won't be able to start the VM at all, until you recreate the varstore manually from the template (which is exactly what libvirtd should save you from). A particular, valid use case for this functionality is when you want to "reset" your variable store. You just delete the old one (when the VM is shut down) and libvirt will recreate it for you, for the pristine template, at next VM startup. (1) Moving the generation of the varstore pathname to define time is also somewhat brittle, similarly to the above. If you accidentally deleted the nvram element while in "virsh edit", then the proposed change (== don't generate an nvram pathname at startup, if it's missing) would prevent the VM from starting, and you'd have to restore the element manually. BTW I could not find the qemu-ga socket generation code in libvirt. (I grepped for "org.qemu.guest_agent".) I did find something relevant in "virtinst/devicechar.py" though, and CHANNEL_NAME_QEMUGA leads further. Also I think if you accidentally remove the guest agent channel from the domain XML, it won't break the VM completely, and (I think!) you can even re-add it in virt-manager. I think this can be made robust, we "just" need to start thinking about the nvram element's text contents as "procedural" -- probably a getter function should be factored out. If the text() child exists, then that's the returned value (as a human-provided override), if it doesn't, then the name should be auto-generated, based on the VM's UUID. I agree that this is complex, but the domain XML should accommodate all of the following: - simple loader element, or type='rom': usual bios thing - type='pflash' readonly='no': unified OVMF.fd file containing both binary and varstore. Consequences: - no concept of a varstore template - no concept of a varstore - hence no pathname generation and no contents copying - this is a "fringe" case for completeness only - type='pflash' readonly='yes': split OVMF binary and varstore. Consequences: a. loader specifies the binary only b. nvram text() child enables a user-provided, VM-specific varstore pathname, if present c. lack of nvram text() child requests auto-generation based on VM name ^W UUID (see my earlier patch about the UUID) d. in nvram's template attribute, if present, the user provides the pathname of a varstore template file compatible with the loader binary e. if nvram's template attribute is missing, then libvirtd insists on being able to resolve the loader binary to a varstore template using qemu.conf's "nvram" setting. If you restrict (c) or (d)/(e) to define time only, then things will work in the "optimal" case, but as soon as the user deletes or loses the VM-specific varstore, and/or loses the <nvram> element, things will break much less gracefully. In any case I don't insist either way; I'll defer to Michal and you. I don't know what the "typical path under $HOME is", but this case is certainly addressible with (b) -- as long as the tools expose it. :) Virt-install does: --boot loader=/usr/share/OVMF/OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram=$HOME/.../guest-VARS.fd This is (b)+(e). --boot loader=/custom/OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/custom/OVMF_VARS.fd,nvram=$HOME/.../guest-VARS.fd This is (b)+(d). Thanks! Laszlo