[libvirt-users] snapshots and qcow2

[Laszlo Hornyak]

Hi Eric,

Thank you for the reply, yes indeed the qcow2 file takes only a few GB on
disk.



On Mon, Dec 8, 2014 at 11:41 PM, Eric Blake <eblake at redhat.com> wrote:

> 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
>
>


-- 

EOF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20141209/7bd6d90f/attachment.htm>