XtremIO PowerShell module -- Report on your all-flash arrays!

All-flash arrays -- if you do not have any, get some.  If you have XtremIO, you are likely ecstatic with the performance, ease of setup, low maintenance, etc.  You are potentially also fairly sad about the Java-based management GUI for when you want to report, especially when you want to report in bulk (say, across ten XtremIO arrays), as it is a separate interface to launch for each array.

How to turn that frown upside-down?  Hello, RESTful API!  After a bit of exploring the API, I have created a module for reading info from the XMS (XtremIO Management Server) appliances (the appliances that are used to manage the XtremIO arrays).  While the APIs provide support for nearly all management activities (create/delete/modify/read config), this module is starting out with just the configuration/stats-reading types of actions.

The XtremIO RESTful API provides item types upon which to report, like volumes, lun-maps, clusters, and initiators.  Newer releases of the XMS appliances add item types of bricks, snapshots, ssds, storage-controllers, and xenvs.  At the end of this post, after the examples, is more info on the differences between the appliance versions and how those difference affect the way one uses this module.

As for the module itself, it is linked below, it is still being improved upon, and the intentions are to [eventually]:

0. house it on GitHub or the likes
1. add the rest of the supported item types
2. add functionality beyond read-only reporting (think config/manage)
3. finish error handling for some scenarios (invalid item types for given API version, for example)

To use the module, just

0. download from https://github.com/mtboren/XtremIO.Utils/releases/download/Latest/XtremIO.Utils.zip
1. unzip somewhere you like (like, say, in Join-Path ${env:\userprofile} "Documents\WindowsPowerShell\Modules")
2. you should now have a folder named <pathToModules>\XtremIOInfo, in which the PowerShell files reside (see note below about using Unblock-File, since this module is not yet Authenticode signed)
3. Import-Module <pathToModules>\XtremIOInfo

You can use Get-Command -Module XtremIOInfo and Get-Help to find out all about the functionality provided by the module and its currently one (1) exported function, including examples.  You will also find the ItemType values currently supported by the module (more to come).

And, some quick examples to whet appetites:

PS vN:\> Get-XIOItemInfo -Computer somexms01.dom.com, somexms02.dom.com, somexms03.dom.com -Credential $credMyAcct -ItemType clusters

Name    TotSSDTB   UsedSSDTB   FreeSSDTB   UsedLogicalTB   TotProvTB   DedupeRatio   IOPS
----    --------   ---------   ---------   -------------   ---------   -----------   ----
xio01   7.47       4.03        3.44        12.17           50          3.0           7886
xio02   7.47       1.13        6.34        3.17            50          2.8           2821
xio03   7.47       5.23        2.24        17.79           50          3.4           28363


PS vN:\> Get-XIOItemInfo -Computer somexms04.dom.com -Credential $credMyAcct -TrustAllCert -Port 443 | Format-List

Name               : xio04
TotSSDTB           : 7.47
UsedSSDTB          : 2.43
FreeSSDTB          : 5.04
FreespaceLevel     : healthy
UsedLogicalTB      : 8.02
TotProvTB          : 50
OverallEfficiency  : 21:1
DedupeRatio        : 3.3
ThinProvSavingsPct : 76
IOPS               : 18160
SWVersion          : 2.2.3-25
SystemSN           : APM00000000004
ComputerName       : somexms04.dom.com

Various notes:
While the module has the ability to connect to different versions of the XMS appliances (v2.2.2 listens on a different port for API requests than does v2.2.3+), not all items are available on the older versions.  For example, one can retrieve info on the item type ssds only from from the newer version of the appliances.

When connecting to an appliance of the newer version, one might save a bit of time by specifying the port on which to communicate -- port 443.  The function tries the default port of the old appliances first (42503), and, if that port is not found to be responsive, tries the default port of the new appliances.  Also, if you did not put "legitimate" SSL certificate on the appliance (as opposed to the self-signed cert that is on it by default), _and_ you are sure that the address to which you are connecting in the appliance, you can use the -TrustAllCert switch parameter.  This is to allow the PowerShell session to establish the SSL connection by not stopping at a "self-signed cert found" error.

One of the other "features" of this module:  we have not yet set the authenticode  signature for it.  That is, it is unsigned.  We went back and forth on the solution:

• buy a legit cert for code signing (best solution, but $$$)
• sign it with a self-signed cert (which still leads to a prompt of 'Do you want to run software from this untrusted publisher?' when you try in import the module, since everyone is security-minded and has at least the RemoteSigned execution policy set on their machines)
• ✔ do not add a signature, and make mention that you will need to Unblock-File the files in the module (after careful inspection of the files to make sure that there is nothing dangerous in there; but, we're talking about vNugglets, here -- you can trust us, right?!  a:  No.  Trust no one)

So, since we went with the last option there, below is the quick/easy way to unblock files.  But, again, this should only be done when you trust the code in the files that you are unblocking -- inspecting the files is for your own good.  Anyway, the unblock command:
Get-ChildItem <pathToModules>\XtremIOInfo | Unblock-File

Alright, enough with the notes, for now.  XtremIO storage arrays: awesome.  Now, the ability to start interacting with management appliances via PowerShell: excellanté!