This test case demonstrates how to manually configure an x86_64
guest to use the uefi-vars device.
It currently fails because the QEMU driver does not yet allow
the use of JSON for NVRAM. That will change in a future commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
...-manual-efi-qemuvars-q35.x86_64-latest.err | 1 +
...-manual-efi-qemuvars-q35.x86_64-latest.xml | 36 +++++++++++++++++++
.../firmware-manual-efi-qemuvars-q35.xml | 19 ++++++++++
tests/qemuxmlconftest.c | 2 ++
4 files changed, 58 insertions(+)
create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err
create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml
diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err
new file mode 100644
index 0000000000..e5f67f8d09
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err
@@ -0,0 +1 @@
+unsupported configuration: Unsupported nvram format 'json'
diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml
new file mode 100644
index 0000000000..a16c404eaf
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml
@@ -0,0 +1,36 @@
+<domain type='qemu'>
+ <name>guest</name>
+ <uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid>
+ <memory unit='KiB'>1048576</memory>
+ <currentMemory unit='KiB'>1048576</currentMemory>
+ <vcpu placement='static'>1</vcpu>
+ <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>
+ <boot dev='hd'/>
+ </os>
+ <features>
+ <acpi/>
+ </features>
+ <cpu mode='custom' match='exact' check='none'>
+ <model fallback='forbid'>qemu64</model>
+ </cpu>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-x86_64</emulator>
+ <controller type='usb' index='0' model='none'/>
+ <controller type='sata' index='0'>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
+ </controller>
+ <controller type='pci' index='0' model='pcie-root'/>
+ <input type='mouse' bus='ps2'/>
+ <input type='keyboard' bus='ps2'/>
+ <audio id='1' type='none'/>
+ <watchdog model='itco' action='reset'/>
+ <memballoon model='none'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml
new file mode 100644
index 0000000000..07b744d490
--- /dev/null
+++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml
@@ -0,0 +1,19 @@
+<domain type='qemu'>
+ <name>guest</name>
+ <uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid>
+ <memory unit='KiB'>1048576</memory>
+ <vcpu placement='static'>1</vcpu>
+ <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>
+ </os>
+ <features>
+ <acpi/>
+ </features>
+ <devices>
+ <emulator>/usr/bin/qemu-system-x86_64</emulator>
+ <controller type='usb' model='none'/>
+ <memballoon model='none'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c
index 89b8ad1a35..1e20957656 100644
--- a/tests/qemuxmlconftest.c
+++ b/tests/qemuxmlconftest.c
@@ -1560,6 +1560,8 @@ mymain(void)
ARG_CAPS_VARIANT, "+inteltdx",
ARG_END);
+ DO_TEST_CAPS_LATEST_FAILURE("firmware-manual-efi-qemuvars-q35");
+
/* Make sure all combinations of ACPI and UEFI behave as expected */
DO_TEST_CAPS_ARCH_LATEST("firmware-manual-efi-acpi-aarch64", "aarch64");
DO_TEST_CAPS_LATEST("firmware-manual-efi-acpi-q35");
--
2.52.0On Mon, Dec 29, 2025 at 12:40:34AM +0100, Andrea Bolognani via Devel wrote: > This test case demonstrates how to manually configure an x86_64 > guest to use the uefi-vars device. > > It currently fails because the QEMU driver does not yet allow > the use of JSON for NVRAM. That will change in a future commit. > > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > --- > ...-manual-efi-qemuvars-q35.x86_64-latest.err | 1 + > ...-manual-efi-qemuvars-q35.x86_64-latest.xml | 36 +++++++++++++++++++ > .../firmware-manual-efi-qemuvars-q35.xml | 19 ++++++++++ > tests/qemuxmlconftest.c | 2 ++ > 4 files changed, 58 insertions(+) > create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err > create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml > create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.xml > > diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err > new file mode 100644 > index 0000000000..e5f67f8d09 > --- /dev/null > +++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.err > @@ -0,0 +1 @@ > +unsupported configuration: Unsupported nvram format 'json' > diff --git a/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml > new file mode 100644 > index 0000000000..a16c404eaf > --- /dev/null > +++ b/tests/qemuxmlconfdata/firmware-manual-efi-qemuvars-q35.x86_64-latest.xml > @@ -0,0 +1,36 @@ > +<domain type='qemu'> > + <name>guest</name> > + <uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid> > + <memory unit='KiB'>1048576</memory> > + <currentMemory unit='KiB'>1048576</currentMemory> > + <vcpu placement='static'>1</vcpu> > + <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. With 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 :|
[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
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
On Mon, Jan 12, 2026 at 06:27:23AM -0700, Andrea Bolognani wrote: > 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'd suggest we still want the "type" attribute on the <varstore> element, as mandatory, otherwise it looks OK to me as it will avoid the sub-elements in the simple common-case. With 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 :|
Hi, > > 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> > <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'/> <varstore template='...'>/path/to/guest.json</varstore> ? Following what we are doing for nvram ... That said I have no idea what guidance is typically used by libvirt when adding stuff to the schema, specifically the choice between attributes and sub-elements looks a bit random to me ... take care, Gerd
On Thu, Jan 15, 2026 at 11:32:48AM +0100, Gerd Hoffmann wrote:
> > > 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>
>
> > <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'/>
>
> <varstore template='...'>/path/to/guest.json</varstore> ?
>
> Following what we are doing for nvram ...
That would rule out extending with sub-elements later:
<varstore template='...'>
/path/to/guest.json
<db>...</db>
</varstore>
is not valid XML.
> That said I have no idea what guidance is typically used by libvirt when
> adding stuff to the schema, specifically the choice between attributes
> and sub-elements looks a bit random to me ...
There's no hard and fast rule so often it's down to the taste of
whoever introduces the new element/attribute. Having to go through
review normalizes this to some extent, but ultimately what we have
today is just the result of a schema growing organically over 20
years while maintaining full backwards compatibility :)
--
Andrea Bolognani / Red Hat / Virtualization
On Thu, Jan 15, 2026 at 03:19:17AM -0800, Andrea Bolognani wrote: > On Thu, Jan 15, 2026 at 11:32:48AM +0100, Gerd Hoffmann wrote: > > > > 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> > > > > > <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'/> > > > > <varstore template='...'>/path/to/guest.json</varstore> ? > > > > Following what we are doing for nvram ... > > That would rule out extending with sub-elements later: > > <varstore template='...'> > /path/to/guest.json > <db>...</db> > </varstore> > > is not valid XML. > > > That said I have no idea what guidance is typically used by libvirt when > > adding stuff to the schema, specifically the choice between attributes > > and sub-elements looks a bit random to me ... > > There's no hard and fast rule so often it's down to the taste of > whoever introduces the new element/attribute. Having to go through > review normalizes this to some extent, but ultimately what we have > today is just the result of a schema growing organically over 20 > years while maintaining full backwards compatibility :) In the case of <loader> that was a design mistake we made very very early in libvirt development before we appreciated the downsides it has for future extension. These days we try to avoid doing that in general. With 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 :|
On Thu, Jan 15, 2026 at 03:19:17AM -0800, Andrea Bolognani wrote: > On Thu, Jan 15, 2026 at 11:32:48AM +0100, Gerd Hoffmann wrote: > > > > 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> > > > > > <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'/> > > > > <varstore template='...'>/path/to/guest.json</varstore> ? > > > > Following what we are doing for nvram ... > > That would rule out extending with sub-elements later: > > <varstore template='...'> > /path/to/guest.json > <db>...</db> > </varstore> > > is not valid XML. Ah, ok. Clearly I'm not an XML expert ;) I like your second version more because it is at least closer to nvram and (hopefully) easier to remember. > There's no hard and fast rule so often it's down to the taste of > whoever introduces the new element/attribute. Having to go through > review normalizes this to some extent, but ultimately what we have > today is just the result of a schema growing organically over 20 > years while maintaining full backwards compatibility :) So, just continue that scheme and pick what you personally prefer? take care, Gerd
On Thu, Jan 15, 2026 at 03:00:23PM +0100, Gerd Hoffmann wrote: > On Thu, Jan 15, 2026 at 03:19:17AM -0800, Andrea Bolognani wrote: > > On Thu, Jan 15, 2026 at 11:32:48AM +0100, Gerd Hoffmann wrote: > > > > > 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> > > > > > > > <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'/> > > > > > > <varstore template='...'>/path/to/guest.json</varstore> ? > > > > > > Following what we are doing for nvram ... > > > > That would rule out extending with sub-elements later: > > > > <varstore template='...'> > > /path/to/guest.json > > <db>...</db> > > </varstore> > > > > is not valid XML. > > Ah, ok. Clearly I'm not an XML expert ;) > > I like your second version more because it is at least closer to nvram > and (hopefully) easier to remember. Hopefully firmware autoselection will take care of picking the right values in 99% of scenarios and users won't have to worry about it at all. But I like the second version better myself, it's less verbose. > > There's no hard and fast rule so often it's down to the taste of > > whoever introduces the new element/attribute. Having to go through > > review normalizes this to some extent, but ultimately what we have > > today is just the result of a schema growing organically over 20 > > years while maintaining full backwards compatibility :) > > So, just continue that scheme and pick what you personally prefer? Right, but I don't necessarily want to spend the time reworking the series only to see the XML design rejected again afterwards, so I figured I'd try to get feedback ahead of time. Let's give it a couple more days. If I don't hear anything by next Monday, I'll assume other folks are okay with the options that the two of us like and implement it :) Thanks! -- Andrea Bolognani / Red Hat / Virtualization
© 2016 - 2026 Red Hat, Inc.