Symptoms:
Batching large numbers of virtual machine (VM) or virtual machine disk (VMDK) creation, cloning, and/or deletion on shared datastores may fail when multiple hosts are operating simultaneously.
Multiple hosts performing VM/VMDK operations on the same shared datastore and accessing file-level locks (type 10c00001) may see this error:
Failed to create virtual disk: Device or resource busy.
Failed to lock the file.
Entries similar to these in the /var/run/log/vmkernel.log file include:
DLX: 3771: vol 'datastore-name', lock at 4325376: [Req mode 1] Checking liveness:[type 10c00001 offset 4325376 v 26266, hb offset 3219456gen 21, mode 1, owner 57579305-35931dbf-05d5000c29923ba3 mtime 62431num 0 gblnum 0 gblgen 0 gblbrk 0].
DLX: 4417: vol 'datastore-name', lock at 4325376: [Req mode: 1] Not free:[type 10c00001 offset 4325376 v 26272, hb offset 3219456gen 21, mode 1, owner 57579305-35931dbf-05d5-000c29923ba3 mtime 62463num 0 gblnum 0 gblgen 0 gblbrk 0].
When virtual machine (VM) and virtual machine directory (VMDK) operations are performed on an ESXi host such as creation, cloning, and deletion, it can lead to contention among multiple hosts accessing shared datastore resources. This can result in delays for other hosts seeking access to the same resource.
The potential for contention may trigger ESXi to issue lock liveness checks of type 10c00001 if the locks are not released when no longer needed. If this occurs, it could potentially prevent the system from responding to certain requests as expected.
vmid = vim-cmd /vmsvc/createdummyvm vm1 /vmfs/volumes/datastore
vmkfstools -d eagerzerodthick -c 1g /vmfs/volumes/datastore/vm1/vm1_data.vmdk
echo /dev/null > /vmfs/volumes/datastore/vm1/vm1_data-flat.vmdk
vim-cmd /vmsvc/destroy vmid