So, I was busy humming along, dividing some hosts between a production vCenter server and the new disaster recovery (DR) vCenter server that I had just installed. As part of this process, I had mounted DR datastore, moved the virtual machines that I needed to run in DR over to their new locations, and was now busy unmounting the production datastores. But, one of the NFS datastores was being stubborn. Why couldn’t I use the Delete button from within the Configuration tab | Datastore link? Why couldn’t I right-click this particular datastore and select the Unmount menu item?
The entire error message read, “An error occurred during host configuration. See the error stack for details on the cause of this problem. Call “HostDatastoreSystem.RemoveDatastore” for object “datastoreSystem-415”. An unknown error has occurred.”
What in the world did that error mean? At least it was consistent. Any of the hosts on which I attempted to remove this particular datastore produced the same error message. I went browsing the contents of the datastore, and found that it contains the Scratch Space for all the hosts! No wonder they refused to dismount it. Didn’t know you could setup Scratch Space on NFS? Goto this blog for the steps:
https://www.orionscache.com/2012/05/how-to-setup-vmware-scratch-space/
Obviously, the answer to my problem was to move the scratch space location of the hosts designated for DR, and then unmount the datastore that I no longer wanted attached. That brings me to another point: it is best practice not to have remote datastores mounted. Think what a network bottleneck I would have created if I had not attempted to dismount this production datastore? My next step was going to be to physically move these hosts, and if they were still reached out across the WAN for their scratch space it would have been a network bottleneck.