VMware Snapshot Consolidation Stuck: How to Fix Without Data Loss
You open vCenter and see the yellow warning icon next to a VM. "Virtual machine disks consolidation is needed." You click Consolidate, the task starts, and then it either fails immediately with a file lock error or sits at 30% for the next six hours while you sweat.
I've dealt with this enough times that I have a playbook. Snapshot consolidation issues fall into a handful of failure modes, and once you can identify which one you're looking at, the fix becomes predictable instead of terrifying.
What "Needs Consolidation" Actually Means
When you delete a snapshot in vCenter, the delta file (the -000001-delta.vmdk that holds changes since the snapshot was taken) needs to be merged back into the parent disk. VMware calls this process consolidation. Most of the time it happens invisibly as part of the snapshot deletion. You never see the word "consolidate" at all.
The "Needs Consolidation" flag appears when that merge failed partway through. VMware successfully updated the snapshot database (the .vmsn file and the vCenter inventory) to remove the snapshot entry, but the delta files on the datastore are still sitting there. Your VM is now running on a snapshot that vCenter doesn't think exists. Left unchecked, that delta file keeps growing until your datastore fills up. This is the same root problem I cover in the snapshot performance article, but here we're dealing with the specific case where the cleanup already failed and vCenter is telling you about it.
The consolidation warning is not cosmetic. It means your VM is running on delta disks that are not in vCenter's snapshot tree. If you reboot or migrate that VM, things can get worse.
Why Consolidation Gets Stuck
There are four reasons consolidation fails, and identifying the right one determines your fix:
File locks. A backup product (Veeam, Nakivo, Commvault, or anything using the VADP snapshot API) took a snapshot for its backup job and then failed to release the read-only lock on the delta file. VMware can't merge a file that another process has locked. This is the single most common cause, and Broadcom documents it directly in KB 374141.
Insufficient datastore space. Consolidation needs working room to merge the delta into the base disk before deleting the delta. The minimum is about 1 GB of free space, but that's the floor. A VM with a 200 GB snapshot delta can't consolidate on a datastore with 5 GB free. The merge runs out of room and fails.
vCenter to host communication failure. If vCenter loses its connection to the ESXi host mid-task, the consolidation task hangs. The host might still be processing, or it might have given up. You can't tell from vCenter because the connection is gone. This ties into the same connectivity problems I wrote about in the vCenter host disconnection troubleshooting guide.
The task genuinely never finishes. Sometimes consolidation starts, appears to work, and then the task runs for 12, 24, 48 hours with no progress. The delta file timestamps stop updating. VMware's snapshot manager thinks everything is fine. Nothing is happening.
The Safe Recovery Path
Before touching anything, gather information. Panic-deleting files is how people lose VMs.
Check whether consolidation is actually stuck or merely slow. SSH into the ESXi host running the VM and go to the VM's directory on the datastore:
cd /vmfs/volumes/your-datastore/your-vm-name
ls -la
Look at the timestamps and sizes on the delta files (anything ending in -delta.vmdk on VMFS, or -sesparse.vmdk on newer vSphere VMFS-6 and vSAN chains). The -flat.vmdk is the base disk extent, not a delta, but its activity can still tell you whether writes are landing. Check again in 10 minutes. If timestamps or sizes are changing, consolidation may still be running and you need to wait. Large deltas take hours to commit. Changing files are a good sign, but not the only signal — also tail the host's vmkernel.log and hostd.log for snapshot-related entries before assuming the process is hung.
If the timestamps are frozen, check the lock state. This is where most people get stuck. Run vmkfstools -D against the delta file to see who holds the lock:
vmkfstools -D your-vm-000001-delta.vmdk
The output gives you a few important fields. Look for the RO Owner line, which contains a MAC address. That MAC belongs to the vmkernel adapter of the ESXi host that holds the lock. If the MAC is all zeros (00:00:00:00:00:00), the file is not locked, and your problem is something else (probably space). If there's a real MAC, an ESXi host has the file locked.
The Mode field gives you a hint about the lock type, but do not rely on mode alone to decide what to kill. Match the owner MAC to a host, then to the specific world ID or process holding the file. Mode 1 is a read-write lock, typically the VMX process of a powered-on VM. Mode 2 is often a backup application holding a read-only lock, but confirm against the owner host and process rather than assuming. If you see Mode 2 and the MAC belongs to a host running your backup proxy, your backup software left a stale lock.
On newer ESXi versions, vmfsfilelockinfo resolves ownership more directly than reading raw vmkfstools -D output:
vmfsfilelockinfo -p /vmfs/volumes/your-datastore/your-vm-name/your-vm-000001-delta.vmdk
Cross-reference the MAC to find the host:
Get-VMHost | Select Name, @{N='VMkernelMAC';E={(Get-VMHostNetworkAdapter -VMHost $_ | Where-Object {$_.ManagementTrafficEnabled} | Select -First 1).Mac}}
That PowerCLI snippet lists every host and its management vmkernel MAC so you can match it against the lock owner.
Clearing File Locks
If a backup product left a stale lock, the cleanest fix is to deal with it on the backup side first. Restart the backup service on the proxy server or the backup server. Veeam, for example, has a Veeam Backup Service you can restart from Services.msc. This often releases orphaned VADP handles.
If that doesn't work, you need to clear the lock at the ESXi level. The safest approach:
- Shut down the VM cleanly, not a suspend.
- Identify the locked delta file with
vmkfstools -D. - If the lock owner is the host you're on and the VM is powered off, the lock should release automatically once the VM's
.vmxprocess is gone. - If the lock persists (another host holds it), log into that host and find the process holding the file:
lsof | grep your-vm-name. - Kill the orphaned process if you can identify it as a backup proxy remnant.
I've seen cases where the only way to clear a stubborn lock is to put the ESXi host into maintenance mode and reboot it. That's heavy-handed and should be a last resort, but if a backup proxy wedged the VMFS lock and nothing else releases it, a host reboot clears it. Plan for downtime and make sure VMs can vMotion off first.
When It's a Storage Space Problem
Check your datastore free space before attempting consolidation:
df -h /vmfs/volumes/your-datastore
If you're under 10% free space, consolidation will likely fail. The delta needs to merge into the base disk, and VMware needs working room to do that. The official minimum scratch space is small, but in practice the requirement scales with your snapshot size, disk format, datastore type, and how busy the VM is during the commit. A safe operational rule: have free space at least equal to your largest active delta file, plus a buffer for ongoing writes.
Options to free space: delete orphaned ISOs, move other VMs to another datastore with Storage vMotion, or delete old snapshot deltas that are truly orphaned (meaning you've confirmed they're not in any VM's disk chain). Do not manually delete delta files that are part of an active chain. That destroys the VM. If datastore capacity is chronically tight, adding enterprise SSDs to expand your storage pool is cheaper than losing a VM to a failed consolidation.
If you can't free enough space on the current datastore, you can Storage vMotion the VM to a datastore with more room. Relocation can sometimes clean up or simplify the disk chain during the move, but it is not a guaranteed fix for an active lock or a broken chain. If locks are already cleared and the only constraint is space, this is one of the cleaner recovery options.
The "Take a New Snapshot" Trick
There's a recovery method that sounds wrong but works often enough that every VMware admin should know it. When consolidation is stuck and the normal Consolidate button does nothing or the option is greyed out:
- Shut down the VM cleanly.
- Take a new snapshot.
- Immediately delete all snapshots (Delete All, not Delete).
- Power the VM on and run Consolidate again.
The logic here is that creating a new snapshot and then doing Delete All forces VMware to walk the entire snapshot chain and commit every delta in sequence. Sometimes this succeeds where the standalone consolidation failed because the snapshot manager rebuilds the chain from scratch and handles the file operations differently.
This is not guaranteed and I've seen it fail when the underlying problem (a lock or a space issue) is still present. Only attempt it after you have confirmed: no consolidation task is currently running, backup locks are cleared, the datastore has enough free space for the largest delta plus buffer, and you have a current backup or restore plan. Adding another delta to a chain that is already broken makes the situation worse, not better.
The Backup Software Shortcut
If you run Veeam or a similar product, there's another approach that community forums surface repeatedly: trigger a fresh backup job against the affected VM. The backup software creates its own snapshot, completes its job, and then removes the snapshot through its own cleanup path. This can clear a stuck consolidation state because the backup product's snapshot removal runs a different code path than vCenter's Consolidate button.
I would not rely on this as a first-line fix because if the backup fails again (same lock, same space issue), you've added another delta to the chain and made the situation worse. But as a recovery method after you've cleared locks and confirmed space, it's worth trying.
What Not to Do
Do not blindly cancel a consolidation task or restart services just because vCenter looks stuck. First verify whether host-side consolidation is still active by checking delta file timestamps, sizes, and ESXi logs. If ESXi is still committing the snapshot chain, interrupting it risks corrupting the disk chain. If the task is genuinely stale (timestamps frozen, no log activity), then you can proceed with the recovery steps above. Even if it takes 24 hours, patience is cheaper than a corrupt VMDK.
Do not manually delete -delta.vmdk files from the datastore browser. Ever. If those deltas are part of the active disk chain, deleting them breaks the chain and the VM will not boot. The only safe way to remove delta files is through VMware's own consolidation process.
Do not create new snapshots while consolidation is in progress. This extends the chain and can cause the consolidation logic to fail.
Do not ignore the "Needs Consolidation" warning hoping it resolves itself. It won't. The delta file keeps growing and your datastore fills up.
Preventing It Next Time
The root cause is almost always a backup job failing to clean up its snapshots. Check your backup software's logs for snapshot removal failures and address those. Veeam has a built-in snapshot retention check. Make sure it runs. If you don't have a proper backup target yet, a Synology NAS with enterprise drives gives you a reliable repository that won't leave your snapshots orphaned when a job fails.
Keep datastore free space above 15%. Snapshot operations need headroom, and a datastore running at 95% is a ticking bomb for consolidation failures.
Set vCenter alarms for snapshot size. A VM with a delta larger than 10-15 GB is either a long-running snapshot that someone forgot or a consolidation failure in progress. Either way, you want to know about it before vCenter does.
If you're dealing with chronic snapshot headaches, some teams are reevaluating whether the VMware stack is worth the operational overhead. The migration path to Proxmox eliminates the VADP lock problem entirely since Proxmox uses a different snapshot mechanism. I walk through that in the Proxmox migration guide. Not suggesting you jump ship over one consolidation failure, but if this is a recurring monthly incident, it's worth knowing the alternatives.
For SSH access to your ESXi hosts (which you'll need for all the commands above), make sure root SSH is enabled. If you've lost that access, the ESXi root password reset guide covers recovery without wiping the host.
When to Stop and Call Broadcom Support
There is a line where blog-post troubleshooting ends and professional support begins. If the VM is business-critical, the snapshot chain has multiple deltas and the descriptors look inconsistent, or you are considering manually editing descriptor files or deleting VMDKs to repair the chain, stop and open a Broadcom support case. Manual chain repair is possible, but it carries real data-loss risk and is not something to attempt from a web tutorial. The diagnostic work above — identifying locks, checking space, reading logs — is safe and gives the support engineer exactly what they need to help you faster.
Recovering Without Losing Data
Snapshot consolidation failures are recoverable if you stop and diagnose before acting. Identify whether it's a lock, a space issue, or a hung task. Clear locks at the source. Free space. Try the new-snapshot-Delete-All trick. Let in-progress consolidations finish. And fix the backup job that created the mess so you're not back here next weekend.