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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list