Here is my storage manager for the FlashArray and VMware. Based on PowerCLI, but uses a front end GUI. Enjoy!
NOTICE THIS HAS BEEN DEPRECATED IN FAVOR OF THE POWERSHELL MODULE HERE:
https://www.codyhosterman.com/scripts-and-tools/pure-storage-powershell-vmware-module/
There are a variety of methods of managing VMware objects (VMFS volumes, VMs, VMDKs and RDMs) and the underlying snapshots to recovery or clone them. But often I get asked if I have a PowerShell (PowerCLI) script to do one or all of them. I have a bunch on my GitHub, but I decided a week or so ago to put something a bit more robust together. At first I was making it a standard interactive script, but it morphed into a GUI, using combo-boxes etc:
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.
I wrote a post recently on the updates made to the PowerCLI 6.3 R1 esxcli implementation, so the logical next step was to implement this new behavior into my PowerCLI scripts that use esxcli. I still have a few scripts to update, but my two best practice-related scripts are ready to go. The two scripts are:
Script to check and set best practices. Download here:
Script to just check best practices, and lists issues in a report. Download here.
While I was updating them for esxcli changes, I figured i might as well improve them too, so there are quite a few changes for both. Let’s take a look.
One of the changes in VMware vSphere PowerCLI 6.3 R1 was a much needed one: how the arguments are managed with esxcli commands. This was always a bit of a pain, especially for commands that have a lot of arguments. I won’t go into the detail on all of why/what of the changes here, as Alan Renouf already did that quite well here. So if you are unsure of the previous ugliness of esxcli in PowerCLI read that post before reading more here. Otherwise, continue on. I want to talk about some specific examples for storage-related commands that I use and many of our customers use quite commonly.
So in a blog series that I started a few weeks back (still working on finishing it), I wrote about managing snapshots and resignaturing of VMFS volumes. One of the posts was dedicated to why I would choose resignaturing over force mounting almost all of the time.
An obvious question after that post is, well when would I want to force mount? There is a situation where i think it is a decent option. A failover situation where the recovery site is the same site as the production site, in terms of compute/vCenter. The storage is what fails over to another array. This is a situation I see increasingly common as network pipes are getting bigger.
This is part 1 of this 7 part series. Questions around managing VMFS snapshots have been cropping up a lot lately and I realized I didn’t have a lot of specific Pure Storage and VMware resignaturing information out there. Especially around scripting all of this and the various options to do this. So I put a long series out here about how to do all of this. Let’s start with what an unresolved VMFS is and how to mount it.
I was recently asked how to query SRM for protected VMs and I decided it would make a good quick blog post. There is a great post here on using PowerCLI with SRM, but it doesn’t show the information to return per virtual machine information by default. Needs a bit more.
All it returns is a SRM-based virtual machine ID which doesn’t relate to what a user is probably looking for (a virtual machine name). So it needs a few more simple steps. The following script which can be found on my GitHub page here that does the following things:
Connects to a vCenter
Connects to SRM
Creates a log folder with a time stamp in the name
Iterates through each Protection Group
Logs every virtual machine in that protection group
I received a question recently on another UNMAP post what are the minimum permissions required to run UNMAP with PowerCLI and finally got around to looking into it. Turns out it is very straight forward. If you run it with a read-only account–it will fail. Since it is creating a file and making changes some configuration authority is required. Running as read only will look like this:
The first step prior to provisioning storage on the FlashArray is to actually create the host records on the array itself. These records, in their most basic form, are just names of hosts with associated WWNs or IQNs. Pretty simple process in general, but as these VMware clusters get larger and larger (vSphere 6.0 now allows 64 hosts per cluster) scripting this configuration becomes a bit more appealing. Granted, this is a one-off operation, but still saves you from a tedious task. So I wrote one. This script also integrates setting the best practices on the ESXi hosts in the cluster and in the case of iSCSI adds the FlashArray iSCSI ports as a target on the host software iSCSI adapters.
***********UPDATE PLEASE REFER TO THE POST AT THIS LINK FOR UPDATED INFORMATION ON THIS SCRIPT***********************
The most common request I get for scripts here at Pure Storage is an UNMAP script using PowerCLI. I have a basic one here that does the trick–UNMAPs Pure Storage volumes in a vCenter. That being said it is pretty dumb–doesn’t tell you much about what happened other than what volumes it is reclaiming (or not reclaiming) and moves on. A few requests have come in recently for something a little more in-depth. Most notably the ability to see how much space has been reclaimed. This information cannot be gathered from the VMware side of things–it has to come from the FlashArray.
There are two options here–either use our REST APIs or use our PowerShell toolkit to get this information (which just wraps the REST calls). For this script I chose to use the REST API directly from within PowerShell. What this script does is:
Connects to the vCenter and FlashArray
Finds all of the datastores and counts how many are actually Pure Storage volumes (NAA comparison)
Iterates through all of the datastores
Skips it if it is not Pure
If it is, the current data reduction ratio is reported and so the is current physical written capacity on the FlashArray.
Runs UNMAP on the datastore
Reports the new data reduction and physical space after UNMAP completes and how much was reclaimed.
Repeats for the rest of the volumes.
The script reports all of this to the console window, but it always throws it in a log file through add-content. If you don’t want it to return the info to the console, simply delete the write-host lines. If you don’t want it to log, delete the add-content lines.
There are a few required parameters–vCenter information (IP, username, password), FlashArray info (IP, username, password), UNMAP block count and a log file location. These are hard-coded parameters, but that can easily be changed by altering it to a read-host.
You may also note that after each UNMAP the script sleeps for 60 seconds–I do this so I make sure the FlashArray has time to update its information right after the UNMAP. 60 seconds is VERY conservative–probably 10 or so is fine, so feel free to mess with that number if you don’t like waiting. I also have another sleep at the end of each datastore operation to give a quick chance to review the latest results before it starts spewing the next datastore information on the screen (note this update didn’t make it into the video demo below–it doesn’t wait after each datastore).
See the script in action below. Essentially I am deleting a bunch of VMs across 4 datastores and then running the UNMAP. You can see the space get reclaimed on the FlashArray.
Note: You need particular access (see a blog post about that here) to vCenter to run UNMAP. For the FlashArray only Read Only is needed (higher of course is fine too).
