About 6 months ago, my esteemed colleague Barkz blogged about our path forward with PowerShell. We have an official PowerShell SDK for managing the FlashArray–but it is limited to that: doing stuff to the FlashArray.
So to add value and make managing it within context of the layers you actually manage your infrastructure from (VMware, Microsoft, etc.) we created some value-add PowerShell modules to make it easier. Barkz talks about them here:
To make it easier to use even these we are building one “Solutions” module that works on top of our PowerShell SDK. The first step is making the underlying modules consistent and aligned to best practices of PowerShell.
My main module, my PowerCLI-based one, that integrates FlashArray cmdlets and VMware PowerCLI ones to manage the array from a VMware perspective (e.g. create a VMFS datastore, not just a volume in one step).
I have made a few changes preparing for this module to be merged into the “one to rule them all”:
- Updated cmdlet naming to conform to best practices (removing plurals and changed cmdlet naming to use pfa instead of fa, to be similar to our SDK. I have used aliasing though to make sure it doesnt break old scripts you might have written.
- Improved pipeline support so you can pass in multiple objects so that the cmdlet will automatically iterate over all objects passed in. I will show an example of what I mean
- Simplified connection management to the FlashArray–this makes it much more similar to what you do with vCenter–you dont need to pass in a vCenter connection everytime you run a PowerCLI command–same here. You don’t need to pass in a FlashArray connection for my cmdlets.
- Renamed the module to remove my name from it. Instead of Cody.PureStorage.FlashArray.VMware, it is not PureStorage.FlashArray.VMware.
- Various bug fixes as well of course.
- Split it into multiple modules to make it easier to track and manage versioning–though they can all be easily installed together.
Installation
So installation doesn’t much change–the preferred method is via the PowerShell Gallery-though it is hosted on GitHub too.
https://www.powershellgallery.com/packages/PureStorage.FlashArray.VMware
https://github.com/PureStorage-OpenConnect/PureStorage.FlashArray.VMware
If you have the old module installed, I would remove it first:
uninstall-module Cody.PureStorage.FlashArray.VMware
The next step is to install the new one!
install-module PureStorage.FlashArray.VMware
This process will load four modules automatically:
- PureStorage.FlashArray.VMware.Configuration
- PureStorage.FlashArray.VMware.VMFS
- PureStorage.FlashArray.VMware.RDM
- PureStorage.FlashArray.VMware.VVol
If you do not have the official Pure Storage PowerShell module installed it will also do that too. This will allow for better version tracking of cmdlets and simpler to make updates individually as needed. The underlying modules can be installed individually, but for the most part just install the whole thing.
Connection Management
This is probably the biggest change in this new version of the module. In the past, in order to run a cmdlet against a FlashArray, you had to run the cmdlet new-pfaarray and store the response in some object and then pass it in subsequent cmdlets:
$fa = new-pfaarray -endpoint myFlasharray.purestorage.com -credentials $creds
$volumes = get-pfavolumes -array $fa
This is okay I guess, but what if you have more than one FlashArray? Deciding what array to pass in takes more effort. If you want to find out where some object exists and you dont know, you have to loop through cmdlets until you get a match. One of the reasons that PowerCLI is nice is that you do not need this complexity. I connect to vCenter and then run get-vm with no parameters. This is how my module works now.
I have written a new cmdlet, called new-pfaconnection. This does a couple of things. This replaces new-pfaarray (well abstracts it).
You run it:
new-pfaConnection -endpoint flasharray-m20-1 -credentials $creds -defaultArray
You can either specify the array to be a default array (-defaultArray) or a non-default array (-nondefaultArray). You do not have to specify a default array–they can all be non-default if you want. If you specify a default array, cmdlets that “create” something like a new VMFS, it will use the default array if there is one. If you make a connection default, it will be stored in a global variable called: $Global:DefaultFlashArray
Whether or not you make it default or non-default, they will all go into a global variable called $Global:AllFlashArrays. Cmdlets that need to locate an object, (like what FlashArray is this datastore on) will automatically loop through the connections in the AllFlashArrays variable and return the correct one. So you no longer have to know or guess which one.
You can run new-pfaconnection to all of your FlashArrays and they will all be added to that global variable.
There is one more global variable called $Global:CurrentFlashArray. What the last FlashArray that was used will be stored in there. So if you run get-pfaVolfromVMFS (which returns the FlashArray volume hosting a VMFS) it will find the correct FlashArray that hosts that datastore and return the volume information, but also set $Global:CurrentFlashArray to the correct connection.
New Cmdlets
New-pfaconnection is a new one of course. But I’ve added a few more.
get-pfaConnectionOfDatastore: You pass in a Pure VVol datastore or a Pure VMFS and it will return the FlashArray connection of the FA that hosts that datastore. It will iterate through the global connections, or connections that you passed in directly if you so choose.
Get-pfaDatastore: Run this against a vCenter, a cluster or a host. This will return all of the Pure datastores presented to that host. You can also limit it to a specific FlashArray, by specifying a connection, or to VVol datastores, or to VMFS datastores.
Some examples:
Pipeline Support
I have had some pipeline support, but it wasnt perfect. In PowerCLI, you could pipe a bunch of VMs to get-datastore and it would return all of the datastores for all of those VMs.
Now, if you run new-pfavolVMFS (creating a new VMFS on a new FlashArray volume), you can pass in more than one FlashArray and it will create a new VMFS on each passed in FlashArray.
$Global:AllFlashArrays | new-pfaVolVmfs -cluster $cluster -volName newVMFS -sizeInTB 16
The above will create a new 16 TB VMFS on each FlashArray in my global FlashArray variable.
Next Steps
Well enhancements, new cmdlets etc. of course. But I will be working with my coworkers to merge this into other modules. So there will eventually be a module called like PureStorage.FlashArray that includes this and many others. I will be working next to include my Pure1 module into this model to and creating cmdlets that use both.
I have done my best to make sure that this is backwards compatible with my old module, but if you have production scripts, make sure to test it with this update to make sure nothing breaks. If it does, please let me know! Add a issue to the Github page for it, or join our Pure Code() and bring it up in our PowerCLI or PowerShell channel.
How should we write the such command?
update-faVvolVmVolumeGroup -purevip x.xx.x -faCreds $faCreds -datastore $datastore
its don`t work “-purevip”
Follow the process here:
https://www.codyhosterman.com/2018/12/updating-a-volume-group-name-on-the-flasharray-for-vvols/. You dont need to pass in the credentials or VIP anymore–it uses the default FA connections now