[adding Gerd] On Wed, Jan 07, 2026 at 10:14:51AM +0000, Daniel P. Berrangé wrote:
On Mon, Dec 29, 2025 at 12:40:34AM +0100, Andrea Bolognani via Devel wrote:
+ <os> + <type arch='x86_64' machine='pc-q35-10.0'>hvm</type> + <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader> + <nvram format='json'>/path/to/guest.json</nvram>
IMHO it is wrong to be trying to squash the JSON vars storage concept into the <nvram> element. It isn't providing NVRAM to the guest and "json" is not a valid -blockdev format type, so this is overloading concepts. IMHO there needs to be a new config element to represent the new UEFI vars service persistence concept.
I went with the existing element because, from a user's perspective, regardless of the underlying implementation details the experience is effectively the same. But I see your point. If we want to introduce a new element, perhaps it could look like this: <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader> <varstore type='uefi-vars'> <template path='/usr/share/edk2/ovmf/OVMF_VARS.qemuvars.json'/> <source path='/path/to/guest.json'/> </varstore> This leaves room to implement fine-grained certificate management as an extension: <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader> <varstore type='uefi-vars'> <source path='/path/to/guest.json'/> <pk path='/path/to/microsoft-pk.pem'/> <kek path='/path/to/microsoft-kek.pem'/> <db path='/path/to/redhat.pem'/> <db path='/path/to/fedora.pem'/> </varstore> Thoughts? Suggestion on better names for the elements/attributes? :) -- Andrea Bolognani / Red Hat / Virtualization