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