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).
The other day I stumbled upon a new VMware labs “Fling” called PowerActions. Basically it allows you to run in-context PowerShell/PowerCLI scripts right from within the vSphere Web Client. My mouth drooled at the promise of what this could deliver–and it really delivered! This is my new favorite tool by a landslide. See the announcement here from @alanrenoufhttp://www.virtu-al.net/2014/09/16/powercli-vsphere-web-clientannouncing-poweractions/. I’d recommend readin this first before you continue down with my post.
This will save you a lot of time in your own scripts. These leverage our REST API and will spare you the steps of creating your own REST calls in your script. Look for this toolkit to expand in the near future.
Previously I blogged about using PowerShell with the Pure Storage FlashArray to enable scripting of common tasks like provisioning or snapshotting. In that post I showed how to use SSH to run Purity operations, but with the introduction of the REST APIs (fully available in 3.4+) there is now a much better and cleaner way to script this. You no longer need to install extra SSH modules and the like, all you need is the Invoke-RestMethod in PowerShell.
Scripting is a wonderful thing–saves me tons of time. PowerShell is no exception. VMware offers a very robust PowerShell cmdlet offering (called PowerCLI) which allows you to do essentially anything you can think of in vSphere. Of course this is all specific to VMware or Windows. What about including scripting commands for Pure Storage into PowerShell (PowerCLI) scripts? It is actually pretty simple using the readily available SSH plugin for PowerShell.
This is a post I plan on just updating on a rolling basis. I have been working on updating the vSphere and Pure Storage Best Practices document and there are few settings that can be tweaked to increase performance. A common question I have and occasionally receive is can this be easily simplified or automated? Of course! And PowerCLI is the best option in most cases–I will continue to add to this post or update it as I find newer or better ways of doing things.
****UPDATED SCRIPTS AND NEW FUNCTIONALITY check out this blog post for insight****
In my previous post I wrote about expanding a ScaleIO volume in a VMware environment. During that procedure there is a requirement to correlate the EUI of the device hosting the VMFS to the ScaleIO identifier so that you can ensure that you actually expand the correct volume. Especially important in large environments. So I thought is there a way to script this correlation in a simple fashion to save you some work? Can the whole process be automated?
On November 18th, the 3.0.1 version of ESI was released and I wanted to write a quick post about what’s new. Even though numbering-wise this is referred to as a minor release, it is a very important one for those using (or want to use) the VMAX-related PowerShell cmdlets that are provided with ESI.
EMC offers a variety of tools to manage/enhance your virtual or physical environments–some free, some licensed. In most cases when you think of EMC tools for VMware one conjures up the free Virtual Storage Integrator which is more commonly referred to as VSI.
VSI is a great tool and continues to be improved through each version and allows you to provision storage, manage pathing, configure SRM etc. The one thing it does not have is a way to automate these tasks through an API or CLI. This is where another product comes in–one that many do not associate with VMware. The EMC Storage Integrator (ESI) is a lot of times seen as the Microsoft version of VSI–but that isn’t really true at all. While it might have started out that way and does indeed support Hyper-V and has a ton of Microsoft-specific features it is really the heterogeneous storage integrator. Importantly it has a very handy and powerful feature–PowerShell cmdlets.
