← All articles

Parallels, VMware Fusion and VirtualBox: Finding Your Forgotten VMs

A Windows VM you spun up once still sits on disk at 40-80 GB. How to find every Parallels, VMware and VirtualBox image on a Mac and clear the dead ones.

· Updated September 14, 2026
VirtualizationParallelsVMwareVirtualBoxmacOSStorage

Of every category of disk cruft a developer accumulates, virtual machine images are the single largest individual files you’ll find — and the easiest to forget about entirely, because they don’t live in a folder you’d ever browse to by accident.

du -sh ~/Parallels/*.pvm
du -sh "~/Virtual Machines.localized"/*.vmwarevm
du -sh ~/VirtualBox\ VMs/*

A single Windows 11 VM with a couple of snapshots routinely runs 40–80 GB. Two or three of those, built for testing sessions that ended a year ago, is a genuinely large chunk of a modern SSD.

Parallels Desktop

Parallels stores each VM as a .pvm package (a folder that looks like a single file in Finder) under ~/Parallels:

ls -la ~/Parallels/
du -sh ~/Parallels/*.pvm | sort -hr

The size on disk is frequently much larger than the VM’s actual used space, because Parallels pre-allocates and rarely shrinks the disk image automatically. Two things reclaim space without deleting the VM outright:

# Compact a VM's disk image after deleting files inside the guest OS
prlctl set "VM Name" --device-set hdd0 --compact

# Remove old snapshots — each one keeps a full delta of everything changed since
prlctl snapshot-list "VM Name"
prlctl snapshot-delete "VM Name" -i <snapshot-id>

Snapshots are the silent killer here: a VM you actively use, with six months of accumulated snapshots, can be double or triple the size of the VM itself. If you don’t have a specific reason to roll back to an old state, delete everything except the most recent snapshot.

For a VM you no longer need at all, delete the .pvm package directly — there’s no safer, more regenerable way to lose data than deleting a VM you were done with, since by definition nothing else on your Mac depends on it:

rm -rf ~/Parallels/"Old Windows Testing.pvm"

VMware Fusion

Same shape, different folder — VMware Fusion keeps its VMs under ~/Virtual Machines.localized:

du -sh "~/Virtual Machines.localized"/*.vmwarevm | sort -hr

Each .vmwarevm bundle contains one or more .vmdk disk files. VMware’s compaction tool works the same way Parallels’ does — shrink after deleting data inside the guest, don’t expect it to happen automatically:

vmware-vdiskmanager -k "~/Virtual Machines.localized/Old VM.vmwarevm/Virtual Disk.vmdk"

VirtualBox

VirtualBox keeps VM definitions and disk images under ~/VirtualBox VMs by default, though this is one of the more commonly relocated defaults — check VirtualBox → Settings → General → Default Machine Folder if the directory looks emptier than expected:

du -sh ~/VirtualBox\ VMs/* | sort -hr

VirtualBox’s .vdi disk images support the same compact operation:

VBoxManage modifymedium disk "path/to/disk.vdi" --compact

The one thing to check before deleting any of these

Unlike a build cache, a VM can contain actual unique data — files you saved inside the guest OS that exist nowhere else. Before deleting a .pvm, .vmwarevm, or VirtualBox VM outright, boot it once and check whether there’s anything in the guest’s Desktop, Documents, or Downloads folders you meant to keep. Once you’re sure, deleting the whole package is safe and immediate — there’s no regeneration cost because there’s nothing to regenerate; you’d just create a fresh VM if you needed one again.

What this is really competing with

If your actual use case is “test my app on Windows occasionally,” a full persistent VM is often the expensive way to do it — UTM (free, Apple Silicon-native) or a cloud-hosted Windows instance you spin up on demand both avoid the standing 40–80 GB tax entirely. Worth reconsidering before you rebuild the VM you just deleted.

The commands above are free and they work. DevCruft, a free Mac app for developers that’s still in development, is being designed to find every VM image across Parallels, VMware and VirtualBox, show when each was last booted, and flag the ones nobody has opened in over a year. Join the waitlist to hear when it launches.

For Docker’s own disk image, which follows the same “pre-allocated and rarely shrinks” pattern, see the Docker disk space guide.

A free app for this is on the way.

We’re building DevCruft to find every cache in guides like this one and show what each costs you. Join the waitlist to hear when it launches.

One email at launch, nothing else. Ask us any time to remove you. Privacy policy