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

[Christian Ehrhardt]

On Wed, Mar 20, 2019 at 8:53 AM Peter Krempa <pkrempa at redhat.com> 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 at redhat.com> 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