VMware Snapshots: Why Your VMs Get Slow

What a snapshot actually does on disk

When you take a snapshot of a running VM, ESXi does not copy the disk. It freezes guest I/O for a few milliseconds, marks the base disk (vmname-flat.vmdk) read-only, and opens a new redo log called a delta file, vmname-000001-delta.vmdk. Every write after that point lands in the delta. The base disk is never touched.

This is redirect-on-write, not the copy-on-write pattern storage admins usually mean by that term. The guest sees a normal virtual disk. Underneath, the hypervisor tracks which grains (4 KB or 16 KB blocks) have been modified and answers each read by checking the top delta first, then walking down the chain towards the base disk only if the requested grain is not in a delta layer.

The consequence that catches people off guard: a single small snapshot adds almost no overhead. The slow death comes from elapsed time and chain depth. As the delta grows, new writes still cost one I/O, but reads that miss in the top delta must traverse the chain. A read that has to fall through to the base disk on a four-level chain is four lookups before the first byte comes back.

The two delta formats, and why grain size matters

ESXi writes deltas in one of two sparse formats. vmfsSparse is the original, used on VMFS5 datastores and for thick-provisioned disks, with a default grain size of 16 KB. SEsparse is the modern default: every VM on a VMFS6 datastore gets SEsparse deltas regardless of disk provisioning, the grain size drops to 4 KB, and the format supports space reclamation through UNMAP. SEsparse arrived back in vSphere 5.5.

Grain size matters because it is the unit of write amplification. When a guest writes to a block that has not been touched since the snapshot was taken, ESXi must first copy the existing grain out of the base disk (or a lower delta) into the snapshot layer before redirecting the new write there. A 4 KB write to a fresh grain on a 16 KB-grain delta means a 16 KB read plus the new write, all to preserve the unchanged 12 KB. This read-modify-write penalty is why a VM under snapshot can show double or triple the read IOPS you would expect from the guest's own workload.

Why the VM gets slow, and when it gets dangerous

The performance curve is not linear. For the first hours or a day, a delta on a healthy datastore is invisible to users. Once the delta passes a few tens of gigabytes, latency climbs in two directions. Read latency climbs because of chain traversal. Write latency climbs because of read-modify-write on a growing set of untouched grains. The exact crossover depends on your spindle count, cache, and how random the write pattern is.

The dangerous part is space. A delta file only ever grows until you delete the snapshot. There is no auto-shrink. I have seen a 40 GB delta on a 100 GB base disk push a datastore past 95% full, which is the zone where you have almost no room left for delta growth, thin-provisioned disks, swap files, and the working space a consolidation needs. Push it to 100% and ESXi stops accepting new writes from every VM sharing that datastore, not just the snapshotted one. If the datastore fills completely during a consolidation, the VM can stall or power off and the delta chain is left in a half-merged state.

The 32-level limit, and why you will never want to test it

VMware documents a maximum of 32 snapshots in a single chain. That is a hard limit, not a target. Long before 32, read latency compounds with every level. Most environments feel pain at three to four levels, and anything in the double digits is usually a sign that a backup product or a forgotten change window left snapshots behind. The fix is never to add another level. It is to find out why the existing ones were not committed.

If you run a third-party image backup product (Veeam, Nakivo, most others) and it fails to clean up after itself, you can end up with dozens of orphaned deltas that the backup console no longer tracks. The VM keeps running on top of them. This is a frequent reason a VM's performance degrades with no obvious configuration change on your side.

Memory snapshots and the .vmsn file

A snapshot taken on a powered-on VM can optionally capture memory. That state lands in a .vmsn file roughly the size of the VM's configured RAM, so a 64 GB VM produces a near-64 GB .vmsn. That file sits on the datastore next to the delta and counts against your free space.

When you quiesce the guest filesystem (the checkbox in the vSphere Client), ESXi coordinates through VMware Tools: the Microsoft VSS provider on Windows, or the sync driver on Linux. Quiescing attempts to produce an application-consistent point if the guest's VSS writers complete successfully. If they do not, you get a crash-consistent or file-system-consistent snapshot instead. Quiescing is what backup products need to do a clean restore, but it also means the snapshot takes longer to create and longer to commit, because ESXi has to flush and freeze I/O across the guest stack. A quiesced snapshot on a busy SQL Server can take minutes to create, during which the VM's write latency spikes.

Why consolidation fails

Deleting a snapshot does not remove the delta. It merges the delta's contents back into its parent disk. That merge is consolidation. On a running VM, ESXi reads the delta, writes the changed grains into the parent, then drops the delta. The VM keeps serving I/O throughout, now redirected to the parent.

Consolidation fails for a small set of reasons, and they are almost all storage-related. The first is free space: the active and helper redo logs can keep growing while a consolidation runs on a powered-on VM, so you need substantial headroom on the datastore, and tight free space is the most common reason consolidation fails outright. The second is a powered-off VM mid-operation. If a host loses power or the VM is killed while consolidating, the chain is left half-merged. The third is a storage path failure: if the host loses access to the LUN during the commit, the merge stalls and vCenter cannot resume it cleanly. The fourth, specific to vCenter tasks, is a timeout when consolidation runs longer than the task's internal limit against a very large delta.

When any of these happen, vCenter flags the VM with a warning: "Virtual machine disks consolidation is needed." The VM keeps running, but it is now running on a chain that vCenter cannot reconcile on its own without intervention.

Storage problems like this cascade into host-level symptoms too. A stalled consolidation task can drag a host's storage latency up and surface as the host disconnecting or becoming unresponsive in vCenter, which is covered in the ESXi host disconnected troubleshooting guide.

Finding every snapshot in vCenter with PowerCLI

The fastest way to find runaway snapshots is not the vSphere Client, which shows snapshots one VM at a time. PowerCLI gives you the whole estate in one pass:

Get-VM | Get-Snapshot |
  Select-Object VM, Name, Created,
    @{N='AgeDays';E={[int]((Get-Date) - $_.Created).TotalDays}},
    @{N='SizeGB';E={[math]::Round($_.SizeGB,1)}} |
  Sort-Object AgeDays -Descending |
  Format-Table -AutoSize

SizeGB is the delta size on disk. AgeDays tells you immediately which ones were left behind by a change window three months ago. Anything older than a few days on a production VM is worth investigating. To find VMs that specifically need consolidation:

Get-VM | Where-Object { $_.ExtensionData.Runtime.ConsolidationNeeded } |
  Select-Object Name, PowerState

PowerCLI does not expose a dedicated cmdlet for consolidation. You call the vSphere API directly on the VM's extension data:

$vm = Get-VM "MyVM"
$vm.ExtensionData.ConsolidateVMDisks_Task()

Check the task in vCenter or poll it with Get-Task to see when the merge finishes.

For a broader tour of operational PowerCLI, the VCF PowerCLI guide extends these same patterns to the rest of the stack, from inventorying hosts to checking license state.

The corresponding create and remove commands are the ones you run around a change window. Note that memory snapshots and quiescing serve different purposes, so split them rather than combining both flags on one snapshot:

# Application-consistent snapshot for a backup-style capture
New-Snapshot -VM $vm -Name "PrePatch-2026-08-03" -Quiesce

# Or, a memory snapshot to roll back to a live running state
New-Snapshot -VM $vm -Name "PrePatch-2026-08-03" -Memory

# Remove it once the change is validated
Get-Snapshot -VM $vm -Name "PrePatch-2026-08-03" |
  Remove-Snapshot -Confirm:$false

The -Quiesce flag needs VMware Tools in the guest and produces an application-consistent point when the VSS writers cooperate. The -Memory flag captures RAM into the .vmsn file, adding roughly the VM's configured memory size to datastore usage, but lets you revert to a live running state.

Committing a large delta without killing the datastore

When the delta is large (tens of GB or more), do not delete the snapshot during business hours on a running production VM. Schedule a window, and commit when the datastore has substantial headroom, more if the chain is multi-level and the VM stays powered on during the merge.

If free space is tight, the safe sequence is to storage vMotion the VM to a datastore with headroom first, then consolidate there, then move it back if you need to. A storage vMotion with an active snapshot chain works, but it copies the whole chain, so budget time for it.

Before committing anything destructive, get an independent copy of the VM's data off the datastore. Snapshotting is not a backup: the base disk and the deltas all sit on the same LUN, so a datastore failure takes the snapshot and the original with it. Offload to a real backup target. If your storage is the bottleneck on capacity or throughput, that is the time to add a dedicated backup repository or faster datastore capacity. A NAS-class box like the Synology DS1522+ running as an iSCSI or NFS backup repository gives you a copy that survives a datastore loss, and Samsung PM9A3 U.2 NVMe drives in the host bring both the throughput and the free-space headroom that large deltas consume.

When a snapshot is the wrong tool

Snapshots are for short-lived change windows: patch a host, apply a guest update, make a config change, then commit. They are not backups. They are not a way to freeze a VM's state indefinitely. They are not a rollback mechanism you can rely on across reboots and weeks of churn, because the delta keeps growing and the commit keeps getting more expensive the longer you wait.

If you catch yourself keeping a snapshot for weeks in case something goes wrong, the snapshot has become your backup strategy, and it is a bad one. A real backup product takes an independent copy off the host, and most of them do it by taking and committing a snapshot as a transport mechanism, then cleaning up after themselves. When that cleanup fails, you inherit the orphaned delta, which is exactly what the PowerCLI query earlier in this article is designed to catch.

Testing this behavior in isolation first saves a lot of pain later. Filling a delta, pushing a datastore full, and watching a consolidation fail and recover is something you want to do once without production on the line. A home lab build is the right place to run that experiment.

The cost angle is worth a mention because snapshot incidents are the kind of issue that turns into a support ticket, and support is something you pay for under the current per-core subscription model. The Broadcom VMware licensing breakdown covers the bundle pricing and per-core structure if you need to weigh what that ticket actually costs you.