On 12/08/2014 03:03 PM, Laszlo Hornyak wrote:
> Hi,
>
> I ran into a strange behavior with libvirt snapshots. I have some vms
> running with thin-provisioned qcow2 disk images (libvirt 1.1.3 with fedora
> 20).
> * When I create a snapshot on the VM, the qcow file suddenly grows big,
> somewhat bigger than the maximum size of the disk.

The maximum (guest) size of a disk is NOT a good indicator for the
(host) size of a qcow2 file.  Internal snapshots can easily cause the
host file to occupy more space than what the guest sees.  In particular,
an internal snapshot requires saving guest memory state - so if your
guest has 1G of RAM, then the internal snapshot will have to occupy 1G
of space just storing the RAM state, even if all the disk blocks are
shared between the snapshot and the current state of the disk.

> * When I delete the snapshot, the allocated disk space is not freed up, the
> qcow image remains the same size. However, if I create a new snapshot
> again, it will take the previous snapshot's space. This does not seem to be
> very well documented in qemu and the man page, manual, online
> documentation, wiki etc does not mention it.

Newer qemu can punch holes in files to make them sparse (where the
kernel and filesystem also permit that), so that even though the
physical size looks large, the actual usage of the file has shrunk after
you delete an internal snapshot.  But to date, no one has written a
defragmenter for qcow2 images; the only way to reduce the physical size
after it has once grown is to do something like 'qemu-img convert' to
copy the image to a new file - but that action loses snapshots.

>
> Is there a way to free up the space allocated for snapshots?

Punching holes should be good enough; 'du file' will show you what the
file is really using.  If it is not good enough, then you'll need to go
to the qemu-devel list and volunteer to write a defragmenter, as libvirt
isn't in charge of that.

Another thing to consider - internal snapshots may be convenient for
having only one file to worry about, but they also come with drawbacks
(at one point, qemu had a bug where taking 2 or more internal snapshots
could DRASTICALLY slow down operations of the file) and aren't as well
tested by qemu folks.  These days, most people prefer external snpashots
(you have to manage multiple files, but the RAM state is kept separate
from disk state, and cleanup is a LOT easier because you merely delete
the files you no longer need, instead of trying to defragment within a
file you are still using).

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org