Internal Snapshots & Used-Space

[Jorge Fábregas]

Hi,

I'm using the new snapshot features of virt-manager and since these are
internal snapshots I'm wondering how to figure out how much space a
given snapshot is currently using.

Previously I used base-images+overlays and I could just check the size
of the overlay file to get an idea.  If I use "qemu-img info" on my
current disks (the ones with internal snapshots) there's a "VM size"
column there but it shows 0 for offline snapshots.

Is there a way to get the actual used-space for an internal snapshot?

Thanks,
Jorge

[Eric Blake]

On 10/09/2013 08:34 AM, Jorge Fábregas wrote:
> Hi,
>
> I'm using the new snapshot features of virt-manager and since these are
> internal snapshots I'm wondering how to figure out how much space a
> given snapshot is currently using.
>
> Previously I used base-images+overlays and I could just check the size
> of the overlay file to get an idea.  If I use "qemu-img info" on my
> current disks (the ones with internal snapshots) there's a "VM size"
> column there but it shows 0 for offline snapshots.
>
> Is there a way to get the actual used-space for an internal snapshot?

Not via libvirt.  I'm not even sure if qemu-img can do that yet,
although the new 'qemu-img map' subcommand to be added in qemu 1.7 might
be the sort of tool for it.  It's probably worth asking on the qemu list.

[Kevin Wolf]

Am 09.10.2013 um 18:02 hat Eric Blake geschrieben:
> On 10/09/2013 08:34 AM, Jorge Fábregas wrote:
> > Hi,
> >
> > I'm using the new snapshot features of virt-manager and since these are
> > internal snapshots I'm wondering how to figure out how much space a
> > given snapshot is currently using.
> >
> > Previously I used base-images+overlays and I could just check the size
> > of the overlay file to get an idea.  If I use "qemu-img info" on my
> > current disks (the ones with internal snapshots) there's a "VM size"
> > column there but it shows 0 for offline snapshots.
> >
> > Is there a way to get the actual used-space for an internal snapshot?
>
> Not via libvirt.  I'm not even sure if qemu-img can do that yet,
> although the new 'qemu-img map' subcommand to be added in qemu 1.7 might
> be the sort of tool for it.  It's probably worth asking on the qemu list.

I'm not even sure what the correct result would be. Internal snapshots
are independent from each other (i.e. there is no parent-child
relationship between them), so for which snapshot would a shared cluster
be accounted?

Kevin

[Jorge Fábregas]

On 10/10/2013 04:04 AM, Kevin Wolf wrote:
> I'm not even sure what the correct result would be. Internal snapshots
> are independent from each other (i.e. there is no parent-child
> relationship between them), so for which snapshot would a shared cluster
> be accounted?

Hi Kevin,

I thought they worked like external snapshots (where one file depends on
its backing file)...but that, for internal snapshots, all the mechanics
happened within that single image.

Now that you mention that, I remembered doing some tests where I deleted
a snapshot (that was the parent of another one conceptually-wise) and
found out the child still worked afterwards.

Now I'm wondering what really happens when you take the internal
snapshot contrary to an external one.  Are internal snaphots less
efficient storage-wise?

Thanks.

[Kevin Wolf]

Am 10.10.2013 um 13:26 hat Jorge Fábregas geschrieben:
> On 10/10/2013 04:04 AM, Kevin Wolf wrote:
> > I'm not even sure what the correct result would be. Internal snapshots
> > are independent from each other (i.e. there is no parent-child
> > relationship between them), so for which snapshot would a shared cluster
> > be accounted?
>
> Hi Kevin,
>
> I thought they worked like external snapshots (where one file depends on
> its backing file)...but that, for internal snapshots, all the mechanics
> happened within that single image.
>
> Now that you mention that, I remembered doing some tests where I deleted
> a snapshot (that was the parent of another one conceptually-wise) and
> found out the child still worked afterwards.
>
> Now I'm wondering what really happens when you take the internal
> snapshot contrary to an external one.  Are internal snaphots less
> efficient storage-wise?

qcow2 has a reference count for each cluster. Taking a snapshot
basically means increasing the refcount of each currently used cluster,
it's not much more. Deleting a snapshot means decreasing the refcount,
and only once the refcount reaches zero, the cluster is freed. (Which
is, by the way, a much cheaper operation than deleting an external
snapshot, which means moving actual user data to a different image.)

So no, it's not less efficient, there is no duplication of data, but
data is kept as long as there is still a snapshot using it.

Kevin

[Jorge Fábregas]

On 10/10/2013 07:42 AM, Kevin Wolf wrote:
> qcow2 has a reference count for each cluster. Taking a snapshot
> basically means increasing the refcount of each currently used cluster,
> it's not much more. Deleting a snapshot means decreasing the refcount,
> and only once the refcount reaches zero, the cluster is freed. (Which
> is, by the way, a much cheaper operation than deleting an external
> snapshot, which means moving actual user data to a different image.)
>
> So no, it's not less efficient, there is no duplication of data, but
> data is kept as long as there is still a snapshot using it.

Thanks for the insight Kevin!

Best regards,
Jorge