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. * 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. Is there a way to free up the space allocated for snapshots? Thank you, Laszlo -- EOF
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
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@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