The VM uses 40 GB inside, but its folder on your drive is 110 GB - and the host disk is now full. Nothing leaked and nothing is corrupt. Your snapshots have been quietly writing every change the VM made for months into delta files that only grow. Here is how they work and how to take the space back without losing data.
A snapshot does not copy your disk. It freezes the base disk and writes all new changes into a delta file - names like -000001.vmdk. Every day the VM runs, the delta grows. Take a second snapshot and a second delta starts, and reads must cross all of them. Snapshots are brilliant for a risky afternoon and terrible as a storage strategy. Reclaiming the space means merging deltas back through the Snapshot Manager - never by deleting files by hand.
Compare two numbers: the space used inside the guest, and the size of the VM folder on the host. A big gap between them is snapshot data. Open the Snapshot Manager from the VM menu to see the tree - which snapshots exist, in what order, and how old they are. This map matters: deleting a snapshot merges its changes forward into the next layer or the current state, and you should know your own tree before you start merging it.
In the Snapshot Manager, select a snapshot and choose Delete - Workstation merges that delta into the chain safely instead of discarding data. Practical rules that keep this painless:
Sometimes Workstation itself reports that virtual machine disks consolidation is needed - usually after a snapshot deletion was interrupted. Use the consolidation option Workstation offers on the VM rather than improvising. This message is the product telling you leftover delta files exist that it can fold back safely. Let it. The worst possible response to this message is opening the folder and deleting the strange-looking files yourself.
Here is the part nobody warns you about: if the host disk reaches completely full while a VM runs, the delta file cannot grow, and Workstation may pause the VM to protect it. The VM looks frozen; the cause is arithmetic, not damage. Keep real free space on any drive that hosts VMs - treat under 10 percent free as an emergency, not a statistic.
Snapshots are checkpoints for hours or days, not backups. The healthy rhythm: take one snapshot before a risky change, test, then delete it the same week. A snapshot you have kept for six months is not protecting you - it is charging you rent in disk space and read speed. Real backups are a powered-off copy of the whole VM folder or a proper backup tool, stored somewhere else entirely.
The video covers VM configuration with storage in mind - watch it to set up VMs that do not silently eat the drive.
Watch Full VideoDelete merges that snapshot's changes back into the chain and removes the checkpoint - your current state survives. Go To travels back in time to that snapshot, discarding the state you were in unless you snapshot it first. Clone builds a separate new VM from that point. Only Delete reclaims space.
No. Those files are the snapshot - the delta holds every change since it was taken, which usually includes your newest work. Deleting them corrupts or rolls back the VM. Space is only ever reclaimed by merging through the Snapshot Manager.
As few as possible - ideally one short-lived checkpoint around a risky change, deleted within days. Each extra layer costs disk space and read performance. If you find a VM carrying months of snapshots, consolidate them and switch to real backups for anything you actually care about.