The typical scenario for UEFI is that we have readonly firmware with separate NVRAM <loader readonly="on">/some/ovmf/path_CODE.fd</loader> <nvram template="/some/ovmf/path_VARS.fd"/> In this case we of course copy path_VARS.fd into a private file path we invent under /var/lib. The user can give an explicit NVRAM path too: <loader readonly="on">/some/ovmf/path_CODE.fd</loader> <nvram>/var/lib/libvirt/images/guest_vars.fd</nvram> If template isn't set, and can't be identified from path_CODE.fd automatically, then the NVRAM file must exist ahead of time. When undefining a VM's persistent config we refuse to allow it if an NVRAM exists, unless UNDEFINE_NVRAM is set which causes it to be deleted. Alternatively KEEP_NVRAM can cause the NVRAM to be left behind. I've always felt this is quite dubious because we happily let the VM be undefined with disks still existing, or TPM state still exist, or any number of files remaining. With that in mind, we have other configurations that are possible. For example, a single writable loader file, either implicitly: <loader>/var/lib/libvirt/images/guest.fd</loader> or explicitly: <loader readonly="off">/var/lib/libvirt/images/guest.fd</loader> In both cases this guest.fd must be pre-populated by the mgt apps since we don't initialize it from any template. We also dont place any restrictions on the undefine step when using a writable loader. This config is fairly sane in that yu can build EDK2 with both CODE and VARs in one file. This makes sense for a public cloud scenario if the user is allowed to bring along their own firmware, as there's no benefit to splitting CODE+VARs if the firmware is just used for a single VM. Building on that though we allow a somewhuat questionable config: <loader>/var/lib/libvirt/images/guest.fd</loader> <nvram>/var/lib/libvirt/images/guest_vars.fd</nvram> where both loader + nvram are writable. We allow 'template' to be set but we completely ignore it, since the loader is not marked read-only. THe mgmt app must pre-create both these writable files now, and undefine only complains about the nvram file. I'm wondering what, if anything, we should do in these edge cases - Allow 'template' on the <loader> element to populate a writable combined CODE+VARS image ? This would let us use a combined CODE+VARS file as a template for writable firmware. - Allow 'template' on the <nvram> element to populate a writable combined CODE+VARS image for <loader>? Takes advantage of fact that 'template' is ignored currently if <loader> is not read-only. That rationale is that <nvram> element doesn't imply that the NVRAM has to be separate, just that there is NVRAM and the primary writable loader provides that. - Or reject 'template' on <nvram> element if <loader> is writable rather than ignoring it ? Mutually exclusive with previous point - Make undefine use NVRAM flags to apply to writable <loader> too ? That could be considwered a behaviour change for existing users though, unless we only do that when support use of a 'template' for the <loader>. - Reject the wierd writable loader + writable NVRAM config ? I can't imagine why we need this, but QEMU allows it, and blocking it would be a behavioural change Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|