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 <ebl...@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
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
