I have officially decided to “retire” my UNMAP script that uses direct REST calls to find before and after capacity changes for given volumes. I am only updating the one that uses the Pure Storage PowerShell SDK from this point on–using this is much more robust, not tied to direct API versions and greatly simplifies managing the data in the script.
I have also created a second version for use in the VMware Fling called PowerActions. This allows the script to be executed from the vSphere Web Client.
So what does this mean for current users of the script? Not anything really. Continue using it as you have, but I suggest upgrading to this new one at some point. If you made tweaks you will need to make them again though.
Besides it using the SDK (which is really and old change, I introduced this version a few months back) there are a few others changes:
- Fixed and issue with multiple arrays not working properly, there was a small bug pulling data out of an array value where the first FlashArray in the array value would return multiple serial numbers. This is fixed.
- Performance improvement. After a suggestion from a reader Nick Carter on this post to not use get-scsilun to find the NAA of the device. Get-scsilun has always been the bane of my existence because it is expensive (slow) and he suggested information from vCenter MoB which can be easily grabbed from a datastore object. Which is also much faster. I did that and the information sorting time is now much shorter. The bulk of the time will still be for the UNMAP operations, but at least that part is removed.
- Removed all write-host lines. I now just only log to the log file instead of the screen, this makes the script more readable (less lines). Most people were running it as a task anyways so the script log is more useful anyways.
- Added a check for volumes that are 75% full or more. This has to do with the rules described here. http://blog.purestorage.com/unmap-block-count-behavior-change-in-esxi-5-5-p3/. It now warns about this scenario and the fact that it might be slow.
- Better PowerCLI version control. In PowerCLI 6.0 and later PowerCLI is now a module not a snap-in, so the lines I included to include the snap-in would fail and spit out an error. This no longer happens. A slight variable change is needed if you want this check to occur.
- Some general script clean-ups. Cleaned up some of the log file formatting too.
So the pre-requisites for this script are as follows:
- This can be run directly from PowerCLI or from a standard PowerShell prompt. PowerCLI must be installed on the local host regardless.
- PowerShell 3.0 or later
- Pure Storage PowerShell SDK 1.0 or later
- PowerCLI 6.0 Release 1 or later (5.5/5.8 is likely fine, but not tested with this script version)
- Purity 4.0 and later
- FlashArray 400 Series and //m
- vCenter 5.5 and later
- Each FlashArray datastore must be present to at least one ESXi version 5.5 or later host or it will not be reclaimed
So check it out and download the latest on my GitHub page:
You can download the Pure Storage PowerShell SDK in the Pure Storage Open Connect GitHub PowerShellSDK Repository
The second part of this update is a version for PowerActions. I’ve posted on this before http://www.codyhosterman.com/2014/10/poweractions-the-powercli-plugin-for-the-vsphere-web-client-with-unmap/.
I have created a second version of this script that supports PowerActions as well. So if you want to kick off this script from the vSphere Web Client you can. From a functionality standpoint it is not much different, still runs UNMAP on FlashArray VMFS volumes and spits out a report of space reclaimed by grabbing it from the FlashArray using the Pure Storage PowerShell SDK. Though this of course means:
- You need to install PowerActions (get it here)
- On the PowerActions server you need to install the Pure Storage PowerShell SDK
- PowerActions is still a Tech Preview “fling” so it isn’t officially supported by VMware, so understand that.
One difference though is that it is started from the cluster object, not the entire vCenter like the original script does. Right click on the cluster you want to run UNMAP on and it will reclaim all FlashArray VMFS volumes in that cluster. The log file will be stored on the PowerActions server under the directory you choose. Remember you need to enter in the FlashArray information into the script (FQDN/IP and creds). If you don’t want to store them in the script you can store them in a secure file on the PowerActions host or something like that, though you will need to alter the script a bit.
The most recent version of PowerActions takes care of the limitations it used to have when it came to versioning, so setup is much easier with the 1.5 release.
To enter the script, choose new script in the PowerActions home and choose the cluster as the parameter. When you get to the text field to type the script, delete everything in it and just paste the whole script in.
Get the PowerActions version of the script here: