On Wed, Mar 20, 2019 at 8:53 AM Peter Krempa <pkrempa@xxxxxxxxxx> wrote: > > On Tue, Mar 19, 2019 at 08:18:15 +0100, Christian Ehrhardt wrote: > > 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 > > 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. > > Since the snaphsot is inactive the VM is not running. The user then > tries to start the VM and gets an error that the machine type is not > valid. At that point the user tries to 'virsh snapshot-edit' the machine > type. If we'd allow the change, attempting to 'virsh start' would fail > again. After reverting the snapshot the definition becomes active and > needs to be edited using 'virsh edit'. > > I think in this case it does not make entirely much sense to add the > flag as the user would have to revert again to the edited snapshot. > > Additionally the correct workflow in my opinion would be to revert to an > old snapshot, use virsh-edit to fix anything required and then create a > new snapshot which would capture the new configuration. > > This obviously will not work for active snapshots, but the described > scenario would anyways require reverting as inactive and then discard > the memory state. > > I'm not persuaded that this workaround is necessary. Thanks Peter for taking a deeper look! 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. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
