On Wed, Jan 07, 2026 at 12:34:34PM -0600, Andrea Bolognani wrote:
> [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? :)
Still looking for input on this. I'd like to get started on a respin
sooner rather than later, but I'm not going to dig in until we have
at least some rough consensus on what the XML should look like.
Here's an alternative take that moves more stuff to the top-level
element, leaving the type='uefi-vars' attribute out on the assumption
that we can always add it later if it ends up being needed due to a
second implementation showing up.
With template:
<loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader>
<varstore template='/usr/share/edk2/ovmf/OVMF_VARS.qemuvars.json'
path='/path/to/guest.json'/>
With fine-grained certificate management:
<loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader>
<varstore 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>
I kinda like this one better. What do you think?
--
Andrea Bolognani / Red Hat / Virtualization
