Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

vCenter says "Virtual machine disks consolidation is needed": why, and scenario-specific recovery decisions to clear it

Troubleshooting article
VMwareBackup & RecoveryTroubleshooting

A virtual machine shows the warning "Virtual machine disks consolidation is needed". Snapshot Manager shows "Needs Consolidation/Delete Snapshots" (KB 316575). The VM usually still runs, but on a chain of extra disk files that nothing is merging.

In plain terms: a snapshot was deleted or finished, but its delta file (the file holding the changes written since the snapshot) was never merged back into the base disk. A backup that did not finish cleanly is one documented cause (KB 321365).

This article explains how to investigate the holder and select a recovery path. A normal backup-proxy release and a removal-refused case need different decisions. Recovery work requires a demonstrated restore route and a case-specific plan; the explanations here do not establish a validated production runbook.

What is actually happening

A snapshot freezes the VM's base disk and sends new writes to a delta file named like VMNAME-000001.vmdk. Deleting the snapshot should merge that delta back into the base disk and remove it. That merge is called consolidation. When it cannot complete, vCenter flags the VM and leaves the delta files in place.

The merge cannot complete while something other than the VM's own process holds a lock on a snapshot file. A lock is a marker that tells the host who may use a file. A powered-on VM legitimately holds exclusive locks on its files (KB 316576). A backup proxy that still has the snapshot disk attached holds a lock too, and that blocks the merge (KB 321365, KB 374141).

Two facts shape the order. Once consolidation starts it cannot be stopped, and interrupting it can corrupt the virtual disks (KB 338534, KB 316414). Deleting a snapshot is also a merge into the base disk, so it carries the same risk. The merge is heavy on the datastore and may affect other VMs on it (KB 338534).

How to prove it

All steps here are read-only. Run them in an SSH session on the host where the VM is registered, or in the vSphere Client where stated.

  1. Confirm the flag. Right-click the VM and open Snapshot Manager. The message "Needs Consolidation/Delete Snapshots" confirms the condition. List the VM folder for -00000X.vmdk and -00000X-delta.vmdk files (KB 316575).

  2. Confirm which disk the VM runs on.

grep vmdk "/vmfs/volumes/<datastore>/<vm>/<vm>.vmx"
scsi0:0.fileName = "<vm>-000001.vmdk"

A -00000X name means the VM is running on a snapshot file, as in the example in KB 316575. That alone is normal if a snapshot exists. It is the fault when the flag in step 1 is also present.

  1. List snapshots.
vim-cmd vmsvc/getallvms
vim-cmd vmsvc/snapshot.get <Vmid>

Note which snapshots belong to your backup product and which were taken by people. Keep this list for the clearing section.

  1. Check for a running backup job on the backup server. KB 321365 and KB 374141 both begin with confirming that no job is active for the VM.

  2. Check datastore free space. KB 316575 lists less than 1 GB free as a cause that blocks consolidation.

  3. Find who holds the lock. - On ESXi 8.0 Update 2 and later, the lock owner appears in the vSphere Client under the VM's Monitor, Tasks and Events (KB 314365). The page documents this for a failed power-on. It does not say a failed consolidation task shows it, so use the command route if the task is silent. - Otherwise run this against the locked file:

vmfsfilelockinfo -p /vmfs/volumes/<UUID>/<VM>/<VM>-000001-delta.vmdk
vmfsfilelockinfo -p /vmfs/volumes/<UUID>/<VM>/<VM>-000001-delta.vmdk -v <vCenter IP> -u <user>

Without -v and -u the output names the lock holder by MAC address. With them the tool asks vCenter to map that address and reports the host IP address and lock mode (KB 314365). - On the lock-holding host, keep the header row so the Cartel column is labelled, then match the Cartel ID to a VM:

lsof | egrep 'Cartel|<VM>-000001-delta.vmdk'
esxcli vm process list

A holder other than the VM may explain a conflicting lock in the normal release case (KB 374141). Establish its identity and the exact error before selecting a branch; the scoped removal-refused exception is described below.

  1. Read the log lines. "Failed to lock the file" and "Device or resource busy" in the VM's vmware.log point to a stale lock. "Lock failed on file" appears in vmkernel.log (KB 321365, KB 374141).

  2. Check chain depth per virtual disk. KB 387210 states that 32 snapshots are supported in a single linear branch. Count the -00000X files for each disk.

Documented causes

The official pages do not rank their causes by frequency, so this order is by how directly the evidence points at them.

A backup proxy still holds the disk. A proxy VM attaches the snapshot disk to read it, and the job crashes or the product does not release it. Evidence: a lock owner that is not the VM's own process, "Failed to lock the file" in vmware.log. KB 321365 and KB 374141.

Snapshots were never removed after the backup. Evidence: snapshots in Snapshot Manager named by your backup product, or delta files while Snapshot Manager shows nothing (KB 316575 names this case). Do not compare the number of snapshots with the number of delta files: one snapshot creates a delta file per virtual disk, and a deleted snapshot's files stay until consolidation finishes, so the two counts can legitimately differ. A mismatch is a pointer, not proof.

vCenter and the ESXi host had connectivity issues during the operation. KB 316575.

Not enough free space on the datastore. KB 316575.

Too many snapshots. More than the supported depth in one branch. KB 387210.

A merge is still running. Large snapshots take long to commit and the VM can look frozen while the alert persists. Progress is not shown; the commit is working while file timestamps keep updating (KB 316575).

Recovery decisions and escalation

There is no universal detach-first sequence. The following decisions explain the options; they are not a lab-validated production runbook.

Before a modifying branch, record the exact VM, disk chain, proxy, datastore type and ESXi build. Confirm there is no active backup or merge, establish a separately preserved and demonstrably restorable backup, assess free capacity and effects on other workloads, and agree the outage and restore points that may be discarded. If a prerequisite is uncertain, preserve the logs and escalate rather than changing the chain. A backup verification report alone is not a demonstrated application restore.

  • The merge is progressing: observe its task, relevant file activity and logs. A static percentage or shared datastore activity alone cannot prove its state. Do not interrupt an active consolidation.
  • A backup proxy is the confirmed holder and normal removal succeeds: use the backup supplier's supported cleanup, identifying the protected disk separately from the proxy's own disks. Never select the option to delete datastore files. Once the conflicting holder is released, a qualified operator can assess the separately approved consolidation (KB 321365, KB 374141).
  • Removal is refused because the disk or its parent belongs to a snapshot: stop the normal branch. KB 375284 describes a distinct ESXi 7.x/8.x HotAdd case: the proxy is powered off, the target is consolidated, and the disk is detached from the still-powered-off proxy after success. Have the backup supplier or Broadcom confirm that exact symptom and applicability before using its procedure. This is not permission to consolidate with an arbitrary live holder. See https://knowledge.broadcom.com/external/article/375284.
  • A management agent is implicated: obtain a host-specific change plan. Include other running tasks and VMs, independent administration access, cluster protection and recovery if the agent does not return. Restart only the identified service under the applicable vendor guidance. If HA host monitoring is temporarily disabled, record its previous state, restore that state after service recovery and verify cluster protection. A restart is not a harmless lock probe. See https://knowledge.broadcom.com/external/article/320280.
  • Ownership, chain state or capacity remains uncertain: stop and open a support case. Do not progress to descriptor edits, disk cloning, new snapshots or host reboot as generic fallbacks.

Consolidation and snapshot deletion change the disk chain. Delete All discards every listed restore point and requires explicit owner agreement for every point being removed; it is not synonymous with removing only backup-created snapshots. This article does not prescribe a create-snapshot/Delete-All sequence.

After an approved recovery, verify task completion, the consolidation flag, every active disk chain and the intended retained snapshots. Delta files can legitimately remain where snapshots were retained; absence of every numbered file is not a universal success test. Check guest and application correctness, then verify backup cleanup and a representative restore. If recovery has succeeded, verify and stop instead of consolidating again.

What not to do

  • Do not consolidate or delete snapshots before a verified backup exists. Both are merges that cannot be stopped (KB 338534).
  • Do not treat proxy detachment as a universal prerequisite. Use the normal release path unless a specialist confirms the specific removal-refused exception in KB 375284; never generalise it to an unknown live holder.
  • Do not choose "Delete files from the datastore" when removing a disk from a proxy. It deletes the VM's disk (KB 321365).
  • Do not interrupt a running consolidation (KB 316414).
  • Do not delete delta files by hand. They hold the VM's data since the snapshot.
  • Do not move or delete NFS lock files from this guide. Preserve ownership evidence and obtain a storage-specific expert procedure.
  • Do not force-kill a VM process. It is a hard shutdown (KB 316576).
  • Do not edit disk paths or rename files. We have seen a case where failed backup operations left extra delta files, a consolidation was then run out of order, and the original base disk name was lost. Consolidation could not bring the name back; putting it right needed ESXi experts working by hand on the datastore.
  • Do not guess at disk chain repairs. Open a VMware support request (KB 316576).

Acceptance checklist

These are required checks, not completed test results.

  • [ ] Exact target, storage/build and per-disk chain recorded.
  • [ ] Active merge distinguished from conflicting holder.
  • [ ] Demonstrated restore route and capacity/impact reviewed.
  • [ ] Normal removal or matching exception selected; ambiguous ownership stops work.
  • [ ] Restore-point removal explicitly approved where applicable.
  • [ ] Any temporary HA change restored and protection checked.
  • [ ] Intended chain and retained snapshots verified; application and restore checks completed.

Sources

  1. KB 316575, Consolidating/Committing snapshots in VMware ESXi. https://knowledge.broadcom.com/external/article/316575 (ESXi and vCenter Server 8.x and 9.x)
  2. KB 321365, Snapshot consolidation fails due to locks held by third-party backup software. https://knowledge.broadcom.com/external/article/321365 (ESXi and vCenter Server 7.x to 9.x)
  3. KB 374141, Snapshot Consolidation Failure: "Failed to lock the file". https://knowledge.broadcom.com/external/article/374141 (ESXi and vCenter 8.x and 9.x)
  4. KB 316576 (legacy KB 2107795), Troubleshooting issues resulting from locked virtual disks. https://knowledge.broadcom.com/external/article/316576 (ESXi 6.x, 7.x, 8.x)
  5. KB 314365, Investigating Virtual Machine file locks on ESXi Host(s). https://knowledge.broadcom.com/external/article/314365 (ESXi 7.x, 8.x, 9.x)
  6. KB 387210, Resolving VM Consolidation Issues with Large Numbers of Snapshots. https://knowledge.broadcom.com/external/article/387210 (vSphere and vSAN OSA)
  7. KB 338534, Estimate the time required to consolidate virtual machine snapshots. https://knowledge.broadcom.com/external/article/338534 (ESXi 7.x and 8.x)
  8. KB 316414, How to calculate current snapshot size, estimate consolidation times. https://knowledge.broadcom.com/external/article/316414 (ESXi 6.x to 9.x)

Additional source checked 24 October 2026: https://knowledge.broadcom.com/external/article/375284

Additional source checked 24 October 2026: https://knowledge.broadcom.com/external/article/320280