"Remember kids, the only difference between Science and screwing around is writing it down" -Alex Jason (made popular by Adam Savage)
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:
Continue reading “Required ESXi permissions for UNMAP through PowerCLI”
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.
Continue reading “PowerCLI Script to Create VMware Clusters on the FlashArray”
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:
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).
Get the script here:
https://github.com/codyhosterman/powercli/blob/master/unmapsdk.ps1
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 @alanrenouf http://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.
Continue reading “PowerActions–The PowerCLI Plugin for the vSphere Web Client with UNMAP”
Quick post here. So I have been reviewing some great posts from @vmKen and @BenMeadowcroft about automating Site Recovery Manager operations with PowerCLI and wanted to give it a try myself. They outlined the process rather clearly in their blogs so it was a breeze to get most of the stuff up and running. But when I went to actually execute a test recovery or a recovery etc. it kept failing! The PowerCLI command to start the recovery was $VMrp.Start($RPmode)–the $VMrp being my recovery plan and the $RPMode being the recovery plan mode of a recovery. The command was accepted but the recovery plan never started.
I got the following error in vCenter:
Unable to start the requested operation. Another operation may be in progress. Please wait for it to finish and try again.
Hmm…weird. I could kick off a test from the GUI with no issue so nothing was “interfering” from what I could tell. I thought maybe since I was using Site Recovery Manager 5.8 maybe something had changed so I tried it with my 5.5 environment and got the same result.
After I was about to lose my mind it finally occurred to me that I was connecting to the protected vCenter and the protected SRM server (I did enter in remote credentials for the recovery SRM server though). While I could query the recovery plan etc without issue from here, maybe SRM didn’t allow a recovery plan to be started unless you directly connected to the recovery vCenter/SRM server.
So I reconnected to the recovery site and it worked! So I guess it makes a difference, so FYI. Now there might be a workaround to this and it is definitely possible I missed something that allows this but this seems to be what you need to do. If you find this isn’t true please let me know!
Thanks Ken and Ben for getting me started!! Cool stuff. Kens posts:
http://blogs.vmware.com/vsphere/2014/05/automate-failover-with-srm.html
http://blogs.vmware.com/vsphere/2014/05/srm-powercli-reporting.html
http://blogs.vmware.com/vsphere/2014/05/powercli-and-the-srm-api.html
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.
Continue reading “PowerShell and Pure Storage REST API Scripting”
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****
Update: get my scripts on my GitHub page here:
https://github.com/codyhosterman/powercli
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?
The answer to both is yes!
Continue reading “Using PowerCLI to correlate VMware VMFS and ScaleIO volume info”
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.
Continue reading “Scripting ESI PowerShell cmdlets and VMware”