Snapshot consolidation fails due to locks held by third party backup software

Products

VMware vSphere ESXi VMware vSphere ESXi 7.0 VMware vSphere ESXi 8.0

Issue/Introduction

This article covers unwanted file locks caused by backup applications with a proxy VM.

Errors that may be seen:

Snapshots cannot be committed.
Snapshots commit without errors and Snapshot Manager is no longer populated. However, a snapshot disk remains in the VM directory, and the VM still runs on that snapshot.
Consolidation failed with the errors similar to:

Failed to lock the file

One or more disks are busy

Unable to consolidate virtual machine snapshots due to file lock

Unable to access file since it is locked

The VM summary tab displays messages similar to:

Snapshot consolidation required

Virtual machine disks consolidation is needed

Virtual machine Consolidation Needed status

Note: For additional symptoms and log entries, see the Related Information section.

Environment

VMware vSphere ESXi

Cause

A third party vendor's backup solution backup proxy VM, or other VM, holds a lock on the base disk, or on a previous snapshot file of the VM that has the consolidation issue. This prevents snapshot consolidation from succeeding.
A third party vendor's backup solution does not complete a backup gracefully, or fails to clean up properly.
A third party vendor's backup solution does not follow VADP documented workflow. A typical example: the snapshot disk is not closed properly before snapshot delete and consolidation.

Resolution

Upgrade to latest version of the backup software.
For example, it's recommended to upgrade to CommVault v11.36 or later, Cohesity v7.3 or later.
Investigate locks to locate the third party backup solution's proxy VM with the disk attached: Investigating virtual machine file locks on ESXi hosts
To resolve this issue caused by backup with VDDK HotAdd transport mode, remove the VM disk(s) from the backup proxy VM.
Caution: Make sure there is no backup job running on the VM that has the consolidation issue.
1. Right-click the backup proxy VM.
2. Click Edit Settings.
3. Expand all the Hard Disk(s).
4. Select the Hard Disk(s) belonging to the VM that has the problem.
5. Click on the X beside the Hard Disk to unmount the Hard Disk from the VM.
  Caution: Do NOT select Delete files from the datastore.
6. Click OK.
7. Consolidate/Delete the snapshot on the VM (see step 4 if using vSAN)
If on vSAN move the lock files to a subfolder before consolidation.
1. cd into the VM namespace/folder on the datastore
2. Create a subfolder to hold the lock files (eg mkdir locks)
3. mv the lock files to this folder with mv .*lck locks
4. Proceed with the consolidation
To resolve this issue caused by backup with VDDK NBD/NBDSSL/SAN transport mode, kill the specific backup process in the backup proxy.
Caution: Make sure there is no backup job running on the VM that has the consolidation issue.
1. You might need 3rd party backup vendor's help to identify the backup process.
2. Or, make sure no backup job is running on the backup proxy then reboot the backup proxy
To resolve this issue caused by the wrong backup workflow of 3rd party backup solutions, backup vendors should implement proper failure cleanup.
1. The backup software should ensure every disk is closed to free the lock on ESX hosts after the disk open.
2. If the backup process is somehow killed, proper cleanup should be implemented to recover by calling VDDK functions VixDiskLib_Cleanup, VixDiskLib_EndAccess, etc.

Additional Information

You might experience these additional symptoms:

Datastore storage consumption rate is high

In the VM's vmware.log, located at /vmfs/volumes/<datastore>/<vmNameDirectory>/vmware.log you see errors similar to:

vmx| ConsolidateOnlineCB: nextState = 2 uid 3
vmx| Foundry operation failed with system error: Device or resource busy (16), translated to 5
vmx| ConsolidateOnlineCB: Done with consolidate

When you attempt to remove the datastore, you see this error:
```
The resource '<VMFS-UUID>' is in use.
```

If you are running third party back up software, consolidation might fail with the following errors in vmware.log file:

vcpu-0| Vix: [8803 mainDispatch.c:4084]: VMAutomation_ReportPowerOpFinished: statevar=3, newAppState=1881, success=1 additionalError=0
vcpu-0| Vix: [8803 vigorCommands.c:577]: VigorSnapshotManagerConsolidateCallback: snapshotErr = Failed to lock the file (5:4008)
vcpu-0| SnapshotVMXConsolidateOnlineCB: Destroying thread 6
vcpu-0| Turning off snapshot info cache.
vcpu-0| Turning off snapshot disk cache.
vcpu-0| SnapshotVMXConsolidateOnlineCB: Done with consolidate

In the vmkernel.log file, located on the ESXi at /var/log/vmkernel.log you see entries similar to:

vmkernel: gen 2141, mode 1, owner 4b94bb81-########-3bd1-########### mtime 244622]on volume 'LUN03'.
vmkernel: [YYYY-MM-DDTHH:MM:SS] cpu2:4109)FS3: 2890: [Requested mode: 1] Lock [type 10c00001 offset 7505920 v 920, hb offset 3510272
vmkernel: gen 2141, mode 1, owner 4b94bb81-########-3bd1-###########mtime 244622] is not free on volume 'LUN03'
vmkernel: [YYYY-MM-DDTHH:MM:SS] cpu2:4111)FS3: 2798: [Requested mode: 1] Checking liveness of lock holders [type 10c00001 offset 7313408 v 796, hb offset 3510272

In the hostd.log file, located on the ESXi at /var/log/hostd.log you see entries similar to these during the snapshot delete process:

DISKLIB-LIB : Failed to delete disk '/vmfs/volumes/4c5f4b7a-########-32ad-#########/TESTVM/TESTVM_1-000001.vmdk' or one of its components: Device or resource busy

When you attempt to consolidate by right-clicking the virtual machine and clicking Snapshot > Consolidate, you see errors similar to:

Consolidate virtual machine disk files <hostname> Unable to access file <unspecified filename> since it is locked
Consolidation failed for disk node 'scsi0:8': msg.fileio.lock.

Consolidating/Committing snapshots in VMware ESXi
"An error occurred while consolidating disks:" deleting one or more snapshots or consolidate disks