Huge efi_vars.fd file (several GB) inside the .utm package of a VM

[rxhfcy]

Describe the issue
I found a huge (4.13 GB) efi_vars.fd file inside the .utm package of one of my VMs (QEMU ARM VM, Fedora Linux aarch64)

("Show in Finder" -> Show package contents -> "Data" folder)

I have 3 other (ARM Linux) VMs that also seem to have bloated efi_vars.fd files inside them (367 MB, 358 MB, 164 MB) but this one was by far the worst. Don't know why.

A random guess: could this have something to do with the fact that I have used the Edit VM / VirtIO Drive / "Compress" button (and probably"Reclaim Space" button too) several times between installing and/or removing lots of stuff inside the VM? Bug in Compress or Reclaim Space maybe?

Screen shot: Before manually deleting the huge efi_vars.fd (BTW similar size to the .qcow2 file (probably a coincidence?), size/content not identical):

I tried manually deleting the huge 4.13 GB efi_vars.df. After deleting the file, I restarted the VM and noticed no difference / no errors (VM still worked normally, I think). After that, there was a new much smaller efi_vars.df (size 655 KB).

Screen shot: After manually deleting the huge efi_vars.fd there was a new one, size is now reasonable (655 KB vs. 4.13 GB):

PS. I found this because I was wondering why the "size" reported by Edit Selected VM / VirtIO Drive was so different from the "size" reported by VM details, might be related / duplicate of #4741.

Please let me know if you need more information. I do have a backup of the huge 4.13 GB efi_vars.df file if you want to look at it.

Suggestion: in your own personal VMs, check the file size of efi_vars.fd inside each VM (especially ARM64 Linux VMs?) and see if any of them are too large / otherwise weird? Also try Compress / Reclaim Space?

Steps to reproduce:
(sorry, don't have good steps, I guess install arm64 Fedora Linux, install lots of packages inside, use Edit VM / VirtIO Drive / Compress (and/or Reclaim Space), remove lots of packages, use Compress (and/or Reclaim Space) again, use the VM for a couple of weeks, see if the efi_vars.df file is huge yet)

Configuration

• UTM Version: 4.3.5 (87)
• macOS Version: 14.0 Beta (23A5337a)
• Mac Chip (Intel, M1, ...): M1

[kyleneideck]

In one of my VMs, efi_vars.fd was 10 GB, but only 69 MB on disk. What's the size on disk for your 4 GB one? (Right click > Get Info in Finder or du -h.)

Apparently, efi_vars.fd is the VM's NVRAM, so I'd guess that it gets mapped directly it to the virtual NVRAM address space, or something like that, so QEMU doesn't have to manage that mapping itself. Then I think you could end up with large but sparse files if the VM writes to NVRAM addresses that are far apart.

[rxhfcy]

What's the size on disk for your 4 GB one?

2.8 GB on disk (!)

[osy]

Okay, so the explanation is that when you suspend, QEMU will save the RAM state into the first QCOW2 drive, which in this case happens to be the EFI vars. Now if you have 8GB of RAM allocated, that means up to 8GB of data could be stored there. To get rid of the space, you should resume the VM and shut it down properly.