On Mon, Feb 23, 2026 at 02:46:31PM +0000, Daniel P. Berrangé wrote:
> On Wed, Feb 18, 2026 at 01:05:59PM +0100, Andrea Bolognani via Devel wrote:
> > Provide a new set of command line flags named after varstore,
> > mirroring the ones that already exist for NVRAM. Users will
> > not need to worry about whether the guest uses one or the
> > other, since either version will seamlessly apply to both
> > scenarios, meaning among other things that existing scripts
> > will continue working as expected.
>
> I'm more inclined to just document that '--reset-nvram' applies to
> all cases and not introduce new args that are just a synonym. Users
> don't really need to even know that the JSON vars aren't using
> NVRAM.
I think the updated documentation does a reasonable job at making it
clear that the two options are equivalent:
$ virsh start --help
NAME
start - start a (previously defined) inactive domain
OPTIONS
--reset-nvram re-initialize NVRAM/varstore from its pristine template
--reset-varstore re-initialize NVRAM/varstore from its pristine template
$ man virsh
start
If --reset-nvram or --reset-varstore is specified, any existing
NVRAM/varstore file will be deleted and re-initialized from its
pristine template.
> Adding 2 args for the same thing, suggests to users that they first
> need to look at the guest XML to determine which arg to use for a
> given guest, which is rather unproductive / unhelpful.
That's true to some extent, but so is the opposite scenario: the user
has already looked at the XML, knows what element is used there, and
now has to figure out whether the virsh option matches the name of
the element or is... The other one.
In the long run, I expect that usage of NVRAM is going to fade out,
with varstore being used for most/all configurations. The closer we
get to that scenario, the more having to use --reset-nvram is going
to look out of place and cause friction. So adding its varstore
equivalent to the vocabulary right now feels preferrable.
--
Andrea Bolognani / Red Hat / Virtualization
