On Mon, Mar 18, 2019 at 4:58 PM Peter Krempa <pkrempa@xxxxxxxxxx> wrote: > > On Mon, Mar 18, 2019 at 16:21:18 +0100, Christian Ehrhardt wrote: > > Currently there is no means to permanently modify the metadata stored > > within a snapshot if it does not pass the ABI compat checker. > > Could you elaborate when this happens? The ABI check is quite important > and if you change the ABI the guest may not be able to run. We are not > really willing to allow the users to stab themselves in this case. Some > cases may actually be bugs in the ABI check. Hi Peter, yeah reasonable question - let me elaborate on the case that I know. First of all this is -not- meant for --live snapshots, instead it is meant for disk snapshots - we might try to detect/limit that if you want. The other things one has to know is that we have realized that people stick way too long to their old machine types (qemu -M ...). There might be issues only solved in the newer features and in general it is recommended to use the latest type if possible. And to be fair, on the other hand it makes the maintenance burden more manageable if your delta ends at least after 10 years or so. So far we only removed some less used types and might reconsider removing the types altogether, but that would not mean it isn't recommended to update the type which still triggers the issue I try to improve here. The TL;DR of the above without stalling with even more details is, that we currently have the case where newer versions of qemu (intentionally) no more have the machine type that you saved your disk snapshot with. On a non-snapshot cases you can easily do your "virtual HW upgrade" through virsh edit and similar before you restart your guest. But for disk-snapshots there is no way anyone can modify the meta data. It is correct that the ABI checker complains (the types do differ), but then people just want to start the older disk snapshots content on a new machine type, see [1] for an example. I hope that helped to show that there are valid cases where you'd want to allow forcing changes, without any self-stabbing involved. [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1802944 -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
