Not a Debian specific question. You may possibly want to ask/check
on, e.g. relevant qemu
list or the like.
Though qcow2 is quite flexible, and can be quite efficient, depending
what data is written there,
what snapshots are or may have been there, etc., it may also be rather
to quite inefficient, including even
less efficient than raw. So, e.g. if compression is used, and the
data can't be compressed, it will take
at least slightly more space than that data itself. Likewise, if
there are no unallocated blocks, not only no space
savings there, but there's the additional overhead of tracking where
the blocks are, as they may be added
in most any order.
So, let's see how grossly inefficient I can be, and if I can recover
some of that.
# qemu-img create -f qcow2 -o
compression_type=zlib,preallocation=off,size=2G
/var/local/vtest/2GiB.qcow2
Formatting '/var/local/vtest/2GiB.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=off compression_type=zlib
size=2147483648 lazy_refcounts=off refcount_bits=16
# stat -c '%s' /var/local/vtest/2GiB.qcow2
196640
#
$ virsh attach-disk balug /var/local/vtest/2GiB.qcow2 vdc --live
--subdriver qcow2
Disk attached successfully
$
// from the guest VM:
bs=65536
# (seek=0; while dd if=/dev/random of=/dev/vdc bs="$bs" count=1
seek="$seek" status=none; do seek=$(expr "$seek" + 2); done
dd: error writing '/dev/vdc': No space left on device
# (seek=1; while dd if=/dev/random of=/dev/vdc bs="$bs" count=1
seek="$seek" status=none; do seek=$(expr "$seek" + 2); done
dd: /dev/vdc: cannot seek: Invalid argument
#
// I used random data so it (generally) wouldn't compress,
// and filled clusters in alternating order to avoid possible
contiguous mapping efficiencies
// Back on the physical host:
# stat -c '%s' /var/local/vtest/2GiB.qcow2
2148073472
# expr 512 \* 2 \* 1024 \* 1024 \* 2
2147483648
#
// Let's detach it, add a snapshot, reattach, and likewise fill again
$ virsh detach-disk balug vdc
Disk detached successfully
$
# qemu-img snapshot -l /var/local/vtest/2GiB.qcow2
# qemu-img snapshot -c snap01 /var/local/vtest/2GiB.qcow2
# qemu-img snapshot -l /var/local/vtest/2GiB.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK ICOUNT 1 snap01 0 B 2025-05-20 01:42:06 00:00:00.000 0 #
$ virsh attach-disk balug /var/local/vtest/2GiB.qcow2 vdc --live
--subdriver qcow2
Disk attached successfully
$
// back on the VM guest:
# (seek=0; while dd if=/dev/random of=/dev/vdc bs="$bs" count=1
seek="$seek" status=none; do seek=$(expr "$seek" + 2); done; seek=1;
while dd if=/dev/random of=/dev/vdc bs="$bs" count=1 seek="$seek"
status=none; do seek=$(expr "$seek" + 2); done
dd: error writing '/dev/vdc': No space left on device
dd: /dev/vdc: cannot seek: Invalid argument
#
// So, back to host, let's detach and see what we can free up.
$ virsh detach-disk balug vdc
Disk detached successfully
$
# ls -ons /var/local/vtest/2GiB.qcow2
4199252 -rw------- 1 0 4296015872 May 20 02:08 /var/local/vtest/2GiB.qcow2
# qemu-img snapshot -d snap01 /var/local/vtest/2GiB.qcow2
# ls -ons /var/local/vtest/2GiB.qcow2
2099792 -rw------- 1 0 4296015872 May 20 02:09 /var/local/vtest/2GiB.qcow2
#
// It's sparse file, we got most all that spare space back.
// Now let's see if we can do likewise for data in the image, if we
replace it with something that
// compresses highly well.
$ virsh attach-disk balug /var/local/vtest/2GiB.qcow2 vdc --live
--subdriver qcow2
Disk attached successfully
$
// and back to the VM guest:
# dd if=/dev/zero of=/dev/vdc bs="$bs" status=none; unset bs
dd: error writing '/dev/vdc': No space left on device
#
// And back to host:
$ virsh detach-disk balug vdc
Disk detached successfully
$
# ls -ons /var/local/vtest/2GiB.qcow2
2099792 -rw------- 1 0 4296015872 May 20 02:13 /var/local/vtest/2GiB.qcow2
# fallocate -d /var/local/vtest/2GiB.qcow2; ls -ons /var/local/vtest/2GiB.qcow2 368 -rw------- 1 0 4296015872 May 20 02:16 /var/local/vtest/2GiB.qcow2
#
Well, that nicely and radically shrunk it - not the logical size, but
freed huge numbers of null blocks to make it very sparse.
So, you might try something like that on the filesystem on the VM,
e.g. fill the unallocated space
with large file(s) containing nothing but ASCII NUL characters - can
then remove those files from the
VM's filesystem. And then with the qcow2 file inactive, see what you
can do with fallocate -d (don't do that
to the file while it's in use by the VM). I not uncommonly do similar
on VMs to save space on their
filesystem images - basically fill most or all the spare space with
large file(s) of just null(s), then remove
those files, and then with the backing file not in use by the VM, use
fallocate -d
There may be more efficient ways if discard/trim is in use all the way
down and through, but often that's
not the case (one may even specifically not want to do that, for
certain reasons).
On Fri, May 16, 2025 at 5:21 AM Celejar <
celejar@gmail.com> wrote:
Hi,
I have a QEMU / KVM VM running Windows that has been running as a guest
on various Debian hosts for about a decade. The Windows OS has
undergone various repairs and reinstalls over the years. I was recently
quite surprised to discover that the VM image size (actual size on
disk, not apparent size) has somehow grown to about 4x the allocated
size of the disk:
~# ls -alsh /var/lib/libvirt/images/win10.qcow2
314G -rw------- 1 root root 352G May 15 12:40 /var/lib/libvirt/images/win10.qcow2
~# qemu-img info /var/lib/libvirt/images/win10.qcow2
image: /var/lib/libvirt/images/win10.qcow2
file format: qcow2
virtual size: 80 GiB (85899345920 bytes)
disk size: 314 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: true
refcount bits: 16
corrupt: false
extended l2: false
Child node '/file':
filename: /var/lib/libvirt/images/win10.qcow2
protocol type: file
file length: 352 GiB (377549750272 bytes)
disk size: 314 GiB
I've found all kinds of discussions of this type of thing online, but
no explanation / solution that seems applicable to my situation.
The image contains no snapshots:
~# qemu-img snapshot -l /var/lib/libvirt/images/win10.qcow2
~#
I think TRIM / DISCARD is properly configured. From the VM XML:
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' discard='unmap'/>
<source file='/var/lib/libvirt/images/win10.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>
TRIM / DISCARD is enabled in the Windows guest, and I've issued manual
TRIM commands in the guest several times, like so:
https://winaero.com/trim-ssd-windows-10/
I think this did claw back some space, but only on the order of tens of GB.
Can anyone explain what's going on here, and how I can fix this?
--
Celejar
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)