Virtual machine disks are one of the least intuitive storage problems on a Mac because the tools that manage them — Parallels Desktop, VMware Fusion, and UTM — each have their own disk format, their own snapshot mechanism, and their own idea of when a disk should shrink back down. Delete files inside a Windows VM, and the disk image on your Mac's SSD often doesn't get any smaller, because the deletion happened inside the guest operating system, not to the host file that represents its storage. Understanding that distinction is the starting point for reclaiming this space properly.
Growable versus pre-allocated: why it matters
Every major VM platform lets you choose between two disk allocation strategies when creating a virtual machine:
Growable (dynamically expanding) disks start small and expand as the guest OS writes data, up to a maximum size you set at creation. This is the default in most setups because it avoids reserving space upfront. The catch is asymmetry: the disk grows automatically as you use it, but does not shrink automatically when you delete files inside the guest — freeing space inside Windows or Linux doesn't tell the host disk image it can hand that space back.
Pre-allocated (fixed size) disks reserve their full maximum size on your Mac's drive immediately at creation, regardless of how much data is actually inside. These offer marginally better performance in some cases, but they mean the size shown in Finder is fixed from day one and gives you no signal about how full the guest actually is.
Check which type you're dealing with in each platform's virtual machine settings before assuming a large file size reflects a problem — a 100GB pre-allocated disk showing 100GB used is working exactly as designed.
Snapshots: the most common cause of unexpected VM disk growth
Snapshots let you save a VM's state and roll back to it later, and each one you take adds a delta file capturing every change made since. If you take snapshots before risky changes (installing software, testing an update) and never clean them up, a virtual machine's total footprint can grow well past its nominal disk size, because you're storing not just the current state but every historical delta between snapshots.
The fix here is always the same across platforms: delete snapshots you don't need to roll back to anymore, oldest first if you're unsure. Parallels manages this through its Snapshots manager in the VM's control centre; VMware Fusion through Virtual Machine → Snapshots; UTM's snapshot support depends on the backend but follows the same principle. In every case, deleting a snapshot merges its changes into the parent state and removes the now-unneeded delta file, which is what actually recovers the space.
Compacting: telling the disk to shrink
Compacting is the operation that reclaims space a growable disk accumulated but no longer needs, after files were deleted inside the guest. It works by having the platform scan the virtual disk for blocks marked as free by the guest filesystem and rewrite the disk image without them.
| Platform | Where to compact |
|---|---|
| Parallels Desktop | Configure → Hardware → Hard Disk → Reclaim disk space (or Free Up Disk Space in the VM's control centre) |
| VMware Fusion | Virtual Machine → Settings → Hard Disk → Compact, or via vmware-vdiskmanager for advanced cases |
| UTM | Depends on the backend (QEMU disks can be compacted with qemu-img convert, since UTM doesn't always expose a one-click option) |
Before compacting, it helps to first empty the guest's own Recycle Bin or Trash and, on Windows guests, run Disk Cleanup inside the VM — compacting can only reclaim space the guest OS has actually marked as free, not space still sitting in the guest's own trash.
Why a compact operation can itself need free space temporarily
Compacting typically works by writing a new, smaller disk image and replacing the old one, which means the operation can briefly require almost as much free space on your host Mac as the VM disk currently occupies, before it finishes and the old file is removed. If your Mac's available space is already very low, a compact operation can fail partway through for lack of room to work — check your actual free space before starting, not just the size of the VM disk you're trying to shrink.
Deleting a VM entirely versus just its disk
If you're removing a virtual machine you no longer need, delete it through the platform's own VM library or manager (Parallels' Control Center, VMware Fusion's Virtual Machine Library, UTM's main window) rather than manually locating and deleting the .pvm, .vmwarevm, or .utm package from Finder. Each of these is a package bundle containing the disk image plus configuration and snapshot metadata, and removing it through the app ensures any associated registration or snapshot chain is cleaned up consistently rather than leaving orphaned references behind.
Finding VM disks you've forgotten about
Virtual machine files are large enough that a forgotten one — a test environment spun up once and never revisited — is often one of the biggest single items on a developer's Mac. They're not always where you'd expect either; Parallels defaults to ~/Parallels, VMware Fusion to ~/Virtual Machines.localized, and UTM to wherever you told it during setup, and any of these can be moved. A size-sorted view of the whole disk finds these regardless of location, which is more reliable than checking each platform's default folder individually.
Where VolumeLens comes in
VM disk packages show up in VolumeLens sized as whole units, the same way any large package bundle does, which makes it straightforward to spot a .pvm, .vmwarevm, or .utm file that's grown far beyond what you remembered — often the trigger to go compact it or check its snapshots properly in the platform's own tools. VolumeLens doesn't compact or modify VM internals itself; it scans locally and its only action is Move to Trash after review, which is exactly right for a file type where the actual fix usually belongs to the platform that created it.