efi_vars.fd file size 18GB suddenly, matching qcow2 file size

[philomathy]

I was curious about why the UTM file for my Linux guest has doubled in size. Examining the package, I found the efi_vars.fd file, which previously held a few kilobytes but now occupies 18GB—roughly matching the xxxx.qcow2 virtual disk.

No snapshots appear to exist; the Snapshots folder in the package is empty. Shrinking or resizing fails because UTM claims snapshots are present, even though the GUI and empty folder suggest otherwise.

Version 5.0.8 (128) runs on MacOS 27.2, with Fedora Linux 44 as the guest.

[petrosalex]

Most likely that's a saved suspend state. efi_vars.fd is one of the images UTM snapshots, and QEMU can store the VM's RAM there, so the size matching your disk is probably a coincidence. qcow2 files also don't shrink on their own after a state is deleted, and qemu-img won't resize an image that has internal snapshots, which would explain your error.

With the VM off and a backup made, run this in the package's Data folder:

qemu-img snapshot -l efi_vars.fd
qemu-img snapshot -d <tag> efi_vars.fd
mv efi_vars.fd efi_vars.old && qemu-img convert -O qcow2 efi_vars.old efi_vars.fd

Do the same check on the qcow2 disk. If -l shows nothing, I'm wrong about this.

[philomathy]

Thanks for your response. I appreciate it. I have not installed brew and the qemu-img package yet.
What I did instead

• backup utm file
• open the original file (show package contents)
• delete the efi_vars.fd
  I deemed this safe, as I don't use snapshots and got the backup anyways.

On VM boot, the VM efi_vars.fd was re-created with 655kb only.
The VM runs normally so far. I got the backup if not.

From observation, I assume the issue with the large efi... file happens when suspending the VM fails.

• the suspend command works (apparently)
• when closing the VM UTM window, however, a message pops up that suspending failed and power-off will happen when closing the VM now. (Exact wording is lost on me.)

That's probably when a stale suspend state exists within the package, within the efi_vars.fd file.

Just my naive suggestion.

Thanks for taking the time to help!

[petrosalex]

Glad it worked. Your theory sounds plausible to me. Two things to keep in mind: UTM resets the EFI variables when it recreates that file, so any custom boot entries are gone (sounds like Fedora didn't mind). And deleting it doesn't touch the qcow2, so if shrinking still complains about snapshots, there's one in the disk too. qemu-img snapshot -l on the qcow2 will show it.

[philomathy]

Yes, I noticed a different start-up behaviour very briefly, but then the headless boot worked just fine.
True, I still cannot use the shrink disk feature. UTM says there are snapshots in the VM. But there are no snapshots visible in the UTM GUI snapshot feature. I assume, snapshots, as a new feature, need some more dev-love.
I'll will take time soon to install brew and the qemu-img package and report back.

[petrosalex]

The shrink check reads the qcow2 itself, so there really is a snapshot in there even though the GUI doesn't list it. Once you have qemu-img, run qemu-img snapshot -l on the qcow2. It's probably called suspend. Then with the VM off and a backup, qemu-img snapshot -d suspend <disk>.qcow2 should remove it and shrinking should work again.