Re: [Qemu-devel] Re: [PATCH] monitor: Really show snapshot information about all devices

[Kevin Wolf]

Am 16.06.2010 17:57, schrieb Chris Lalancette:
> On 06/16/10 - 05:32:58PM, Kevin Wolf wrote:
>> Am 16.06.2010 17:22, schrieb Chris Lalancette:
>>> On 06/16/10 - 03:15:11PM, Kevin Wolf wrote:
>>>> Am 16.06.2010 14:59, schrieb Miguel Di Ciurcio Filho:
>>>>> On Wed, Jun 16, 2010 at 9:40 AM, Kevin Wolf <address@hidden> wrote:
>>>>>>
>>>>>> If the human monitor was exactly what its name says, I'd happily apply
>>>>>> this one (though I think it should be made clear from which image the VM
>>>>>> state would be loaded). However, it isn't and I'm not sure if this
>>>>>> wouldn't break libvirt. Dan, can you help?
>>>>>>
>>>>>
>>>>> I didn't mention in the commit, but I've looked at libvirt's source
>>>>> and it is not using 'info snapshots' AFAIK.
>>>>
>>>> Anthony, Dan, are you okay with the change then?
>>>
>>> Right, exactly as Miguel said, libvirt doesn't use "info snapshots" at all
>>> at the moment.  One of the reasons we don't use it at present is precisely
>>> because it doesn't give us information about all disks in-use.
>>>
>>> The other reason that we can't use "info snapshots" is that we need to know
>>> parent information about snapshots. That is, if you take a sequence of
>>> snapshots:
>>>
>>> A -> B -> C
>>>
>>> And then you delete B, the disk changes from B will be merged automatically
>>> into C to keep C a valid snapshot.  However, there is currently no way to
>>> discover this parent/child relationship, so we can't use "info snapshots"
>>> for that reason as well.
>>
>> Well, there is no parent/child relation in qcow2, so exposing this is
>> going to be really hard. We also don't really need it anywhere in qemu.
>> What would libvirt use this information for?
> 
> I keep being told this, and I don't really understand how this is.  I know
> when I was heavily playing with this, the scenario above worked; that is, the
> deletion of snapshot B maintained a valid C snapshot.  If nothing is tracking
> the parent/child relationship, how does this work?

Clusters are refcounted. When you save a snapshot, the refcount for all
clusters in the current state is increased. When you delete it, the
refcount is decreased and only if it's zero the cluster is freed.

> As for how libvirt uses it, it's mostly to provide the ability for the user
> to keep track of a "tree" of snapshots.  So the user could do something like
> install their base OS, and take a snapshot S1.  Then they could install one 
> set
> of applications, and take a snapshot S2.  Now they can go back to the base
> image, install a different set of applications, and take a snapshot S3.
> Now both S2 and S3 are children of S1, and libvirt wants to be able to
> represent this relationship.

qemu doesn't even remember which snapshot you have loaded. Basically you
have one L1 table for active cluster allocations and you have another
one for each snapshot. When you load a snapshot, it just copies the L1
table to the active one (and adjusts refcounts).

So technically the concept of a snapshot tree doesn't exist with
internal snapshots. It's something that management introduces.

Kevin