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 :|
