[libvirt] [PATCH] qemu: Do not override config XML in case of snapshot revert

[Daniel Henrique Barboza]

On 5/15/19 3:17 PM, Eric Blake wrote:
> On 5/15/19 1:03 PM, Daniel Henrique Barboza wrote:
>>
>> On 5/15/19 12:49 PM, Eric Blake wrote:
>>> If you reboot the guest, the inactive XML will become active and the
>>> guest will have a new device. But if the guest continues running without
>>> rebooting, the inactive XML will be different from the live XML. Whether
>>> or not the guest rebooted, a revert must NOT expose the new device to
>>> the live XML installed during the revert.  But there is still a question
>>> as to whether the revert should also undo the inactive XML change that
>>> was made after the snapshot was created, or leave the inactive XML alone
>>> (that is, after we revert, will a fresh boot once again pick up the new
>>> device, or will the fresh boot be stuck with the configuration as though
>>> step 3 had never happened).
>> Maybe we should consider that, in Libvirt, the snapshot state consists
>> of both inactive and live XMLs.
> Right now, that is untrue. The snapshot state consists of a single XML
> (either the live XML for a live or disk-only snapshot, or the inactive
> XML for an offline snapshot). We could make it true, but it is an
> invasive change and we'd still have to cope with existing live snapshots
> that didn't have both stored.

Good point. In case we go on with this change, the current behavior
should be maintained for the existing live snaps that doesn't have
the inactiveXML information.

>> Like Michal suggested in his first reply.
>> It appears to be the most consistent way of dealing with the revert of a
>> VM state - the change is that the VM state is now both inactive and
>> active XMLs.
> Reverting to an offline or disk-only snapshot is easy - there's only one
> XML to worry about (once you've reverted, the domain is offline, so
> there is no live XML - unless the revert command also included the flag
> to start the domain in which case the live XML will match the
> just-reverted offline XML). Reverting to an online snapshot is trickier
> (right now, we MUST overwrite the live XML to perform the revert
> correctly, and we HAPPEN to overwrite the inactive XML as well) - but
> there you can argue that we've merely been buggy for a few years, and
> that we should leave the inactive XML untouched in that case.

The solution will need to consider all this cases, including an offline
domain being reverted to a live domain and so on. I didn't see the code
thus I don't know how hard it is to implement it consistently.


Worst case scenario, if a new solution (snap with both XMLs for example)
is proven to be too hard or too error prone, I'd say that keeping what
we already do, but with a documentation amend saying that
snapshot-revert will overwrite the inactiveXML with the live XML that
is being loaded, suffices. At least the user can be aware of what is
happening and that the behavior is expected.



Thanks,


DHB



>