One of the tools I use quit often are the “vmkfstools” which provide some really handy functions. I want to share some of the available parameters with a quick description of a use case.
- Wipe (zero) an existing VMDK
vmkfstools –w /vmfs/volumes/<…>.vmdk
Why is this useful? Many storage systems are using thin provisioning and for most of them do blocks filled with zeroes represent free storage. So if you wipe a VMDK before you delete it, you can easily free up all the allocated blocks associated to that VMDK on the storage system.
Depending on if your storage system also support the VAAI(SCSI) unmap primitive, the array can instantly start to reclaim unused blocks. But keep in mind this adds additional load to your storage system.
- Reclaim storage on a VMFS datastore
vmkfstools –c XXXG -a buslogic -d eagerzeroedthick /vmfs/volumes/<datastore name>/<dummy name>.vmdk
In case you have already deleted some VMs or moved them around with storage vMotion, you may want to compare the storage usage on the VMFS layer compared to the amount on the thin provisioned LUN/vDisk. Then you can zero the remaining free space on the VMFS datastore with a dummy VMDK to free up some of the unused space. This will temporarily fill up your datastore, but you are going to delete the dummy VMDK once it has been created. More details …
But be careful, if you are too aggressive with the size of the VMDK you may run out of space if simultaneously someone creates a snapshot or a thin provisioned VMDK starts to allocate new blocks. This of course will also create additional load to your storage array.
- Determine the owner of a locked file
vmkfstools -D /vmfs/volumes/<…>.vmdk
You could run in a situation where you are unable to perform certain actions like to power on VMs, delete files on a datastore, etc. because a file like a VMDK is locked. More details …
“Unable to access a file since it is locked”
To find out which host holds the lock you can use vmfkstools –D to get the MAC address of the current “owner”:
Lock [type 10c00001 offset 52054016 v 438, hb offset 3190784
gen 74499, mode 0, owner 00000000-00000000-0000-000000000000 mtime 1379854
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 65, 49>, gen 68, links 1, type reg, flags 0, uid 0, gid 0, mode 600
len 494, nb 1 tbz 0, cow 0, newSinceEpoch 1, zla 2, bs 65536
Then you could restart the management agents on the host holding the lock. Sometimes it could be also a backup server or a proxy VM/appliance who still has the lock on the VMDK, which maybe needs to be rebooted.