[libvirt] [PATCH 1/2] snapshots: allow create --redefine to force a new configuration

Eric Blake eblake at redhat.com
Wed Mar 20 16:39:01 UTC 2019


On 3/20/19 3:16 AM, Christian Ehrhardt wrote:

>> So looking at the bug, user created a snapshot, then upgraded qemu to a
>> version which dropped the old machine type.
>>
>> Reverting to a inactive internal snapshot in this case will restore the
>> definition including the machine type. That is what snapshots are
>> expected to do.

We already have a FORCE flag for virDomainSnapshotRevert(); is that not
sufficient to allow reverting to an inactive snapshot where the domain
description is no longer viable in modern qemu?  I'm trying to see why a
second --force flag to create --redefine helps things.

Also, since current snapshot --redefine code lets you omit <domain> from
the snapshot, what's so hard about back-to-back redefines, the first
which removes the non-viable <domain>, and the second which now adds a
corrected one in (libvirt can no longer tell that the two definitions
are ABI-incompatible, because of the intermediate state where libvirt
behaves like pre-0.9.5 days when there was no <domain> and the burden
was on the user instead of on libvirt to remain ABI compatible).

If we add a FORCE flag during snapshot redefinition, would that mean
we'd also need a FORCE flag during a redefinition of my proposed
checkpoints?  Note that with checkpoints, I've specifically stated that
the <domain> element is going to be mandatory during redefine (at least,
initially). The only reason it was not mandatory for snapshots is
history (we had old releases that did not generate the <domain>
subelement, before realizing that knowing the old state of the domain is
important for proper reverts).

> 
> And yes your summary seems correct.
> I personally still like to give admins the ability to force configs,
> but I'm ok if the general upstream opinion to that is no.
> 
> I have asked the reporter - on the bug that I got - to chime in here and
> do the "convincing" as he is the affected person I think he is more able
> to do so - e.g. express the pain with the suggested workaround.

I look forward to more details.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190320/ad42606d/attachment-0001.sig>


More information about the libvir-list mailing list