Pure1 PowerShell Module, Alerts, Support Contracts, Easier authentication, Custom REST tutorial.

Just pushed out a new release of the Pure Storage Pure1 PowerShell module. Not nearly as significant of a release as, but still a couple of notable things.

As usual update with update-module PureStorage.Pure1:

The first update is simplified authentication. The first time you authenticate, you need to run New-PureOneCertificate–on Windows this will create a self-signed x509 certificate, and if run on Linux or Mac it will create an RSA key pair. By default it will store it in the user directory first logged into when running PowerShell core:

Continue reading “Pure1 PowerShell Module, Alerts, Support Contracts, Easier authentication, Custom REST tutorial.”

Setting the Windows Terminal Tab to vCenter Name with PowerShell

Quick one. Today, I was working on some PowerShell using one of my favorite new Windows tools, Windows Terminal.

I’ve written about it a bit in the recent past:


I often will connect to multiple vCenters, but even more frequently will have multiple vCenters connected but in separate sessions or tabs:

Four tabs, four vCenters. And I never clicked on the one I meant to be cause they were all called PowerShell. In a fairly recent release, Windows terminal added the option to rename the tabs:

Continue reading “Setting the Windows Terminal Tab to vCenter Name with PowerShell”

PowerShell Authentication with FlashArray REST 2.x

Purity 6.0 ships with a new REST version 2.2. 2.2 includes the endpoints to manage ActiveDR processes (demote/promote), tagging (more on that in a later post) and more.

REST 2.x is a new major release of our REST API that changes the underlying structure of the API, the endpoints, authentication, queries, etc. Our current PowerShell SDK uses REST 1.x (which is changing) but for folks who might want to write their own PowerShell against REST, or starting using it now–here is some help.

Continue reading “PowerShell Authentication with FlashArray REST 2.x”

Default FlashArray Connection With PowerShell

In the VMware Pure PowerShell module (PureStorage.FlashArray.VMware) there is a default array connection stored in a global variable called $Global:DefaultFlashArray and all connected FlashArrays in $Global:AllFlashArrays. The VMware/Pure PowerShell module automatically uses what is in the “default” variable.

The underlying “core” Pure Storage PowerShell module (PureStoragePowerShellSDK) does not yet take advantage of global connections. So for each cmdlet you run, you must pass in the “array” parameter. For example to get all of the volumes from an array:

Kind of annoying if you are interactively running commands and only have one array connection you care about (or one that you primarily care about).

Continue reading “Default FlashArray Connection With PowerShell”

Pure1 REST API Authentication Made Easy

I’ve been working with the Pure1 REST for about a year now and have really enjoyed what it brings. I’ve integrated it into a few things: PowerShell. vRO. vSphere Plugin. One of the “tricky” things about it though is the authentication. Instead of a username and password it requires the use of a RSA256 public/private key pair. This is inherently more secure, but of course requires a bit more know-how when it comes to pair generation.

I simplified a fair amount of it in PowerShell, but didn’t quite get to the finish line. The generation of the key pair could be done but it came in the form of a PFX–which basically combines the public key and private key into one file. Unfortunately, Pure1 requires the them to be separated as all it needs is the public key, not your private key. While this is “better” it does leave Windows users at a bit of a disadvantage–there is no built in mechanism to generate this without installing OpenSSL directly. The process could not be done entirely in PowerShell. Or so I thought…

Continue reading “Pure1 REST API Authentication Made Easy”

Generating the default VVol Storage Container ID

A VVol datastore, is not a file system, so it is not a traditional datastore. It is just a capacity quota. So when you “mount” a VVol datastore, you aren’t really performing a traditional mounting operation as there is no underlying physical storage to address during the mount. So instead of mounting some storage device, you are mounting what is called a storage container. This is the meta data object that represents the certain amount of capacity that can be provisioned from a given array. An array can have more than one storage containers, for reasons of multi-tenancy or whatever.

In a VMFS world, when you go to create a new datastore, you pass it the serial number of the storage you want to format with VMFS. You know that serial, because, well, you created the storage device. When you “mount” a VVol datastore, instead of a device serial, you supply the storage container UUID. It comes in the form of vvol:e0ad83893ead3681-b1b7f56a45ff64f1. Of course the characters will vary a bit.

Continue reading “Generating the default VVol Storage Container ID”

Mounting a VVol Datastore with PowerCLI

I’ve been making a lot of updates to my PowerShell module around VVols recently and this was the last “table stakes” cmdlet I wanted to add. There are certainly more to come, but now we definitely have the basics. In release of the PowerShell module I added a cmdlet called Mount-PfaVvolDatastore.

As of today we support a single VVol datastore–though we are working on adding support for more than one.

Continue reading “Mounting a VVol Datastore with PowerCLI”

Registering VASA with PowerShell

Registering VASA providers is the first step in setting up VVols for a given vCenter, so automating this process is something that might be of interest to folks. We currently have this process in our vSphere Plugin, as well as in our vRO plugin, and of course you can do it manually. What about PowerShell? Well we have that too!

In our PowerShell Pure/VMware module there are three new cmdlets:

  • new-pfavasaprovider
  • get-pfavasaprovider
  • remove-pfavasaprovider
Continue reading “Registering VASA with PowerShell”

Assigning Read Access to Windows Private Key

I have written about authenticating with the Pure1 REST API, and my PowerShell module in the past:


NOTE: This workaround is not really needed anymore with the default behavior of the module. See this post: https://www.codyhosterman.com/2019/12/pure1-rest-api-authentication-made-easy/

One of the issues is that if you followed my default instructions, you would need to run the PowerShell window as an admin to be able to create the connection. The answer–now that I think about it is fairly obvious: non-admin users (or admins not running in admin mode) don’t have security rights to it. Duh!

Continue reading “Assigning Read Access to Windows Private Key”

Revamped PowerShell Module for Pure and VMware

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:

Continue reading “Revamped PowerShell Module for Pure and VMware”