11 votes

Can you help me figure out why my VM is growing?

Posted by heh
Tags: linux.debian, ask.help, utm, tech support, virtual machines, unix, macos

I have an M1 MacBook Air. I use UTM to run a Debian 11 virtual machine.

After the initial setup, updating and upgrading, installing Firefox and a few small programs, (I almost called them apps, d'oh), the Debian.utm file size was about 6GB. Now, less than a month later, it's almost 9GB.

The VM size increases after each use. I haven't downloaded or installed anything close to 3GB worth. I have downloaded files, then put them into the trash and emptied the trash, could the trash not be emptying properly?

I have run ncdu, but nothing stands out. When I drill down into /usr and into each large folder, no sub folder is larger than a few 100MB. I can't see any big files lurking.

I've googled using many search terms, but I can't get past results that are about how to increase the size of a VM that is running out of room.

Thanks very much for reading this, any ideas?

7 comments

  1. [2]
    teaearlgraycold
    Link
    How much space did you provision for the VM? My guess is that even though it's taking up 6GB on disk you told the VM it has much more space - perhaps 20GB? When it writes incidentally to a virtual...

    How much space did you provision for the VM? My guess is that even though it's taking up 6GB on disk you told the VM it has much more space - perhaps 20GB? When it writes incidentally to a virtual sector farther out in the disk it needs to expand the real space under the host disk. Again, that's just a guess. Essentially, the space is being taken up by a lot of unneeded zeros. If you really don't want the disk to grow you could provision a smaller disk.

    14 votes
    1. heh
      Link Parent
      Hi, that's correct, the VM was provisioned with 20GB of space. The issue is that, (I didn't include this info in my original post to try to keep things simple) last month a VM with the same...

      Hi, that's correct, the VM was provisioned with 20GB of space.

      The issue is that, (I didn't include this info in my original post to try to keep things simple) last month a VM with the same configuration (Debian 11, same settings and programs installed, etc.) gradually filled up to around 20GB and then some programs stopped working properly. For example, a screen capture software (kazam) wouldn't work, wouldn't save anything to disk.

      I had to, or chose to, delete the whole VM and start from scratch. So this time, I created the VM and set it up the way I wanted to, and then saved a clean backup_copy_Debian.utm file, so that if the current VM disk fills up again I can delete the current VM and just copy over the backup VM, and I'll be ok for another few months until that one fills up.

      so, worst case, that's what I'll do, but I'd rather figure out what's going on.

      3 votes
  2. [5]
    whbboyd
    (edited )
    Link
    ncdu's accounting is almost certainly correct. This is most likely due to a lack of communication between the VM filesystem and virtualized storage controller: the VM is allocating space on the...

    ncdu's accounting is almost certainly correct. This is most likely due to a lack of communication between the VM filesystem and virtualized storage controller: the VM is allocating space on the virtual device assuming it has exclusive access to the entire reported size, while the virtualization is attempting to allocate storage lazily to minimize resource consumption on the host. Therefore, the 9GB actual file size is closer to being the sum of all writes ever performed by the VM than just the currently allocated blocks; there's "stuff" in the extra 6GB that the VM doesn't care about, but the host has no way to know that and reclaim the space.

    If this is what's happening, you should expect the drive file to expand up to roughly the total size of the virtualized device.

    You may be able to reverse this through the use of TRIM on the VM, which tells the host which areas of the storage device the VM isn't using. Your virtualization software then may (or may not, I don't know how common this is) compact the image to reclaim the space. You can manually do a TRIM on Linux with sudo fstrim -av at the commandline; note that with layered storage subsystems, any of them may drop the TRIM commands, in which case they obviously won't be effective. This is especially common with encryption subsystems (where it has a good justification: usage of the encrypted device can be inferred if the underlying storage is trimmed), and results in "0 B trimmed" by fstrim.

    7 votes
    1. [4]
      heh
      Link Parent
      I ran fstrim -av and got this: /boot/efi: 505.9 MiB (530456576 bytes) trimmed on /dev/vda1 /: 14.6 GiB (15626035200 bytes) trimmed on /dev/vda2 I restarted the VM and ran fstrim -av again, and got...

      I ran fstrim -av and got this:

      /boot/efi: 505.9 MiB (530456576 bytes) trimmed on /dev/vda1
      /: 14.6 GiB (15626035200 bytes) trimmed on /dev/vda2

      I restarted the VM and ran fstrim -av again, and got basically the same output:

      /boot/efi: 505.9 MiB (530456576 bytes) trimmed on /dev/vda1
      /: 14.5 GiB (15610728448 bytes) trimmed on /dev/vda2

      The size of the VM, as seen in macOS Finder, is the same. And the results of ncdu inside the VM are the same.

      This isn't a huge deal, I don't want to spend hours on it, I may a) live with it, b) try VMware fusion, or c) make an account and post the issue on GitHub, where there's a UTM section.

      Thanks again,

      (If I end up finding the answer, I'll update this thread so someone searching for this issue will find resolution. If I give up and this thread is never updated, then to ye poor souls in the future looking for answers.. sorry, you're on your own.)

      1 vote
      1. [2]
        overbyte
        Link Parent
        After running TRIM, you'll still need to trigger the compact operation from the host side. Shut down the VM and run Reclaim Space on the drive. VMWare has something similar with shrinking/thinning...

        After running TRIM, you'll still need to trigger the compact operation from the host side. Shut down the VM and run Reclaim Space on the drive. VMWare has something similar with shrinking/thinning disks.

        Welcome to the world of thin provisioning, runaway growth and all. Basically you'll want to set a maximum size for the VM drives so they don't grow beyond what you're comfortable with.

        2 votes
        1. heh
          Link Parent
          Hi, replying to you and to @ShamedSalmon fstrim and then reclaiming space worked, not completely, it seems like there's still about a gig in there somewhere but it did shrink things down from...

          Hi, replying to you and to @ShamedSalmon

          fstrim and then reclaiming space worked, not completely, it seems like there's still about a gig in there somewhere but it did shrink things down from about 9Gb to 7.25GB. So this seems like a solution.

          recap for anybody finding this thread in the future:

          1. inside the VM, run from the command line sudo fstrim -av
          2. shut down the VM, and in UTM select the VM's settings (it's the three bars icon at the top right) and then select VirtIO Drive in the pane at the left, and click "reclaim space".

          Thanks very much, you've saved me mucho frustration.

          4 votes
      2. ShamedSalmon
        Link Parent
        Not a computer expert here, so bear with me. If I understand you correctly, you want to thin out the disk image, right? I've never used UTM but it looks like it's both a fork of and frontend for...

        Not a computer expert here, so bear with me.

        If I understand you correctly, you want to thin out the disk image, right? I've never used UTM but it looks like it's both a fork of and frontend for QEMU that leverages the built-in hypervisor. Does that sound right? My first dumb question is have you followed their recommendation here?

        EDIT: It's exactly what @overbyte suggests :)

        If I had to guess, the .utm is a NeXT/macOS "bundle", e.g. a folder object that contains the contents of your virtual machine, including the .qcow2 disk image. My next suggestion would be that if the GUI for the UTM vmm is not providing a way to slim your images, you could try doing so manually with the qemu-img utility. It's part of the QEMU package. A little cumbersome, for sure, so doublecheck that it's not already available somewhere within the UTM.app bundle (e.g. UTM.app/Contents/MacOS or UTM.app/Contents/Resources or somewhere else).

        There's two parts to this method, filling the guest disk with zeroes, then shrinking it from the host.

        Within the Debian guest, zero-fill the disk using dd, like so:

        dd if=/dev/zero of=/var/tmp/zero.file bs=1048576; rm /var/tmp/zero.file; shutdown -h now

        Then, from the host, copy the .qcow2 image into a new sparse image, like so:

        qemu-img convert -O qcow2 /path/to/Debian.utm/path/to/original_disk_image.qcow2 /path/to/Debian.utm/path/to/sparse_disk_image.qcow2

        Then either modify your configuration to test the new sparse image, or simply rename the new image to the old one.

        (If you are able to build or track down a copy of virt-sparsify that could run on the macOS host, you would be able to skip the zero-fill step in the guest, but I couldn't find a package or build script for it anywhere. It's uaually a part of libguestfs-tools, if you want to look as well.)

        I do pretty much the same thing in VMware to shrink disks for guests that don't support resizing (such as OS X 10.4) by running dd in the guest as above and then from the host, punching out the zeroes with:

        vmkfstools -K /path/to/my_fussy_legacy_image.vmdk

        Hopefully this can help in some way!

        2 votes