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:
https://github.com/codyhosterman/powercli/blob/master/unmapsdk.ps1
You can download the Pure Storage PowerShell SDK in the Pure Storage Open Connect GitHub PowerShellSDK Repository
PowerActions
The second part of this update is a version for PowerActions. I’ve posted on this before https://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:
https://github.com/codyhosterman/powercli/blob/master/unmapsdkPowerActions.ps1
Thank you for the quick turnaround on getting out the PowerActions version of the UNMAP script. Very much appreciated!
Sure thing! Let me know how it works out for you
Thanks. great work so far. just one error i get on one datastore:
Der Wert “1.424,340” kann nicht in den Typ “System.Int32” konvertiert werden.
Fehler: “Die Eingabezeichenfolge hat das falsche Format.”
In C:\Users\Eddi\Desktop\UnmapPure.ps1:184 Zeichen:13
+ $unmapsavings = ($volphysicalcapacity – $volphysicalcapacitynew)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvalidCastFromStringToInteger
I try to translate:
The value “1.424,340” cant be converted into “System.Int32”.
Error: “The entered number sequenze has the wrong format.”
In C:\xxxx\UnmapPure.ps1:184 Row:13
+ $unmapsavings = ($volphysicalcapacity – $volphysicalcapacitynew)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvalidCastFromStringToInteger
Hmm. I’ve seen issues with number formatting before with other scripts because of the comma/period usage differences but it is strange that it would only happen on this one datastore. Would you be able to run this manually on just that one datastore and print out the value of those variables?
I just run this script again and now im getting many error like this:
Fehler beim Indexvorgang. Der Arrayindex wurde als NULL ausgewertet.
In C:\Users\Eddi\Desktop\UnmapPure.ps1:157 Zeichen:13
+ $volinfo = Get-PfaVolumeSpaceMetrics -Array
$EndPoint[$arraychoice] …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : NullArrayIndex
Fehler beim Indexvorgang. Der Arrayindex wurde als NULL ausgewertet.
In C:\Users\Eddi\Desktop\UnmapPure.ps1:181 Zeichen:13
+ $volinfo = Get-PfaVolumeSpaceMetrics -Array
$EndPoint[$arraychoice] …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : NullArrayIndex
Of course I will run it manually.
This sounds like it didn’t authenticate properly at all. The $endpoint array wasn’t populated
But I didn’t Change anything in the script. really strange.
Shoot me an email. cody AT pure storage DOT com We will figure this out
Hi, thanks for this! However, I’m getting a weird error: Only administrators can change settings for all users.
Cannot validate argument on parameter ‘Server’. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.
The log file also shows the following:
The volume is 75% or more full so the block count is overridden to 200 MB. This will slow down the reclaim dramatically
It is recommended to either free up space on the volume or increase the capacity so it is less than 75% full
The block count in MB will be 200
It never asked me for block count to begin with.
Sure thing!
The script calculates the best block count based on the free size. Volumes that are 75% full or more will always use the default count of 200 due to VMware rules https://www.codyhosterman.com/2015/07/unmap-block-count-behavior-change-in-esxi-5-5-p3/
There are some environmental variables that it sets in the start, it is probably failing to set them or just warning that it cannot set it for everyone.
Are you running it as administrator?
The server error has to be for the vCenter connection, it is the only line that takes in a Server parameter. It seems to be connecting to vCenter though right? the $vcenter variable is correctly filled out?
Cody,
I appreciate that you share the script. So can I run the script as regular scheduled task once every month ?
Would there be any risk when running it during:
After hourse where all the backup running
Working hours where all production workload is happening
Thanks,
Al
You’re welcome! Yeah I have a ton of customers who run this as a scheduled task. We don’t really have any recommendations around when to run it, it is a pretty low priority process so it doesn’t really cause a problem. I would recommend making sure you are at least ESXi Patch 3 or later, as there are some important UNMAP fixes in it. Some very risk averse customers actually run it from ESXi hosts that are only in maintenance mode. That’s generally pretty rare though
I feel dense asking this question… what is the format for passing parameters to the script when running as a scheduled task?
Not dense–it is a good question. I probably should put a post together about doing it. You need to reconfigure the inputs of the script to do that essentially. This method from my coworker for the credentials is a good one
http://www.purepowershellguy.com/?p=8431