There might be cases when a VM temporarily used a lot of disk space which is then not needed any more. The sparse disk image format qcow2 will grow as the disk space is used, but it does not automatically shrink. To regain disk space on the host server, the disk image can be shrunk back to a smaller size.
Unfortunately, sparse disk images do not shrink when disk space is not used any more. The following procedure will show how it is possible to shrink a qcow2 disk image after it has been expanded to its maximum size. The following output shows the disk image of the VM being expanded to the maximum.
$ qemu-img info vm-106-disk-1.qcow2
image: vm-106-disk-1.qcow2
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 80G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
corrupt: false
From within the VM, the df command shows that the space on the disk is a long way from all being used.
$ df -hP Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_at5106-lv_root 78G 16G 59G 21% / tmpfs 939M 0 939M 0% /dev/shm /dev/vda1 239M 119M 108M 53% /boot
The first thing that needs to be done is filling the empty space with zeroes. This way the shrinking process knows which blocks can be shrunk together.
$ dd if=/dev/zero of=zero-file bs=1M count=40000
It is a good practice to run this command as a non-root user. The filesystem reserves a certain amount of space for root on it. If the above command is executed as root without a size limit like “bs=1M count=40000”, dd would fill up the disc including the reserved disc space. This can render your system unusable. More details about this are also described in Utility df shows inconsistent calculation for ext filesystems.
The suggestion is to not fill up the entire free space by limiting the size using the “bs=1M count=40000” (this example creates a 40000MB file) when executed as root or executing the command as non-root (less privileged user). Nevertheless, the suggestion would still be to delete this created file directly after creation to avoid any issues caused by a 100% filled filesystem.
After overwriting the free space with zeroes, the VM needs to be shut down as manipulations on the disk image should be done only when the VM is not running. At this stage a backup is strongly suggested.
Rename the original disc image to another name to enable the next step to create the shrunk disk image directly with the name needed for the VM.
$ mv vm-106-disk-1.qcow2 vm-106-disk-1.qcow2.original
The actual “shrinking” is done with the following command. The command below will, as the parameters indicate, “convert” the input disc image (which is qcow2) into the “-O” output format “qcow2”. This means it will actually not convert but create a new disc image file of the same type.
$ qemu-img convert -O qcow2 vm-106-disk-1.qcow2.original vm-106-disk-1.qcow2
This command will take a while, depending on the size of the disc image. When it is done, the command will not show any output.
The new disc image can be checked again for its size information. The output below shows now that the disc image is not at its maximum size. The actual size shows 21GB rather than the 80GB that we had in the output before.
$ qemu-img info vm-106-disk-1.qcow2
image: vm-106-disk-1.qcow2
file format: qcow2
virtual size: 80G (85899345920 bytes)
disk size: 21G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
corrupt: false
Now the VM can be started again. It is recommended to check the correct function of the VM after it is started before the original disc image is deleted.
Read more of my posts on my blog at http://blog.tinned-software.net/.
