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

Madhu Pavan kmp at linux.vnet.ibm.com
Mon Oct 30 08:55:16 UTC 2017



On 10/27/2017 06:51 PM, Jiri Denemark wrote:
> On Fri, Oct 27, 2017 at 18:47:51 +0530, Madhu Pavan wrote:
>> On 10/27/2017 02:51 PM, Jiri Denemark wrote:
>>> 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.
>> With the current behavior that I see from snapshot-list, I understood we
>> categorize the snapshots
>> as "Active (running, paused)" or "config(shutoff)" depending if the
>> snapshot was taken on an
>> active or inactive domain. With my use case what I observed was that the
>> revert of active
>> snapshot actually overwriting inactive domain configuration. I thought
>> only the "config" snapshot
>> alone can overwrite the inactive domain configuration. Hence this patch.
>> Are you suggesting we
>> should have both active and inactive domain configurations to be saved
>> for an active guest and
>> restore (both by default) OR (provide options to select)?
> Yes, exactly.
I have sent a new patchset considering your suggestions.
Here is the link to it
https://www.redhat.com/archives/libvir-list/2017-October/msg01333.html

Madhu




More information about the libvir-list mailing list