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(a)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