[Michael Paoli <michael.pa...@berkeley.edu> wrote: [Message parts rearranged to correct top-posting]
> On Fri, May 16, 2025 at 5:21 AM Celejar <cele...@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: ... > 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, 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 The guest OS shows 56GB out of a configured 80GB in use, so even if I freed the entire remaining 24GB using the method you describe, the VM image size would *still* be between 3x to 4x as large as the configured 80GB of storage, as per the numbers in my original message. > 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). I think I've successfully enabled TRIM/DISCARD in both the guest OS as well as the host libvirt configuration, and as I mentioned, I think I did claw back some space by doing so, but not nearly enough. -- Celejar
