I know that my efforts in this have me standing on the shoulders of giants, as my work is just another modification to those who posted both the original script, and the one that allowed for some datastores not being visible to all clusters/datacenters in a vCenter.
I will also preface this by saying that I was led here looking for a way to completely automate the vmfs unmap of all my datastores. Originally, I was looking to set it up as a series of scripts distributed across my ESXi 5.5 hosts, and run those scripts as cron jobs, but that effort was proving fruitless. I couldn't get the script to run properly, much less get the cron job set up. As a member of a two-member team responsible for the entire server/storage/network/VDI workload for a school district, we thrive on automation. If it can be automated, it should be. If it can be scripted to reduce the amount of time I have to spend on it in the future, it should be. Period.
I digress. I made it to here.
One of the situations I have going on in my environment that made the original version of this script not work for me was the lack of datastore visibility to all my hosts. We have two vCenters (one for VM servers, one for VDI), and our server vCenter has, at present, two different clusters, one for "normal" servers, and one for servers related to VoIP (the hosts in the VoIP cluster are MUCH less powerful). Additionally, all the ESXi hosts are Cisco UCS blades, all booting from iSCSI SAN storage. Having come from a military background, when we re-designed our entire storage policy for disaster recovery, I put in place restrictions on most of my datastores to only be visible to the vCenter clusters that needed to access them, and restrict the iSCSI boot datastores to only be visible to their respective hosts.
As a result, I took a look at the second version of the script that was posted that did the VMFS unmapping by connecting to all the clusters individually, and painstakingly (my PowerShell skills are weak so I had to look up most of the commands as I went) modified it to connect to ALL the hosts in ALL the clusters to do the unmapping. I realized this was going to create many redundant unmappings as many of my datastores are visible to more than one host, so I added a separate sub-process to keep track of the datastores it had already processed, and not process them again.
I ran this modified version, and found that it mostly worked, but, like many others, I hit the 30 minute timeout on the unmap process on one of my datastores, even running it with a block count of 800 against a 10TB VMFS5 datastore. Not liking the "SSH into the server from PowerShell" option that relies on keys, etc, as I try to do things as natively as possible, I tried to increase the block count again, this time to 2000, but I found that my boot datastores, the ones visible to only one host, had an unused block count of 1936, just enough under my limit to create problems. This led me to the realization that all this was scripted, and other parts of the unmap command were variablized (such as the datastore to run the unmap command against), so why not variablize the block count as well? If PowerCLI can find that there aren't enough free blocks to run the command, then there has to be a command set I could run to find how many free blocks there were, and set my block count for the unmap command as a function of that.
With this concept in mind, I started doing research on the impact of running the unmap command with a higher block count than the default of 200, and since it was always my goal to automate it running in the off-hours, but never to degrade performance significantly even if it were run during working hours, I settled on a block count that was 0.5% of the datastore freespace in MB (as the default block size for VMFS5 volumes is 1MB/block). I rounded this number as a function of Powershell, and injected it back in. The end result was that the script ran in about 25 minutes total, instead of the 1.5+ hours it ran at previously. And remember that 10TB datastore that failed to process with the block count at 800? It completed successfully in three minutes, and ran at a block count of 16172.
Having already read this thread, and knowing there were others running into the same issues, I now present you with my modifications to this script. I have included commented blocks to allow it to run without any user input AND connect to multiple vCenters so it can be run as a scheduled task from a Windows server. Be advised that as of the time of this posting, I have not yet run it as a scheduled task, but the theory is sound and the script runs.
Snow days are fun, aren't they? Without it, I'd have had real work to do today!
