I’m using Boxes on my Steam Deck and I noticed with version 49.0 Stable that my VM’s local max storage is not the same with my disk image size anymore and everytime I launch my VM that size gets bigger. On previous version of GNOME Boxes, i setup my VM to 80GB, that means my virtual OS can only use up to that storage and its file size should be 80GB also, but outside the VM, on my steam deck, the image size is now 109.2GB, before that it was 107.4GB, then before than its 105GB. It grew everytime i shutdown and boot my VM. Can anyone help me with this issue?
Is there anyone to help? My disk image size is now 111.6GB, i have zero remaining disk space on my SSD
Sorry you are facing this issue.
Could you please attach the Troubleshooting Logs of your virtual machine? Right-click the VM → Preferences → Troubleshooting Logs.
To clarify:
- Do you know if the problem started with v49?
- Approximately how much disk space is in use in the VM?
- What’s the OS in the VM?
I happen to have Windows 10 in a VM on Steam Deck. (Or at least I thought I did, but Boxes was not installed. Maybe a Steam update wiped it? I (re?)installed the Flatpak and got v49.) Haven’t booted it in a while, so I let it update to End-of-Line, while keeping an eye on the .qcow2 file. I had defined the disk originally as “up to” 100GB, with 30-something in use. Did the Disk Cleanup after, saving 5GB. So the disk-in-use ended up a little lower than I started. But the .qcow2 grew several GBs, into the 40s.
Tried the broadly suggested fsutil behavior query DisableDeleteNotify and confirmed TRIM was not disabled. Checking the disk properties, the device was a “QEMU HARDDISK ATA” with a driver from 2006. If Windows thinks the drive is a plain old hard disk and not an SSD, it wouldn’t send TRIM, would it? So two questions about Boxes:
- what’s needed for the guest to see the virtual drive as an SSD?
- if properly configured, would deletes be handled appropriately to actually shrink the
.qcow2
So I tried to shrink the file. I read about virt-sparsify. But when I tried to install the guestfs-tools package, I was warned that an existing package, exfat-utils, conflicted with it. It provides the ExFAT FUSE, which I guess might be used if you tried an SD formatted with that. I didn’t want to mess with the immutable core image. That means using manual steps, as documented for Proxmox.
You need spare disk space, on either an SD or USB drive (through a dock, so you have power the whole time, which can take while). Since the file is already bigger than the supposed max, doing a “dumb” sector copy should shrink it to that 80GG or less. Then you need to figure out if you then zero out the free disk space, and that causes the file to grow: would that fit?
When I used sdelete in my Windows VM, it quickly caused the .qcow2 to grow to 100GB, the max size. Luckily I had 10GB left over on the Deck’s internal SSD. It then took more than a few hours to actually flush the 60-ishGB of disk writes. I shut down the VM and quit Boxes.
I installed the qemu-img package (disabling the readonly flag first) and then
qemu-img convert /home/deck/big.qcow2 /run/media/deck/usbdrive/shrink.qcow2
which worked to shrink the file. Now, you can replace the file, being as careful as you want or can be by copying the old file off first, if you have space.
While poking around, I found you can use qemu-nbd to mount the .qcow2 as a live device outside a VM. I did that on a regular Linux box, ran GParted – specifying /dev/nbd1 on the command line, due to this (recently-fixed) issue – and shrank the partition from 100 to 45GB, so that if I have to do it again, there’s less to zero-out. If it gets tight on space inside the VM, I can nudge it back up.