Everpure PowerShell SDK 2.52.323 released! New Cmdlets, Parameters, & More!
If your FlashArray automation has reached the point where every new Purity feature means another wrapper function, another chunk of parameter-validation code, and another comment that says “temporary workaround,” this release is for you. Everpure PowerShell SDK 2.52.323 is the latest GA release of the SDK for FlashArray. 64 new cmdlets and 47 existing cmdlets with new parameters. The more useful way to think about it is this: a whole lot of storage operations that used to sit just outside your PowerShell toolbox are now much closer to first-class automation. And yes, there’s an important footnote before we get too excited - we’re still a bit behind on the API parity with Purity. We’re still working on that.Stay tuned!. Wrappers, Drift, Chaos... Oh My PowerShell is great right up until the API surface you need isn’t represented by a cmdlet yet. Then the usual routine begins: A little REST, a little PowerShell. Authentication, URI construction, JSON bodies, response parsing, and error handling all end up in the same script. A little inventory archaeology. Someone has to remember which array has which policy, which workload belongs to which directory, and whether that “new” script still matches the current API. A little parameter drift. The array supports a capability, but your automation doesn’t expose it because the wrapper was written six months ago. A little naming chaos. Not enough to make the script fail, naturally. Just enough to make the next person stare at it for twenty minutes. The old way works. It’s just not especially fun to maintain, and “works” is doing a lot of heavy lifting there. So what exactly is new in 2.52.323? This release updates the SDK’s cmdlet coverage for Purity REST API versions 2.0 through 2.52. It adds new entry points across object storage, policies, quality of service, protection, identity, realms, workload placement, and more. Here are the areas that stood out to me in the release notes. Object Store gets a much bigger PowerShell surface There are new cmdlets for working with: Buckets and bucket performance/space information Lifecycle rules Object Store access keys, accounts, users, and user policies Object Store virtual hosts Object Store access policy members and rules That includes the basic create, update, remove, and get operations you’d expect in an automation workflow. In other words, Object Store administration is less likely to require a detour into raw REST calls just because the script needs to create a bucket or rotate an access key. Network access policies become scriptable The release adds cmdlets for network access policy objects, members, and rules, along with operations for creating, updating, removing, and inspecting them. There are also new array parameters for associating network access policies by ID, name, or resource type. That’s the kind of small-looking addition that becomes important when you’re trying to make a script reusable across arrays instead of hard-coding one environment’s identifiers into it. QoS coverage expands across the stack New cmdlets expose QoS information for hosts, host groups, volumes, volume groups, and realms. Existing host and host-group creation and update cmdlets also gain bandwidth and IOPS limit parameters. That gives you a more consistent way to describe performance intent in automation. Instead of treating QoS as a manual cleanup step after provisioning, your script can include the limits as part of the object lifecycle. Workload-aware directory and file-system operations A large part of the parameter expansion is about workloads. Directory and file-system cmdlets gain workload IDs, workload names, workload configuration, policy associations, default protection options, and related controls. There are also new workload-oriented parameters for NFS, SMB, snapshot, and quota policies. This is useful if your automation thinks in terms of applications and workloads rather than treating every volume, directory, or file system as an isolated object. Presets and placement recommendations expose more detail New-Pfa2PresetWorkload and Set-Pfa2PresetWorkload gain a substantial set of parameters for naming patterns, directory configurations, export configurations, quota and snapshot behavior, periodic replication, QoS, and placement. The placement recommendation cmdlet also gains parameters for richer result data, including target IDs and names, resource types, capacity, model, placement configuration, replication configuration, warnings, and capacity/load projections. This matters because a placement recommendation is more useful when automation can inspect why a target was selected, what its projected state looks like, and what warnings came back — not just whether a recommendation existed. Tags show up in snapshot workflows The new tag-related parameters on volume snapshot and remote protection group snapshot operations include tag namespace, key, value, copyability, and tag context/resource references. That’s a nice fit for scripts that use tags to carry ownership, application, environment, or operational metadata through protection workflows. More coverage around realms, SSO, offload, and remote resources The release also adds or expands cmdlets around: Realm connections and connection keys Remote realms and remote realm tags Remote pods SSO/SAML configuration Azure offload identity and placement settings Active Directory service testing Array cache inspection Support system manifests This is a broad release, not a single-feature release wearing a new version number. The common thread is that more of the things admins already manage in Purity are now represented in the SDK. 47 new parameters is arguably the more interesting part New cmdlets are easy to spot. New parameters are where existing automation gets more capable without needing a complete rewrite. A few examples from the release notes: ContextName and AllowError are added to several commands, including DNS, network interface, realm, and connection-path operations. QosBandwidthLimit and QosIopsLimit are added to host and host-group creation and update operations. WorkloadIds and WorkloadNames are added to directory, file-system, and policy query paths. Azure client, tenant, secret, and placement settings are added to offload creation. Snapshot operations gain tag-related parameters. SSO/SAML operations gain parameters for trusting other SAML service providers in a fleet and setting the service-provider entity ID. Preset workload operations gain a large set of nested configuration parameters, including naming patterns, export settings, quota rules, snapshot rules, replication rules, and placement configuration. The release notes contain the complete cmdlet-by-cmdlet list. I’d use that list as the migration checklist for existing scripts search for the wrapper functions you wrote around these areas, then see whether the SDK now gives you a direct path. There is a HTML Help file available in the GitHub repository. Check it out for an easy reference. The module can be installed side by side with the PowerShell SDK 1.x line, which is helpful if you have older scripts that aren’t ready for a migration project this week. Nobody needs that surprise in the middle of a maintenance window. Compatibility details that kinda matter The release notes call out these requirements and compatibility points: Purity FlashArray support for REST API versions 2.0 through 2.52, inclusive .NET Core 2.1 or later as the stated requirement A 64-bit operating system Windows PowerShell minimum versions for Windows 10, Windows Server 2016, Windows Server 2019, macOS, and Linux macOS and Linux support is noted as not fully tested The practical takeaway: check the host where your automation actually runs, not just the workstation where you first tested the module. A script that works from a newer admin laptop can still fail when it lands on an older jump host with a different PowerShell runtime. A worked example: turning a storage workflow back into storage automation Imagine a team managing application file systems for several environments. Their current process looks like this: Create the file system from PowerShell. Open a separate tool to add policy associations. Manually set QoS on the host group. Add tags to snapshots later, because the first script doesn’t know about them. Keep a second script around to inspect placement results when the environment gets busy. None of those steps is individually terrible. Together, they create the classic “automation” workflow where the human is still the integration layer. With 2.52.323, the team can start consolidating that process around the SDK’s expanded surface: Use the new workload-oriented directory and file-system parameters to carry workload identity and configuration through provisioning. Include host or host-group QoS limits as part of the create or update operation. Use the expanded preset workload parameters to define naming, protection, export, quota, snapshot, replication, and placement behavior together. Inspect placement recommendation targets, warnings, and projections from PowerShell instead of flattening the response into a yes/no result. Apply snapshot tags as part of the protection workflow rather than as a manual afterthought. The point isn’t that one giant script should own the entire storage universe. Please don’t build that script. The point is that each stage can now express more of the intended state directly, with fewer custom REST wrappers sitting between the operator and the array. The nerdy details A few practical observations from the release notes: The SDK exposes Purity REST API functionality as PowerShell cmdlets, so this release is primarily about keeping the PowerShell surface aligned with the API surface. The release adds 64 cmdlets and expands 47 existing cmdlets with new parameters. The release notes do not report performance testing for this release. The full cmdlet and parameter inventory is long, 472 lines in the published release-notes file, so use the source document as the exhaustive reference instead of treating this post as a replacement for it. Why this matters The best SDK release is not the one that gives you the most commands to memorize. It’s the one that lets you delete the most “temporary” code. PowerShell SDK 2.52.323 gives admins more direct coverage for Object Store, policies, QoS, workload configuration, snapshots, tags, realms, placement, and identity. That means fewer hand-built REST calls, fewer disconnected provisioning steps, and a better chance that the automation describes the desired storage state instead of merely replaying the clicks somebody made last quarter. Start with the parts your scripts already work around. Install from the PowerShell Gallery, update the help, compare your wrappers with the new cmdlets and parameters, and migrate incrementally. You don’t have to boil the ocean. You just have to stop rebuilding the same little piece of ocean in every script. Until next time… Cheers!PowerShell SDK v2.44.111 released with REST API 2.44 support!
🎉 The Pure PowerShell SDK v2 version 2.44.111 has been released! This release marks the full compatibility with Purity REST API version 2.44 and it contains many additions, changes, and deprecations for cmdlets. Please read the Release Notes for more detailed release information. To install the updated module: Install-Module -Name PureStoragePowerShellSDK2 Here is a brief review of the newest additions and changes: In this release, we added the cmdlets for managing Directories, DirectoryServices, Policies, ProtectionGroupSnapshot tags and Servers. Multiple endpoints got new parameters. Find detailed information about the cmdlets in the sections below. On this release we added the following 31 new cmdlet(s): Get-Pfa2DirectoryGroup Get-Pfa2DirectoryPolicyUserGroupQuota New-Pfa2DirectoryPolicyUserGroupQuota Remove-Pfa2DirectoryPolicyUserGroupQuota Get-Pfa2DirectoryUser Get-Pfa2DirectoryGroupQuota New-Pfa2DirectoryService Remove-Pfa2DirectoryService Get-Pfa2DirectoryServiceLocalDirectoryService New-Pfa2DirectoryServiceLocalDirectoryService Update-Pfa2DirectoryServiceLocalDirectoryService Remove-Pfa2DirectoryServiceLocalDirectoryService Get-Pfa2DirectoryUserQuota Get-Pfa2PolicyUserGroupQuota New-Pfa2PolicyUserGroupQuota Update-Pfa2PolicyUserGroupQuota Remove-Pfa2PolicyUserGroupQuota Get-Pfa2PolicyUserGroupQuotaMember New-Pfa2PolicyUserGroupQuotaMember Remove-Pfa2PolicyUserGroupQuotaMember Get-Pfa2PolicyUserGroupQuotaRule New-Pfa2PolicyUserGroupQuotaRule Update-Pfa2PolicyUserGroupQuotaRule Remove-Pfa2PolicyUserGroupQuotaRule Get-Pfa2ProtectionGroupSnapshotTag Remove-Pfa2ProtectionGroupSnapshotTag Set-Pfa2ProtectionGroupSnapshotTagBatch Get-Pfa2Servers New-Pfa2Servers Update-Pfa2Servers Remove-Pfa2Servers The following 29 cmdlet(s) have new parameters: 'New-Pfa2ActiveDirectory' have the following new parameter(s): SourcesId SourcesName 'Update-Pfa2ActiveDirectory' have the following new parameter(s): SourcesId SourcesName 'New-Pfa2DirectoryPolicyNfs' have the following new parameter(s): PoliciesServerId PoliciesServerName 'New-Pfa2DirectoryPolicySmb' have the following new parameter(s): PoliciesServerId PoliciesServerName 'Get-Pfa2DirectoryExport' have the following new parameter(s): Name 'New-Pfa2DirectoryExport' have the following new parameter(s): Name ServerId ServerName 'Remove-Pfa2DirectoryExport' have the following new parameter(s): Name 'Get-Pfa2DirectoryService' have the following new parameter(s): Id 'Update-Pfa2DirectoryService' have the following new parameter(s): Id CaCertificateRefId CaCertificateRefName CaCertificateRefResourceType SourcesId SourcesName 'Get-Pfa2DirectoryServiceLocalGroup' have the following new parameter(s): AllowErrors ContextName 'New-Pfa2DirectoryServiceLocalGroup' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames 'Update-Pfa2DirectoryServiceLocalGroup' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames ContextId 'Remove-Pfa2DirectoryServiceLocalGroup' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames 'Get-Pfa2DirectoryServiceLocalGroupMember' have the following new parameter(s): AllowErrors ContextName 'New-Pfa2DirectoryServiceLocalGroupMember' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames 'Remove-Pfa2DirectoryServiceLocalGroupMember' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames 'Get-Pfa2DirectoryServiceLocalUser' have the following new parameter(s): AllowErrors ContextName 'New-Pfa2DirectoryServiceLocalUser' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames 'Update-Pfa2DirectoryServiceLocalUser' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames 'Remove-Pfa2DirectoryServiceLocalUser' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames 'Get-Pfa2DirectoryServiceLocalUserMember' have the following new parameter(s): AllowErrors ContextName 'New-Pfa2DirectoryServiceLocalUserMember' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames 'Remove-Pfa2DirectoryServiceLocalUserMember' have the following new parameter(s): ContextName LocalDirectoryServiceIds LocalDirectoryServiceNames 'New-Pfa2NetworkInterface' have the following new parameter(s): AttachedServersId AttachedServersName 'Update-Pfa2NetworkInterface' have the following new parameter(s): AttachedServersId AttachedServersName 'New-Pfa2PolicyNfsMember' have the following new parameter(s): MembersServerId MembersServerName 'New-Pfa2PolicySmbMember' have the following new parameter(s): MembersServerId MembersServerName 'New-Pfa2ProtectionGroupSnapshot' have the following new parameter(s): TagsCopyable TagsKey TagsNamespace TagsValue TagsContextId TagsContextName TagsResourceId TagsResourceName 'New-Pfa2ProtectionGroupSnapshotTest' have the following new parameter(s): TagsCopyable TagsKey TagsNamespace TagsValue TagsContextId TagsContextName TagsResourceId TagsResourceName The following 16 cmdlet(s) had parameters dropped: 'Update-Pfa2Array' dropped the following parameter(s): ContextNames 'Update-Pfa2ContainerDefaultProtection' dropped the following parameter(s): ContextNames 'Update-Pfa2DirectoryService' dropped the following parameter(s): ContextNames 'Update-Pfa2DirectoryServiceRole' dropped the following parameter(s): ContextNames 'Set-Pfa2PresetWorkload' dropped the following parameter(s): ContextNames 'New-Pfa2ProtectionGroupSnapshot' dropped the following parameter(s): ContextNames 'Update-Pfa2ProtectionGroupSnapshot' dropped the following parameter(s): ContextNames 'New-Pfa2ProtectionGroupSnapshotTest' dropped the following parameter(s): ContextNames 'Update-Pfa2ProtectionGroup' dropped the following parameter(s): ContextNames 'New-Pfa2RemoteProtectionGroupSnapshot' dropped the following parameter(s): ContextNames 'New-Pfa2RemoteProtectionGroupSnapshotTest' dropped the following parameter(s): ContextNames 'Update-Pfa2RemoteProtectionGroup' dropped the following parameter(s): ContextNames 'New-Pfa2SyslogServer' dropped the following parameter(s): ContextNames 'Update-Pfa2SyslogServer' dropped the following parameter(s): ContextNames 'Update-Pfa2SyslogServerSetting' dropped the following parameter(s): ContextNames 'New-Pfa2WorkloadPlacementRecommendation' dropped the following parameter(s): ContextNamesPure Storage PowerShell SDK2 version 2.43.46 released!
We released the Pure Storage PowerShell SDK version 2.43.30 not too long ago. We have since received reports of users having issue with the Connect-Pfa2Array cmdlet only when using PowerShell version 5.x. The error would something similar to this: Could not load file or assembly 'System.ComponentModel.Annotations, Version=4.2.0.0, Culture=neutral, PublicKeyToken=someToken' or one of its dependencies. We have released a fix for this in the PowerShell Gallery. https://www.powershellgallery.com/packages/PureStoragePowerShellSDK2/2.43.46. This was the only fix for this release and the issue does not affect the cmdlet when used with PowerShell version 7.x. To upgrade, run Install-Module: Install-Module -Name PureStoragePowerShellSDK2 -Repository PSGallery -RequiredVersion 2.43.46 -Verbose -Force We do apologize for any inconvenience this may have caused.New Pure Code site is live!
After many months of messing with some very old code, we have launched a revised site for the Pure Code Portal. It is much more minimalistic and cleaner than the old one, and we have plans to add our Code videos and Pure Employee website links in the near future. Have a look and feel free to leave a comment if you would like to see something on the site. https://code.purestorage.com/ Cheers, //MikeSome Fleet PowerShell code using Invoke-RestMethod
Hello fellow scripters! This script is a PowerShell script that uses native PowerShell cmdlets to do the tasks. It does not use the Pure Storage PowerShell SDK2. This is for folks who do raw API calls using automation packages, runbooks, and scripts. It is not intended to use in it's entirety, but rather to be used as code snippets and starters for your own scripts. The full script is available in this GitHub repository. This script will: Use native PowerShell (non-SDK) Invoke-RestMethod calls to the FlashArray API Authenticates an API Token user and gets the x-auth-token for requests Query a fleet and determine the fleet members Query fleet Presets & Workloads List fleet volumes and hosts (top X, configurable) Create a host, volume, and then connect the volume to the host on a member array. <# .SYNOPSIS Authenticates to Pure Storage FlashArray REST API and retrieves session token. .DESCRIPTION - Authenticates using API token. - Retrieves the x-auth-token from response headers for subsequent requests. - Dynamically queries the FlashArray for the latest available API version and uses it for requests. .PARAMETER Target Required. The FQDN or IP address of the FlashArray to target for REST API calls. .PARAMETER ApiToken Required. The API token used for authentication with the FlashArray REST API. .EXAMPLE .\Connect-FAApi.ps1 -Target "10.0.0.100" -ApiToken "<Your API Token here>" .NOTES Author: [email protected] Origin Date: 10/23/2023 Version: 1.1 #> param ( [Parameter(Mandatory = $true)] [string]$Target, [Parameter(Mandatory = $true)] [string]$ApiToken ) ################ SETUP ################ # Query the array for the latest available API version try { $apiVersions = Invoke-RestMethod -Uri "https://$Target/api/api_version" -Method Get -SkipCertificateCheck $numericApiVersions = $apiVersions.version | Where-Object { $_ -match '^\d+(\.\d+)*$' -and $_ -notmatch '^2\.x$' } $latestApiVersion = ($numericApiVersions | Sort-Object { [version]$_ } -Descending)[0] Write-Host "Latest API Version detected:" $latestApiVersion } catch { Write-Host "Could not retrieve API version, defaulting to 2.45" $latestApiVersion = "2.45" } # Set the Base Uri if ($latestApiVersion) { $baseUrl = "https://$Target/api/$latestApiVersion" } # Prepare headers for authentication $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]" $headers["api-token"] = $ApiToken # Authenticate and get session token $response = Invoke-RestMethod "https://$Target/api/$latestApiVersion/login" -Method 'POST' -Headers $headers -SkipCertificateCheck -ResponseHeadersVariable "respHeaders" # Display the value of "username" from the response, if present if ($response.items -and $response.items[0].username) { Write-Host "Username:" $response.items[0].username } else { Write-Host "Username field not found in response." } # TO-DO: Check if user is LDAP or local # Parse "x-auth-token" from response headers and store in $xAuthHeader $xAuthHeader = $respHeaders["x-auth-token"] Write-Host "x-auth-token:" $xAuthHeader # Add x-auth-token to headers for subsequent requests $headers.Add("x-auth-token", $xAuthHeader) # You can now use $headers for further authenticated requests to the FA API ########################################################################### Add pagination, query the fleet: # optional pagination & limit code $continuation_token = $null $limit = 10 # Adjust as needed ################ FLEETS ################ # Get Fleet name $fleetsResponse = Invoke-RestMethod -Uri "$baseUrl/fleets" -Method Get -Headers $headers -SkipCertificateCheck $fleetName = $fleetsResponse.items[0].name #Write-Host "Fleet Name: $fleetName" # Get fleet members $membersUrl = "$baseUrl/fleets/members?fleet_name=$fleetName" $membersResponse = Invoke-RestMethod -Uri $membersUrl -Method Get -Headers $headers -SkipCertificateCheck if (-not $membersResponse.items -or $membersResponse.items.Count -eq 0) { Write-Error "No fleet members found." exit 1 } # Extract Fleet member names $VAR_RESULTS = @() foreach ($item in $membersResponse.items) { if ($item.member -and $item.member.name) { $VAR_RESULTS += $item.member.name } elseif ($item.name) { $VAR_RESULTS += $item.name } } if ($VAR_RESULTS.Count -eq 0) { Write-Error "No member names found in fleet members response." exit 1 } # Write out the fleet members #Write-Host "Extracted Member Names: $($VAR_RESULTS -join ', ')" Query for volumes, hosts: ################ FLEET VOLUMES QUERY ################ # Query volumes for extracted member names $volumesUrl = "$baseUrl/volumes?context_names=$($VAR_RESULTS -join ',')" ## uncomment for full response - no limit, and comment out pagination code below #$volumesResponse = Invoke-RestMethod -Uri $volumesUrl -Method Get -Headers $headers -SkipCertificateCheck #$volumesResponse | ConvertTo-Json -Depth 5 ## with paginated reponse do { ## Build the query string for pagination $queryString = "?limit=$limit" if ($continuation_token) { $queryString += "&continuation_token=$continuation_token" } $volumesUrl = "$baseUrl/volumes$queryString" ## Invoke REST method and capture response headers $volumesResponse = Invoke-RestMethod -Uri $volumesUrl -Method Get -Headers $headers -SkipCertificateCheck -ResponseHeadersVariable respHeaders ## Output volumes data $volumesResponse | ConvertTo-Json -Depth 5 ## Extract x-next-token from response headers for next page $continuation_token = $respHeaders["x-next-token"] ## Continue if x-next-token is present } while ($continuation_token) ################ FLEET HOSTS QUERY ################ # Query hosts for extracted member names $hostsUrl = "$baseUrl/hosts?context_names=$($VAR_RESULTS -join ',')" ## full response - no limit, and comment out pagination code below #$hostsResponse = Invoke-RestMethod -Uri $hostsUrl -Method Get -Headers $headers -SkipCertificateCheck #$hostsResponse | ConvertTo-Json -Depth 5 ## with paginated reponse do { ## Build the query string for pagination $queryString = "?limit=$limit" if ($continuation_token) { $queryString += "&continuation_token=$continuation_token" } $hostsUrl = "$baseUrl/hosts$queryString" ## Invoke REST method and capture response headers $hostsResponse = Invoke-RestMethod -Uri $hostsUrl -Method Get -Headers $headers -SkipCertificateCheck -ResponseHeadersVariable respHeaders ## Output hosts data $hostsResponse | ConvertTo-Json -Depth 5 ## Extract x-next-token from response headers for next page $continuation_token = $respHeaders["x-next-token"] ## Continue if x-next-token is present } while ($continuation_token) Query for Presets & Workloads: ################ FLEET PRESETS QUERY ################ $presetsUrl = "$baseUrl/presets?context_names=$($VAR_RESULTS -join ',')" $presetsResponse = Invoke-RestMethod -Uri $presetsUrl -Method Get -Headers $headers -SkipCertificateCheck -ResponseHeadersVariable respHeaders $presetsResponse | ConvertTo-Json -Depth 5 ################ FLEET WORKLOADS QUERY ################ $workloadsUrl = "$baseUrl/workloads?context_names=$($VAR_RESULTS -join ',')" $workloadsResponse = Invoke-RestMethod -Uri $workloadsUrl -Method Get -Headers $headers -SkipCertificateCheck -ResponseHeadersVariable respHeaders $workloadsResponse | ConvertTo-Json -Depth 5 Create a Host on a fleet member array, create a volume, connect the volume to the host: ################ CREATE VOLUME, HOST, AND CONNECT THEM ON ANOTHER FLASHARRAY IN THE FLEET ################ # Select a secondary FlashArray in the fleet $otherArrayName = $VAR_RESULTS | Where-Object { $_ -ne $Target } | Select-Object -First 1 if (-not $otherArrayName) { Write-Error "No other FlashArray found in the fleet." exit 1 } Write-Host "Selected secondary FlashArray for operations: $otherArrayName" # Create a new volume on the secondary FlashArray $newVolumeName = "APIDemo-Vol01" $volumePayload = @{ name = $newVolumeName size = 10737418240 # 10 GiB in bytes context = @{ name = $otherArrayName } } $createVolumeUrl = "$baseUrl/volumes" $createVolumeResponse = Invoke-RestMethod -Uri $createVolumeUrl -Method Post -Headers $headers -Body ($volumePayload | ConvertTo-Json) -ContentType "application/json" -SkipCertificateCheck Write-Host "Created volume:" $newVolumeName "on" $otherArrayName # Create a new host on the secondary FlashArray $newHostName = "FleetDemoHost01" $IQN = "iqn.2023-07.com.fleetdemo:host01" $hostPayload = @{ name = $newHostName iqn = @($IQN) context = @{ name = $otherArrayName } } $createHostUrl = "$baseUrl/hosts" $createHostResponse = Invoke-RestMethod -Uri $createHostUrl -Method Post -Headers $headers -Body ($hostPayload | ConvertTo-Json) -ContentType "application/json" -SkipCertificateCheck Write-Host "Created host:" $newHostName "with IQN:" $IQN "on" $otherArrayName # Connect the newly created volume to the newly created host $connectPayload = @{ volume = @{ name = $newVolumeName context = @{ name = $otherArrayName } } host = @{ name = $newHostName context = @{ name = $otherArrayName } } } $connectUrl = "$baseUrl/host-volume-connections" $connectResponse = Invoke-RestMethod -Uri $connectUrl -Method Post -Headers $headers -Body ($connectPayload | ConvertTo-Json) -ContentType "application/json" -SkipCertificateCheck Write-Host "Connected volume" $newVolumeName "to host" $newHostName "on" $otherArrayName # Output results $createVolumeResponse | ConvertTo-Json -Depth 5 $createHostResponse | ConvertTo-Json -Depth 5 $connectResponse | ConvertTo-Json -Depth 5
Configure Fusion with Powershell!
Here's a little Powershell script to get a new FlashArray Fusion Fleet up and running and verify you can deploy a 1GB test volume on array 2 even though you're connected to array 1! You'll need PureStoragePowershellSDK2 v2.4.30 or newer, Purity 6.8.1 or newer, and both arrays configured to use the same LDAP or Active Directory infrastructure for management to run it. The script will prompt you for two FlashArrays to connect to, what you'd like to name the new fleet, and LDAP/Active Directory credentials with array admin rights on both arrays. If you haven't tried Fusion yet and like automating with Powershell, give it a try! #################################################################################### # Script to create a new Fusion fleet, add a second array to the fleet, and # create a new 1GB test volume on array 2 via a command sent to array 1. # # Mike Sasse - 8/15/2025 - v1.0 #################################################################################### #Stop the script if any command throws an error $ErrorActionPreference = "Stop" #Display script function and requirements Write-Host "This script will create a new Fusion fleet, add a second array to the fleet, and" Write-Host "create a new test volume on array 2 via a command sent to array 1." Write-Host "`nPure Storage SDK2 2.43.30+ must be installed and both arrays must be running Purity 6.8.1+." #Import Pure Storage PowerShell SDK2 Import-Module PureStoragePowerShellSDK2 #Prompt user for the two FlashArrays $FlashArray1Name = Read-Host "Enter the first FlashArray FQDN or IP" $FlashArray2Name = Read-Host "Enter the second FlashArray FQDN or IP" #Prompt user for new fleet name $Fleet = Read-Host "Enter the new fleet name" #Get credentials to connect to the two FlashArrays Write-Host "Enter LDAP/Active Directory credentials with array admin rights to be used to connect to both FlashArrays:" $Creds = Get-Credential #Connect to both FlashArrays Write-Host "`nConnecting to $FlashArray1Name..." $FlashArray1 = Connect-Pfa2Array -Endpoint $Flasharray1Name -Credential $Creds -IgnoreCertificateError Write-Host "`nConnecting to $FlashArray2Name..." $FlashArray2 = Connect-Pfa2Array -Endpoint $Flasharray2Name -Credential $Creds -IgnoreCertificateError #Store the new test volume name as a variable $volumeName = "FusionTestVolume" #Store the new test volume size as a variable $Size = "1GB" #Create the new fleet via FlashArray 1 and pipe the output to null Write-Host "`nCreating new fleet named $Fleet on $FlashArray1Name..." New-Pfa2Fleet -Array $FlashArray1 -Name $Fleet | Out-Null #Create a new fleet key and store as a variable Write-Host "`nFetching new fleet key..." $FleetKey = New-Pfa2FleetKey -Array $FlashArray1 #Grab FlashArray 2 and store as a variable $FA2 = Get-Pfa2Array -Array $FlashArray2 #Join FlashArray 2 to the fleet and pipe the output to null Write-Host "`nJoining $Flasharray2Name to $Fleet..." New-Pfa2FleetMember -Array $FlashArray2 -FleetName $Fleet -MembersKey $FleetKey._FleetKey -MemberName $FA2.Name -MemberResourceType remote-arrays | Out-Null #Create a new test volume on FlashArray 2 via FlashArray 1 and pipe the output to null Write-Host "`nCreating new volume $volumeName on $Flasharray2Name through $Flasharray1Name..." New-Pfa2Volume -Array $FlashArray1 -Name $volumeName -Provisioned $Size -ContextNames $FA2.Name | Out-Null Write-Host "`nComplete!"PowerShell SDK v2.43.30 released!
The Pure PowerShell SDK version 2.43.30 has been released! There are a boatload of changes in this release, and all of those changes can be found in the release notes. New cmdlets for Fleets, tags, realms, and more. New parameters for context_names (fleets) and Allow_Errors. Install the SDK today! Install-Module PureStoragePowerShellSDK2 Update your current version: Update-Module PureStoragePowerShellSDK2 PowerShell Gallery Link
Is there a way to view lower level Fibre Channel diagnostic
Is there a way to view lower level Fibre Channel diagnostic logs from the CLI? We are having an issue with some VMware hosts not getting a response to a PLOGI so they are not able to see any volumes from the Pure array on one of our fabrics. Other storage systems on the same fabric are working fine.
