[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
