[libvirt] [PATCH] qemu: snapshot: Keep non-persistent changes alive in snapshot

Jiri Denemark jdenemar at redhat.com
Fri Oct 27 09:21:42 UTC 2017

On Fri, Oct 27, 2017 at 14:02:23 +0530, Kothapally Madhu Pavan wrote:
> Restoring to a snapshot should not overwrite the persistent configuration
> xml of a snapshot as a side effect. This patch fixes the same. Currently,
> virDomainSnapshotDef only saves active domain definition of the guest.
> And on restore the active domain definition is used as both active and
> inactive domain definitions. Thiswill make the non-persistent changes
> persistent in snapshot image. This patch allows to save inactive domain
> definition as well and on snapshot-revert non-persistent configuration is
> restored as is.
> Currently, snapshot-revert is making non-presistent changes as persistent.
> Here are the steps to reproduce.
> Step1: virsh define $dom
> Step2: virsh attach-device $dom $memory-device.xml --live
> Step3: virsh snapshot-create $dom
> Step4: virsh destroy $dom
> Step5: virsh snapshot-revert $dom $snapshot-name
> Step6: virsh destroy $dom
> Step7: virsh start $dom
> Here we still have $memory-device attached in Step2.

I think this is actually a bit more complicated. When reverting to a
snapshot, when reverting a snapshot we should revert both active and
inactive configuration for backward compatibility and also because it
makes sense. Imagine you made a snapshot of a running domain, played
with the domain configuration and then reverted the state of the domain
to the snapshot. Once you shutdown the domain and start it again you'd
get a completely different machine. Of course, you actually may want
such behavior. Thus we can't really guess whether a user wants to revert
both active and inactive configuration or just one of them. The user
should be able to tell us what to do (and we should revert both configs
if no preference is given).

However, for this to be really useful we need to store both active and
inactive configurations when creating a snapshot of a running domain.


More information about the libvir-list mailing list