On 8/9/19 9:02 AM, Jiri Denemark wrote:
On Wed, Jul 31, 2019 at 14:52:17 -0500, Eric Blake wrote:
> On 7/31/19 2:45 PM, Daniel Henrique Barboza wrote:
>> Max,
>>
>> Code looks ok. Two tests (virsh-checkpoint and virsh-snapshot) are
>> failing, but they are also failing on master, thus I say this patch get a
>> pass because it didn't break anything else.
>
> What failures are you seeing? Those were just recently added, and if
> they are failing for you, it's worth getting them fixed. But I'm not
> seeing them fail on my end.
>
>> On 7/23/19 4:47 PM, Maxiwell S. Garcia wrote:
>>> The snapshot-create operation of running guests saves the live
>>> XML and uses it to replace the active and inactive domain in
>>> case of revert. So, the config XML is ignored by the snapshot
>>> process. This commit changes it and adds the config XML in the
>>> snapshot XML as the <inactiveDomain> entry.
>
> Since checkpoints are brand new, and also created always on a running
> image, should they also gain an <inactiveDomain> entry? And if we are
> fast enough, would it be worth mandating that entry on a checkpoint
> REDEFINE (even though we can't do it for a snapshot REDEFINE)?
Can you actually revert to a checkpoint? I don't think so, which means
there's no reason for storing the inactive XML for it.
At present, no. But down the road, when you revert a snapshot that was
created coincedentally with a checkpoint, we may need to revert to that
checkpoint as part of reverting to the snapshot. But then again, the
snapshot's inactive XML would be sufficient.
Okay, I'm leaning towards not needing an inactiveDomain in checkpoints.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org