I’ve noticed I am beginning to have some blog post sprawl as I update my UNMAP script over and over so I will be using this post from now on to record future updates. Please use this post as the final word on what is new with my UNMAP Script.
This script runs UNMAP on all FlashArray datastores in your vCenter environment to reclaim dead space. All operations are logged to a file in a directory of your choosing. This script requires that a datastore be accessible by at least one ESXi version 5.5 host or later to run UNMAP. Please refer below for detailed changes and requirements for specific versions. The newest version description will be directly below. The script can be found here:
Note there is an unattended version of this script too, if you want to run it as a scheduled task. Find it here:
For required vCenter permissions please see this post:
Script Version 5.0 January 27th, 2017
This latest version has a few major changes:
- Support for VMFS-6. VMFS-6 by default enables automatic background UNMAP and therefore does not require manual UNMAP to be run. My script now identifies VMFS-6 volumes and checks to see if automatic UNMAP is turned on. Any VMFS-6 that has it turned on it will skip
- No longer ever need to go into the script and hard-code variables. They are now asked interactively when you run the script. This includes:
- Log file directory
- FlashArray connection information
- vCenter connection information
- Whether to send results to Log Insight
- Improved logging in general.
- Changed how space reclamation results are reported. It now uses the method described in the post here. Far more accurate and useful than before. Also it reports at the end, not for each datastore logging section to make it easier to read. Furthermore, it gives the array more time to make sure the space reporting is accurate. Usually takes a few seconds and doing it immediately after the UNMAP is not always accurate. It is reported on the array level and the datastore level in a table at the end of the log and also on-screen.
- Returns more information to the screen. Which datastore it is running UNMAP on and the final total space reclaimed (both virtual and physical) for all entered arrays in GB.
- Checks and imports both the PowerCLI modules and the FlashArray PowerShell SDK. They must both be installed.
- Improved error handling
Another note on space reporting. I report three numbers for a given volume:
- Expected minimum virtual space to be reclaimed. This is by taking the difference between the VMFS allocation and what the array sees as written overall (virtual space)
- Actual reclaimed virtual space. This is the difference between virtual space for a volume before UNMAP as compared to after. If the actual is much higher than the expected, this is due to the presence of thick provisioned virtual disks. This makes the expected lower than it should be.
- Actual physical space reclaimed. This is how much unique space actually written down to SSD was reclaimed.
Note, if you want a report about how much will be reclaimed without actually running it, you can run this script:
Integration with Log Insight
See a more in-depth post about how I send to Log Insight here:
The UNMAP script also optionally supports sending per-datastore UNMAP results to Log Insight.
If you do not use Log Insight, or don’t want to send results to it, then enter n and move on.
If you do, enter y, the Log Insight server and a UUID to use to identify the messages.
If this is enabled, the script will send a REST call with the PowerShell InvokeRest-Method command to Log Insight. You enable this feature by simply changing the $loginsightserver from $null to your server. The REST call sends the following information:
- VMFS volume that UNMAP ran on
- Network Address Authority (NAA) of the underlying device
- The FlashArray volume name
- The FlashArray
- The ESXi server that ran the UNMAP process
- The virtual space reclaimed in GB
The Log Insight message will look like below (with the corresponding fields as I named them in the REST call):
Hopefully will be a decent way to keep track over time how much space has been reclaimed by UNMAP procedures. Now I can run queries and show how much has been reclaimed overall: