I had noticed that a customer had been building ESXi hosts but the local datastore on the host was being created as vmfs5 instead of vmfs6.
No problem – just delete the local datastore, assuming no VMs have been built on it, and recreate as vmfs6 right? not so simple. Attempting to delete the datastore threw up this error:
Cannot remove datastore ‘Datastore Name: because file system is busy. Correct the problem and retry the operation.
So whilst this occured due to local datastore being created on the older vmfs version, it could apply to any datastore you need to delete. Here we needed to try and find out what could be writing to the datastore that would affect the ability to delete it. Some things to check:
There is likely a dumpfile set up on the host. Run the following command to check
# esxcli system coredump file list
If it lists there is a dumpfile configured on the local disk, run this command to turn it off:
# esxcli system coredump file remove --force
If the datastore being deleted is a shared datastore, run the following command to find the owner of the file:
# vmkfstools -D /vmfs/volumes/Datastore/vmkdump/684938663845.dumpfilevmkfstools -D /vmfs/volumes/Datastore/vmkdump/123456789101.dumpfile
The output will look like:
Lock [type 10c00001 offset 200392704 v 10, hb offset 3875328 gen 3, mode 1, owner 52ebd042-43b191f0-0173-012345678910 mtime 250
The last part of that id relates to the mac address of vnic0 of the owning host, e.g 01:23:45:67:89:10
Run the above vmkfstools command to delete.
Once you have deleted the datastore, run the following command to reenable the dump file elsewhere
esxcli system coredump file add -d datastore_name
Browse ESXi > Configure > System > Advanced System Settings and find setting ScratchConfig.CurrentScratchLocation (). If the ESxi host is used as Scratch Location, edit to something like /tmp and reboot the host.
You can then delete the problematic datastore. Remember to go back and change the scratch location to the new datastore.