Portworx Enterprise Release Notes

3.2.4

August 22, 2025

This version addresses security vulnerabilities.

3.2.3

May 13, 2025

To install or upgrade Portworx Enterprise to version 3.2.3, ensure that you are running one of the supported kernels and all prerequisites are met.

New Features

• FlashArray Direct Access shared raw block (RWX) volumes
  Portworx now supports FADA shared raw block (RWX) volumes, enabling live migration of KubeVirt VMs with high-performance raw block storage. This eliminates filesystem overhead, improves I/O performance, and ensures seamless migration by allowing simultaneous volume access on source and destination nodes. For more information, see Run KubeVirt VMs with FlashArray Direct Access shared raw block (RWX) volumes.

Note: This release also addresses security vulnerabilities.

Improvements

Improvement Number	Improvement Description	Component
PWX-42785	FlashArray Fibre Channel integration now filters out WWNs from uncabled ports when creating hosts. This enhancement reduces manual intervention and prevents errors during volume attachment in environments with partially connected FC ports.	Volume Management
PWX-43645	Portworx now supports setting the sticky bit for FlashArray Direct Access (FADA) volumes. You can set the sticky bit using the --sticky flag with the pxctl volume update command.	Volume Management
PWX-42482	A backoff mechanism now limits repeated calls, reducing kube-apiserver load. Unnecessary LIST /api/v1/nodes API calls from nodes in the NotReady state or with px/enabled=false are reduced, which improves efficiency.	API

Fixes

Issue Number	Issue Description	Severity
PWX-42489	Portworx made repeated GET requests to /api/v1/namespaces/portworx/configmaps/px-telemetry-phonehome from nodes that were either NotReady or had px/enabled=false. User Impact: These API calls were unnecessary and added load to the Kubernetes API server, particularly in clusters with many storageless or inactive nodes. Resolution: Portworx startup previously made unconditional API calls to fetch telemetry configuration. This has been fixed by updating the sequence to first check local sources before querying the Kubernetes API. Components: Telemetry and Monitoring Affected Versions: 3.2.2.2 or earlier	Minor
PWX-43598	Repl-add could select a replica node that doesn't comply with the volume's volume-affinity VPS rule when no valid pools are available. If a KubeVirt VPS fixer job is running, it may enter a loop of repeated repl-add and repl-remove operations on the same volume without resolving the placement issue. User Impact: This may lead to incorrect replica placement and violation of affinity rules. The VPS fixer job can create unnecessary load by repeatedly attempting to correct the placement. Resolution: Portworx now evaluates additional conditions before allowing fallback to relaxed volume-affinity placement. Relaxed-mode is applied only when no nodes are available that meet the required affinity criteria, ensuring more consistent replica alignment. Components: Volume Placement and Balancing Affected Versions: 3.2.2.2 and earlier	Minor

Known issues (Errata)

Issue Number	Issue Description	Severity
PWX-43463	In OpenShift virtualization, after you restart the entire Kubernetes cluster, virtual machines remain in the Provisioning state because the data volumes fail to complete cloning. CDI uploader pods repeatedly crash with device or resource busy errors, which prevents stable access to multipath block devices. Workaround: Delete pods to clear the CDI controller cache: oc delete pod -n openshift-cnv cdi-deployment-xxxxxx oc delete pod -n openshift-cnv cdi-apiserver-xxxxxx oc delete pod -n openshift-cnv cdi-uploadproxy-xxxxxx oc delete pod -n openshift-cnv cdi-operator-xxxxxx Delete the stuck DataVolume object before retrying the upload: oc delete dv -n <namespace> <data-volume-name>	Minor
PWX-43486	When using FlashArray Direct Access (FADA) shared block volumes, virtual machines (VMs) might temporarily stop during live migration if the primary FlashArray (FA) controller reboots while the secondary controller is unavailable. This occurs because I/O paths are unavailable, causing I/O errors that pause the VM. Workaround: Don’t reboot both FlashArray controllers in quick succession. After bringing one controller back online, wait at least 10 minutes, then confirm that the output of multipath -ll shows active paths from both FlashArray controllers before rebooting the other. You can filter the output by the device serial number, which you can find by matching the PersistentVolumeClaim (PVC) name on the FlashArray and checking the volume’s serial. If a VM pauses, restart the VM pod to recover.	Minor
PWX-42358	On RHEL 8.10 systems, running Linux kernel 4.18, runc exec may fail when attempting to access the Portworx container. This occurs because systemd removes the container’s devices and blkio cgroup directories when it detects no active processes. Although Portworx continues to run as expected, runc cannot execute a command in the container without these cgroup paths. Workaround: To resolve this issue, restart the Portworx service or manually recreate the missing cgroup directories by running the following commands: mkdir -p /sys/fs/cgroup/devices/system.slice/portworx.service/portworx/ mkdir -p /sys/fs/cgroup/blkio/system.slice/portworx.service/portworx/	Minor
PWX-43849	Portworx does not support Debian 11 with kernel version 5.10.0-34-amd64 for PX-StoreV1 due to a known issue, and we recommend using Debian 12 with kernel version 6.1.0-31-amd64.	Minor

3.2.2.2

April 17, 2025

Portworx now supports IPv6 clusters for OpenShift with KubeVirt in dual-stack networking mode. To install or upgrade Portworx Enterprise to version 3.2.2.2, ensure that you are running one of the supported kernels and all prerequisites are met.

Fixes

Issue Number	Issue Description	Severity
PWX-42915	In clusters where IPv6 is preferred (PX_PREFER_IPV6_NETWORK_IP=true), Sharedv4 volume mounts may fail if Portworx selects an incorrect IPv6 address. This causes pods to remain in the ContainerCreating state with a "permission denied" error from the server. User Impact: Pods using Sharedv4 volumes may fail to start in IPv6-preferred or dual-stack clusters. This does not affect clusters using IPv4 by default. Resolution: Portworx now uses a consistent strategy to select the most appropriate IPv6 address: Ignores temporary, deprecated, and unspecified addresses. Scores the remaining addresses: Unique local addresses (ULA): score 1. Global unicast addresses: score = 4 + (128 - prefix length) (e.g., /64 = 68, /128 = 4). Chooses the address with the highest score. If scores are equal, the address with the lowest alphabetical value is selected. This update ensures stable and reliable IPv6 address selection for Sharedv4 volume mounts. Components: Shared Volumes Affected Versions: 3.2.2.1 or earlier	Minor
PWX-42843	When Portworx was deployed in a dual-stack (IPv4 and IPv6) Kubernetes cluster, it created a sharedv4 Kubernetes Service without explicitly specifying the ipFamily field. If ipFamily wasn't set, Kubernetes created an IPv4 address by default, while Portworx was listening on an IPv6 address. User Impact: Pods using sharedv4 service volumes failed to start because sharedv4 volume mounts couldn't complete using the IPv4-based Kubernetes Service IP address. Resolution: Portworx now explicitly sets the ipFamily field on the sharedv4 Kubernetes Service based on the IP address it uses in a dual-stack Kubernetes cluster. Components: Shared Volumes Affected Versions: 3.2.2.1 or earlier	Minor

Known issues (Errata)

Issue Number	Issue Description	Severity
PWX-43355	KubeVirt virtual machines using Portworx on IPv6 clusters with SharedV4 volumes may enter a Paused state. In certain scenarios, the VMs might attempt to mount the volume using a local NFS path that resolves to a Unique Local Address (ULA), which Portworx does not expose for mount operations. Workaround: Configure the spec.parameters.allow_ips field in the StorageClass and specify both Unique Local Address (ULA) and link-local address ranges. Link-local addresses: fe80::/10 Unique local addresses (ULA): fd00::/8 Example StorageClass: apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: px-sharedv4-ipv6-example parameters: repl: "2" sharedv4: "true" sharedv4_svc_type: "ClusterIP" sharedv4_mount_options: vers=3.0,nolock allow_ips: "fe80::/10;fd00::/8" provisioner: pxd.portworx.com reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true Components: Shared Volumes Affected Versions: 3.2.2.2	Minor

3.2.2.1

March 26, 2025

Fixes

Issue Number	Issue Description	Severity
PWX-42778	Processing unaligned write requests on volumes might cause partial data transfer issues. User Impact: When processing large write requests (e.g., 1MB), unaligned blocks at the start of a request might lead to partial data transfers. This occurs when the available space in the user iovecs runs out before the last portion of the data is copied. Note: This issue occurs only when using the virtio driver in a KubeVirt deployment. Resolution: Improved handling of unaligned requests prevents premature exhaustion of user iovecs and ensures that all data is copied for large write operations. Components: Storage Affected Versions: 3.2.2	Minor

3.2.2

March 10, 2025

Since February 10, 2025, the Portworx Essentials license was discontinued. Starting with version 3.2.2, no images will be released for Portworx Essentials.

To install or upgrade Portworx Enterprise to version 3.2.2, ensure that you are running one of the supported kernels and that the prerequisites are met.

New Features

• Encryption support for FlashArray Direct Access (FADA)
  Portworx now supports FADA volume Encryption, providing seamless data protection by encrypting information both in transit and at rest on FlashArray storage. Encryption keys are used consistently across the cluster, even with multiple FlashArrays. This feature ensures that data remains secure throughout the process, with encryption handled at the storage level. For more information, see Create encrypted PVCs in FlashArray.

• NVMe-oF/TCP support for FlashArray Direct Access (FADA)
  Portworx now supports NVMe-oF/TCP protocol, providing high-performance, low-latency storage access for Kubernetes applications using FlashArray LUNs. By leveraging standard TCP/IP, this feature eliminates the need for specialized networking hardware like RoCEv2, making deployment more flexible and cost-effective while maintaining optimal performance. For more information, see Set up NVMe-oF TCP protocol with FlashArray.

• PX-StoreV2 support on additional platforms
  Portworx now supports installation with PX-StoreV2 on the following platforms:

  • Microsoft Azure Kubernetes Service (AKS)
  • Google Kubernetes Engine (GKE)
  • Google Cloud Anthos with FlashArray Cloud Drives

• Portworx Enterprise now supports Kubernetes version 1.31, starting from version 1.31.6. Before upgrading Kubernetes to 1.31.6 or later, update the Portworx Operator to version 24.2.3. For more details, refer to the Portworx Operator 24.2.3 release notes.

note

The logUploader utility is now hosted in the portworx/log-upload repository. Please update your image repository mirrors to pull from this new location.

Fixes

Issue Number	Issue Description	Severity
PWX-41668	In environments with slow container runtimes, the Portworx Pod could report READY=0/1 (Not Ready) even when the backend was fully operational. This occurred due to internal readiness checks failing to update in rare cases. User Impact: The pod might appear as Not Ready, causing confusion in monitoring. Resolution: The readiness check logic has been fixed, ensuring the POD transitions correctly to READY=1/1 when the backend is operational. Components: Monitoring Affected Versions: 3.2.1.2 or earlier	Minor
PWX-40755	When Portworx is configured with separate data and management interfaces, some KubeVirt VMs may enter a paused state during platform or Portworx upgrades. User Impact: During upgrades, certain KubeVirt VMs may pause unexpectedly and require manual intervention to restart. Resolution: The issue has been fixed, ensuring KubeVirt VMs remain operational during Portworx and platform upgrades, without requiring manual restarts. Components: Upgrade Affected Versions: 3.2.0, 3.2.1, 3.2.1.1, and 3.2.1.2	Minor
PWX-40564	Pool expansion could fail if the backend FA volume was expanded but the updated size was not reflected on the node. User Impact: If a drive was expanded only in the backend and a pool expansion was attempted with a size smaller than the backend size, the operation would fail. Resolution: Pool expansion now correctly retrieves and updates the drive size from the backend, preventing failures caused by size mismatches. Components: Drive and Pool Management Affected Versions: All	Minor
PWX-39322	Cloud drive lock contention during the startup of an affected node could cause inconsistencies in the internal KVDB, potentially triggering a panic in other PX nodes. User Impact: In large clusters, where lock contention is more likely, this issue could significantly extend the Portworx cluster restore process. Resolution: If an inconsistency is detected when the affected node starts, it now performs a cleanup to resolve the issue, preventing other nodes from panicking. Components: Drive and Pool Management Affected Versions: All	Minor
PWX-40423	Decommissioning a non-KVDB storage node did not automatically delete the associated drives from the FA backend. User Impact: Users had to manually remove drives from the FA backend after decommissioning a node. Resolution: The decommission process has been updated to ensure that backend devices are deleted automatically when the node wipe is completed. Components: Drive and Pool Management Affected Versions: All	Minor
PWX-41685	The PVC label template in VPS did not recognize incoming label keys containing multiple segments (dots). As a result, the template was not replaced with the label value, leading to unintended VPS behavior. User Impact: Users utilizing PVC label templates with multi-segment PVC labels experienced incorrect VPS functionality. Resolution: Updated the pattern matching for PVC label templates to support multi-segment label keys, ensuring correct label value replacement. Components: Volume Placement and Balancing Affected Versions: All	Minor
PWX-40364	When volume IDs had varying lengths (as expected), the defrag schedule occasionally failed to resume from the correct position after pausing. Instead, it restarted from the beginning, preventing the completion of a full iteration. User Impact: The built-in defrag schedule was unable to iterate through all volumes, rendering it ineffective in addressing performance issues. Users had to revert to using a defrag script. Resolution: The built-in defrag schedule now correctly resumes from the last stopped position and iterates through all volumes as expected. Components: KVDB Affected Versions: 3.2.0 and 3.2.1	Minor
PWX-37613	If a pool expansion failed after cloud drives were expanded but before the pool was updated, attempting a subsequent expansion with a smaller size resulted in an error. User Impact: Users could experience a pool expansion failure if a previous expansion was interrupted and left unfinished, and they attempted another expansion of a smaller size. Resolution: The second pool expansion request now detects and completes the previously interrupted expansion instead of failing. Components: Drive and Pool Management Affected Versions: 3.1.2 to 3.2.1	Minor
PWX-38702	In certain failover scenarios, mounting a shared file system could fail with an "Exists" or "file exists" error. This issue occurs due to an unclean unmount when the file system was last mounted on the same node. User Impact: This might result in user pods remaining in “Container Creating” state. Resolution: The fix addresses multiple underlying causes that lead to unclean unmounts. Additionally, since this issue can also arise due to a race condition in the Linux kernel, the fix now detects such scenarios, aborts the mount process, and provides a clear error message. Components: Shared Volumes Affected Versions: 3.2.0 to 3.2.1.2	Minor
PWX-42043	The CLI command pxctl cred list [-j] returns an error and fails to list credentials. User Impact: If the cluster contains non-S3 credentials, the pxctl cred list [-j] command will not display the credentials. Resolution: The command now correctly lists all credentials, including non-S3 credentials, without errors. Components: CLI and API Affected Versions: 3.1.8, 3.2.1.2	Minor

Known issues (Errata)

• PWX-42379: On PX-Security enabled clusters running Kubernetes 1.31 or later, expanding an in-tree PersistentVolumeClaim (PVC) fails due to compatibility issues. This prevents users from increasing storage capacity through standard PVC expansion methods, potentially impacting workloads that require additional storage.

  Workaround: Until this issue is resolved in a future external-resizer sidecar release from the upstream Kubernetes community, users can manually expand the volume using pxctl volume update --size <new-size> <volume-name> instead of updating the PVC size.
  
  Components: Volume Management
  Affected Versions: 3.2.1.1 or later
  Severity: Minor

• PWX-42513: When you deploy more than 100 apps with FlashArray Direct Access (FADA) PVCs using NVMe-oF-TCP at the same time, volumes are created in the backend. However, the attempt to attach hosts to the volume in the Portworx layer sometimes fails, leaving device mappers on the hosts with no available paths. Because the mapper device is created, Portworx attempts to create a filesystem but hangs due to the missing paths.

  Additionally, PVC creations can get stuck in the ContainerCreating state. The large number of multipath FADA volumes increases the time required for newer FADA volumes' multipath to appear, causing Portworx to enter an error state.

  Note: We recommend creating FADA volumes in batches with a significant interval between each batch.

  Workaround: To recover from this state, perform the following steps:

  1. Identify the affected device:

     multipath -ll

     eui.00806e28521374ac24a9371800023155 dm-34 ##,##
     size=50G features='1 queue_if_no_path' hwhandler='0' wp=rw

  2. Disable queueing for the affected device:

     multipathd disablequeueing map eui.00806e28521374ac24a9371800023155

  3. Flush the multipath device:

     multipath -f eui.00806e28521374ac24a9371800023155

  4. Verify that the device has been removed:

     multipath -ll eui.00806e28521374ac24a9371800023155

  5. Reattach the volume manually from the FA controller to the host (worker node).

  6. Confirm that the device is correctly reattached and that paths are available:

     multipath -ll eui.00806e28521374ac24a9371800023155

     eui.00806e28521374ac24a9371800023155 dm-34 NVME,Pure Storage FlashArray                 
     size=50G features='4 queue_if_no_path retain_attached_hw_handler queue_mode bio' hwhandler='0' wp=rw
     `-+- policy='queue-length 0' prio=50 status=active
       |- 1:245:24:544    nvme1n24 259:68 active ready running
       `- 0:1008:24:544   nvme0n24 259:71 active ready running

  7. Confirm that no Portworx processes are in an uninterruptible sleep state (D state) using the following command:

     ps aux | grep " D "

  
  Components: Volume Management
  Affected Versions: 3.2.2
  Severity: Minor

3.2.1.2

February 04, 2025

New Features

Portworx Enterprise now supports the following:

• Installation of Portworx with PX-StoreV2 on Rancher clusters running on Ubuntu or SUSE Linux Micro. For hardware and software requirements, see Prerequisites.
• Rancher clusters on SUSE Linux Micro. For a list of supported distributions and kernel versions, see Qualified Distros and Kernel Versions.

Note: This release also addresses security vulnerabilities.

Fixes

Issue Number	Issue Description	Severity
PWX-41663	If Kubernetes clusters contain FlashBlade volumes migrated from Pure Storage Orchestrator (PSO) clusters, the Portworx process on these systems enters a continuous crash loop, preventing normal volume operations. User Impact: Portworx repeatedly crashes and restarts, preventing normal cluster operation. Resolution: This issue has been resolved. Portworx no longer crashes in environments with FlashBlade volumes migrated from PSO clusters. Components: Upgrade Affected Versions: 3.2.1, 3.2.1.1	Major

Known issues (Errata)

Issue Number	Issue Description	Severity
PD-3880	On systems with automatic updates enabled, the system may upgrade to a kernel version that is not listed on the supported kernel page. This can prevent the Portworx kernel module from loading, resulting in a failed Portworx installation. Workaround: Disable automatic updates and verify that you are using a supported kernel version. Components: Installation Affected Versions: 3.2.x, 3.1.x, 3.0.x	Major

3.2.1.1

December 17, 2024

Visit these pages to see if you're ready to upgrade to this version:

• Prerequisites
• Supported kernels

Improvements

Portworx has upgraded or enhanced functionality in the following areas:

Improvement Number	Improvement Description	Component
PWX-40233	The volume snapshot count with Portworx CSI for FlashArray and FlashBlade license has been increased from 5 to 64	Licensing & Metering
PWX-37757	The Pure export rules for accessing FlashBlade are now defined by the specified accessModes in the PVC specification. *(rw) is set for ReadWriteOnce, ReadWriteMany, and ReadWriteOncePod PVC access modes. It allows clients to perform both read and write operations on the storage. *(ro) is applied for ReadOnlyMany PVC access mode. It ensures that the storage can only be accessed in read-only mode, preventing modifications to the data.	Volume Management

Fixes

Issue Number	Issue Description	Severity
PWX-38838	During asynchronous disaster recovery, delete requests for objects in the object-store were being rejected when the schedule contained more than 16 volumes. User Impact: Due to this issue, users saw some of the asynchronous disaster recovery relayed objects were not being cleaned up from object-store. Resolution: The system has been updated to accept up to 64 delete requests. This change prevents objects from being retained in the object-store when the schedule includes more than 16 volumes but fewer than 64. Components: Migration Affected Versions: 3.2.x, 3.1.x, 3.0.x	Major
PWX-40477	Portworx cluster failed to migrate from using external KVDB to internal KVDB. User Impact: Due to this issue, users were unable to migrate their Portworx clusters from external KVDB to internal KVDB, disrupting operations that rely on the internal KVDB for managing the cluster's state and configuration. Resolution: Portworx clusters can now be successfully migrated from external KVDB to internal KVDB. For instructions, contact Portworx Support. Components: KVDB Affected Versions: 3.2.0, 2.13.12	Major

3.2.1

December 2, 2024

Visit these pages to see if you're ready to upgrade to this version:

• Prerequisites
• Supported kernels

New features

Portworx by Pure Storage is proud to introduce the following new features:

• Portworx now supports the PX-StoreV2 backend on the following platforms
  • Anthos on vSphere
  • OpenShift on vSphere
  • Openshift with FlashArray Cloud Drives

3.2.0

October 31, 2024

Visit these pages to see if you're ready to upgrade to this version:

• Prerequisites
• Supported kernels

note

Portworx 3.2.0 requires Portworx Operator 24.1.3 or newer.

New features

Portworx by Pure Storage is proud to introduce the following new features:

• Secure multi-tenancy with Pure FlashArray When a single FlashArray is shared among multiple users, administrators can use realms to allocate storage resources to each tenant within isolated environments. Realms set boundaries, allowing administrators to define custom policies for each tenant. When a realm is specified, the user must provide a FlashArray pod name where Portworx will create all volumes (direct access or cloud drives) within that realm. This ensures that each tenant can only see their own storage volumes when logged into the array.
• Support for VMware Storage vMotion Portworx now supports the Storage vMotion feature of VMware, enabling vSphere cloud drives to be moved from one datastore to another without any downtime.
• Defragmentation schedules Users can now set up defragmentation schedules using pxctl commands during periods of low workload to improve the performance of Portworx.

Improvements

Portworx has upgraded or enhanced functionality in the following areas:

Improvement Number	Improvement Description	Component
PWX-35876	For IBM customers, Portworx now supports the StorageClass with the encryption flag set to true.	Marketplaces
PWX-38395	Previously, all storageless nodes would restart to claim a driveset when a storage node went down and its driveset was detached in the same zone. With this improvement, only one storageless node will claim ownership of the driveset and restart, while the other storageless nodes remain unaffected and do not restart.	Drive & Pool Management
PWX-33561	For partially attached drivesets, Portworx now detaches the driveset only when cloud drives are not mounted, avoiding unnecessary detachment when a mount is present.	Drive & Pool Management
PWX-37403	FlashArray now allows specifying multiple management ports for the same FlashArray. If customers are on a VLAN connection to FlashArray, the virtual IP address might encounter issues. Customers can specify the management IPs of the controllers directly in the secret as comma-separated values.	Drive & Pool Management
PWX-38597	For FlashArray Cloud Drives, on Portworx restart, any stale entries of the driveset are cleaned, and the locally attached driveset is prioritized for mounting volumes rather than checking all other drives.	Drive & Pool Management
PWX-39131	The total number of GET API calls are reduced significantly.	Drive & Pool Management
PWX-38551	The latency of any operation on FlashArray due to multiple API calls has been reduced. Portworx now uses the FlashArray IDs stored in the cloud drive config map to limit API calls only to the FlashArray where the drive resides.	Drive & Pool Management
PWX-37864	When you add a drive using the pool expand add-drive operation, the config map is now automatically updated with the pool ID of the newly added drive, preventing the need for a Portworx restart.	Drive & Pool Management
PWX-38630	Portworx now supports adding a cloud drive to a storageless node when the cloud drive specification for the journal device in the StorageCluster spec is explicitly set to a value other than auto.	Drive & Pool Management
PWX-38074	Improved the startup timing of Portworx nodes in multi-FlashArray setups by handling metrics timeouts more effectively. When volume creation on a FlashArray takes too long, Portworx now avoids sending further requests to that FlashArray for 15 minutes, allowing other nodes to continue the startup process without delays.	Drive & Pool Management
PWX-38644	For FlashArray Cloud Drives, pool expansion failure messages are no longer overridden by maintenance mode messages, providing more useful error information for users to debug their environment.	Drive & Pool Management
PWX-33042	In disaggregated environments, users cannot add drives to a storageless node labeled as portworx.io/node-type=storageless. To add drives, users need to change the node label to portworx.io/node-type=storage and restart Portworx.	Drive & Pool Management
PWX-38169	During pool expansion, Portworx now check the specific driveset that the node records, rather than iterating through all drivesets in the cluster randomly. This change significantly reduces the number of API calls made to the backend, thereby decreasing the time required for pool expansion and minimizing the risk of failure, particularly in large clusters.	Drive & Pool Management
PWX-38691	Portworx now raises an alert called ArrayLoginFailed when it fails to log into a FlashArray using the provided credentials. The alert includes a message listing the arrays where the login is failing.	Drive & Pool Management
PWX-37672	The pxctl cd i --<node-ID> command now displays the IOPS set during disk creation	Drive & Pool Management
PWX-37439	Azure users can now specify IOPS and throughput parameters for Ultra Disk and Premium v2 disks. These parameters can only be set during the installation process.	Drive & Pool Management
PWX-38397	Portworx now exposes NFS proc FS pool stats as Prometheus metrics. Metrics to track the number of Packets Arrived, Sockets Enqueued, Threads Woken, and Threads Timedout have been added.	Shared Volumes
PWX-35278	A cache for the NFS and Mountd ports has been added, so the system no longer needs to look up the ports every time. The GetPort function is only called the first time during the creation or update of the port, and the cache updates if accessed 15 minutes after the previous call.	Shared Volumes
PWX-33580	The NFS unmount process has been improved by adding a timeout for the stat command, preventing it from getting stuck when the NFS server is offline and allowing retries without hanging.	Shared volumes
PWX-38180	Users can now set the QPS and Burst rate to configure the rate at which API requests are made to the Kubernetes API server. This ensures that the failover of the sharedv4 service in a scaled setup is successful, even if another operation causes an error and restarts some application pods. To do this, add the following environment variables: KUBERNETES_OPS_QPS_RATE with value: 2000 KUBERNETES_OPS_BURST_RATE with value: 4000	Shared Volumes
PWX-39035	Portworx will no longer print the Last Attached field in the CLI's volume inspect output if the volume has never been attached.	Volume Management
PWX-39373	For FlashArray Direct Access volumes, the token timeout time has been is increased from 15 minutes to 5 hours to avoid, which provides enough time for Portworx to process large number of API token requests	Volume Management
PWX-39302	For Portworx CSI volumes, calls to the Kubernetes API to inspect a PVC have been significantly reduced, improving performance.	Volume Management
PWX-37798	Users can now remove labels from a Portworx volume using the pxctl volume update -l command, allowing them to manually assign pre-provisioned Portworx volumes to a pod.	Volume Management
PWX-38585	FlashArray Direct Access users can now clone volumes using pxctl.	Volume Management
PWX-35300	Improved FlashBlade Direct Access volume creation performance by removing an internal lock, which previously caused delays during parallel creation processes.	Volume Management
PWX-37910	Cloudsnaps are now initialized using a snapshot of KVDB avoiding failure errors.	Storage
PWX-35130	Portworx now sends an error message and exits the retry loop when a volume is stuck in a pending state, preventing continuous creation attempts.	Storage
PWX-35769	Storageless nodes now remain in maintenance mode without being decommissioned, even if they exceed the auto-decommission timeout. This prevents failure for user-triggered operations when the storageless node is in maintenance mode.	Control Plane
PWX-39540	Portworx now ensures the correct information for a pure volume is returned, even if the FlashArray is buggy, preventing node crashes.	Control Plane
PWX-37765	The pxctl volume list command has been improved to allow the use of the --pool-uid flag alongside the --trashcan flag, enabling the filtering of trashcan volumes based on the specified Pool UUID.	CLI & API
PWX-37722	Added a new --pool-uid flag to the pxctl clouddrive inspect command, allowing users to filter the inspect output based on the specified Pool UUID.	CLI & API
PWX-30622	The output of the pxctl volume inspect <volume-id> command now displays the labels alphabetically, making it easier to track any changes made to labels.	CLI & API
PWX-39146	The pxctl status output also includes a timestamp indicating when the information was collected.	CLI & API
PWX-36245	PX-StoreV2 pools now support a maximum capacity of 480TB by choosing appropriate chunk size during pool creation.	PX-StoreV2
PWX-39059	Portworx now installs successfully on cGroupsV2 and Docker Container runtime environments.	Install & Uninstall
PWX-37195	Portworx now automatically detects SELinux-related issues during installation and attempts to resolve them, ensuring a smoother installation process on SELinux-enabled platforms.	Install & Uninstall
PWX-38848	Portworx now properly handles the floating license-lease updates, when cloud-drives move between the nodes.	Licensing & Metering
PWX-38694	Improved the time to bring up a large cluster by removing a short-lived cluster lock used in cloud drive deployments.	KVDB
PWX-38577	The logic for handling KVDB nodes when out of quorum has been improved in Portworx. Now, Portworx processes do not restart when KVDB nodes are down.	KVDB

Fixes

Issue Number	Issue Description	Severity
PWX-38609	Portworx sometimes lost the driveset lock for FlashArray cloud drives when the KVDB drive was removed in situations such as KVDB failover. User Impact: Loss of the driveset lock resulted in other nodes attempting to attach a drive already attached to the current node. Resolution: Portworx now uses a temporary driveset to safely remove the KVDB drive. Components: KVDB Affected Versions: 3.1.5	Critical
PWX-38721	Portworx attempted to mount FlashBlade Direct Access volumes using the NFS IP. However, if an existing mount point used an FQDN, Portworx defaulted to the FQDN after a restart. If a Kubernetes mount request timed out, but Portworx completed it successfully, Kubernetes retried the request. Portworx then returned an error due to the FQDN, leading to repeated mount attempts. User Impact: Application pods with a timed-out initial mount request were stuck in the ContainerCreating state. Resolution: Portworx now performs IP resolution on the existing mount entry. If they match, it confirms the mount paths are already created, and Portworx returns a success. Components: Volume Management Affected Versions: 3.1.x, 3.0.x	Critical
PWX-38618	In a cluster where multiple applications used the same FlashBlade Direct Access volume, some applications used FQDNs while others used IP addresses. The NFS server recognized only the FQDN, causing a mismatch in the mount source paths tracked by Portworx. User Impact: Application pods using IPs to mount the FlashBlade Direct Access volume were stuck in the terminating state. Resolution: When a request is received from CSI to unmount a target path for FlashBlade Direct Access, Portworx unconditionally unmounts it, even if the source path differs from the one recognized by it. Components: Volume Management Affected Versions: 3.1.x, 3.0.x	Critical
PWX-38376	During node initialization in the boot-up process, FlashArray properties are required for all the dev mapper paths already present on the node. This call is made to all arrays configured in pure.json configuration file, which sometimes failed, causing the initialization to fail. User Impact: Users saw node initialization failures due to errors from arrays that had no volumes for the current node. Additionally, unintended extra API calls were made to the arrays, contributing to the overall API load. Resolution: Portworx now uses the FlashArray volume serial to determine which array the volume belongs to. The array ID is then passed as a label selector to DeviceMappings, ensuring that only the relevant array is queried. Components: Volume Management Affected Versions: 3.1.x, 3.0.x	Critical
PWX-36693	When a storageless node transitioned to a storage node, the node's identity changed as it took over the storage node identity. The old identity corresponding to the storageless node was removed from the Portworx cluster. All volumes attached to the removed node were marked as detached, even if pods were currently running on the node. User Impact: Volumes incorrectly appeared as detached, even while pods were running and consuming the volumes. Resolution: Portworx now decommissions cloud drives only after the AutoDecommissionTimeout expires, ensuring that volumes remain attached to the node and are not incorrectly displayed as detached. Components: Volume Management Affected Versions: 3.1.1	Critical
PWX-38173	When the storage node attempted to restart, it could not attach the previous driveset, as it was already claimed by another node, and could not start as a new node because the drives were still mounted. User Impact: The storage node attempting to come back online repeatedly restarted due to unmounted drive mount points. Resolution: Portworx now automatically unmounts FlashArray drive mount points if it detects that the previous driveset is unavailable but its mount points still exist. Component: Drive and Pool Management Affected Versions: 3.0.x, 3.1.x	Critical
PWX-38862	During Portworx upgrades, a sync call was triggered and became stuck on nodes when the underlying mounts were unhealthy. User Impact: Portworx upgrades were unsuccessful on nodes with unhealthy shared volume mounts. Resolution: Portworx has removed the sync call, ensuring that upgrades now complete successfully. Components: Drive & Pool Management Affected Versions: 3.1.x	Critical
PWX-38936	If a storage node restarts, it restarted a few times before it could successfully boot, because its driveset was locked and won't be available for a few minutes. User Impact: Users saw the Failed to take the lock on drive set error message and the node took longer time to restart. Resolution: In such case Portworx tells the restarting node that the driveset is not locked, and thus it is able to claim this driveset without having to wait until the lock expires. During this time other nodes still see this driveset as locked and unavailable Components: Drive & Pool Management Affected Versions: 3.1.x	Major
PWX-39627	In large Portworx clusters with many storage nodes using FlashArray or FlashBlade as the backend, multiple nodes might simultaneously attempt to update the lock configmap, resulting in conflict errors from Kubernetes. User Impact: Although the nodes eventually resolved the conflicts, this issue spammed the logs and slowed down boot times, especially in large clusters. Resolution: The refresh interval has been changed from 20 seconds to 1 minute. In case of a conflict error, Portworx now delays the retry by a random interval between 1 and 2 seconds, reducing the likelihood of simultaneous updates. Additionally, the conflict is logged only after 10 consecutive occurrences, indicating a real issue. Components: Drive & Pool Management Affected Versions: 3.1.x, 3.0.x	Major
PWX-36318	In IBM Cloud, the node name is the same as the node IP. If the selected subnet had very few available IPs and Portworx replaced a worker node, the new node would take the same IP. User Impact: When Portworx started on the replaced node with the same IP, it incorrectly assumed that it had locally attached drives due to the volume attachments. This assumption led to an attempt to access the non-attached device path on the new node, causing Portworx to fail to start. Resolution: With the new provider-id annotation added to the volume attachment, Portworx now correctly identifies the replaced node as a new one without local attachments. Component: Drive and Pool Management Affected Versions: 3.1.x	Major
PWX-38114	In IBM Cloud, the node name is the same as the node IP. If the selected subnet had very few available IPs and a worker node was replaced, the new node had the same IP. User Impact: When Portworx started on the replaced node with the same IP, it incorrectly assumed it had locally attached drives due to existing volume attachments, leading to a stat call on the non-attached device path and causing Portworx to fail to start. Resolution: The volume attachment now includes a new annotation, provider-id, which is the unique provider ID of the node, allowing Portworx to recognize that the replaced node is new and has no local attachments. Component: Drive and Pool Management Affected Versions: 3.0.x, 3.1.x	Major
PWX-37283	A storageless node did not transition into a storage node after a restart if it initially became storageless due to infrastructure errors unrelated to Portworx. User Impact: These errors caused the node to have attached drives that it was unaware of, preventing the node from recognizing that it could use these drives during the transition process. Resolution: when a storageless node attempts to become a storage node, it checks for any attached drives that it previously did not recognize. Using this information, the storageless node can now correctly decide whether to restart and transition into a storage node. Component: Drive and Pool Management Affected Versions: 3.1.x, 3.0.x	Major
PWX-38760	On a node with existing FlashBlade volumes mounted via NFS using a DNS/FQDN endpoint, if Portworx received repeated requests to mount the same FlashBlade volume on the same mount path but using an IP address instead of the FQDN, Portworx returned an error for the repeated requests. User Impact: Pods were stuck in the ContainerCreating state. Resolution: Portworx has been updated to recognize and return success for such repeated requests when existing mount points are present. Components: Volume Management Affected Versions: 3.1.x, 3.0.x, 2.13.x	Major
PWX-37614	When a Portworx volume with volumeMode=Block was created from a StorageClass that also had fs or fsType specified, Portworx incorrectly attempted to format the raw block volume with the specified file system. User Impact: Users were unable to use a common StorageClass for creating both block and file volumes. Resolution: Portworx now allows the creation of raw block PVCs even if fs or fsType parameters are specified in the StorageClass. Components: Volume Management Affected Versions: 3.1.2	Major
PWX-37282	HA-Add and HA-level recovery failed on volumes with volume-affinity VPS, as the volume-affinity VPS restricted pool provisioning to certain nodes. User Impact: Users experienced issues such as volumes losing HA after node decommission or HA-Add operations failing. Resolution: The restriction of volume-affinity VPS has been relaxed. Portworx now prioritizes pools that match VPS labels but will select secondary candidate pools under specific conditions, such as during HA increases and when the volume carries the specified VPS labels. This change does not affect VPS validity. Components: Storage Affected Versions: 3.1.x, 3.0.x	Major
PWX-38539	The Autopilot config triggered multiple rebalance audit operations for Portworx processes, which overloaded Portworx and resulted in process restarts. User Impact: Users saw alerts indicating Portworx process restarts. Resolution: Portworx now combines multiple rebalance audit triggers into a single execution, minimizing the load on Portworx processes and reducing the likelihood of restarts. Components: Storage Affected Versions: 3.1.2.1	Major
PWX-38681	If there were any bad mounts on the host, volume inspect calls for FlashArray Direct Access volumes would take a long time, as df -h calls would hang. User Impact: Users experienced slowness when running pxctl volume inspect <volId>. Resolution: Portworx now extracts the FlashArray Direct Access volume dev mapper path and runs df -h only on that specific path. Components: CLI and API Affected Versions: 3.1.x, 3.0.x	Major
PWX-37799	Portworx restarted when creating a cloud backup due to a KVDB failure. User Impact: If a cloud backup occurred during a KVDB failure, Portworx would unexpectedly restart. Resolution: The nil pointer error causing the restart has been fixed. Now, Portworx raises an alert for backup failure instead of unexpectedly restarting. Components: Cloudsnaps Affected Versions: 3.1.x, 3.0.x	Major
PWX-39080	When the Kubernetes API server throttled Portworx requests, in certain scenarios, a background worker thread would hold a lock for an extended period, causing Portworx to assert and restart. User Impact: Portworx asserted and restarted unexpectedly. Resolution: The Kubernetes API calls from the background worker thread have been moved outside the lock's context to prevent the assert. Components: KVDB Affected Versions: 3.2.0	Major
PWX-37589	When Azure users attempted to resize their drives, Portworx performed an online expansion for Azure drives, which did not align with Azure's recommendation to detach drives of 4 TB or smaller from the VM before expanding them. User Impact: Azure drives failed to resize and returned the following error: Message: failed to resize cloud drive to: 6144 due to: compute.DisksClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="BadRequest" Message="Disk of size 4096 GB (<=4096 GB) cannot be resized to 6144 GB (>4096 GB) while it is attached to a running VM. Please stop your VM or detach the disk and retry the operation Resolution: Portworx now detaches drives of 4 TB or smaller before performing pool expansion, instead of attempting online expansion. Components: Drive & Pool Management Affected Versions: 3.0.x,3.1.x	Minor
PWX-36683	Portworx failed to resolve the correct management IP of the cluster and contacted the Telemetry system using an incorrect IP/port combination. This issue caused the pxctl status command output to result in Telemetry erroneously reporting as Disabled or Degraded. User Impact: Telemetry would sometimes appear to be unhealthy even when it was functioning correctly. This could lead to confusion and misinterpretation of the system's health status. Resolution: The issue was resolved by fixing the logic that chooses the management IP, ensuring that Portworx correctly resolves the management IP of the cluster. This change prevents the system from using the wrong IP/port combination to contact the Telemetry system, thereby ensuring accurate reporting of Telemetry status. Components: Telemetry & Monitoring Affected Versions: 3.0.x,3.1.x	Minor

Known issues (Errata)

Issue Number	Issue Description	Severity
PD-3505	EKS users may encounter issues installing Portworx on EKS version 1.30. This version requires the Amazon Linux 2023 (AL2023) kernel, which, in turn, enforces IMDSv2 by default Workaround: Configure IMDSv2 as optional on all EC2 instances in the node group where Portworx will be installed. If you have already attempted the installation and received an error such as preflight check failed for StorageCluster >[namespace]/[storage_cluster_name]: env variable AWS_ZONE is not set, complete step 1, delete the existing StorageCluster, and then reapply the configuration. Components: Install Affected Versions: 3.0., x, 3.1.x	Critical
PD-3329	Provisioning of KubeVirt VM fails if the bootOrder is not specified for the VM disks and the first disk is not a PVC or a DataVolume. Workaround: Specify the bootOrder in the VM spec or ensure that the first disk is a PVC or a DataVolume. Components: KVDB Affected Versions: 3.1.3	Major
PD-3324	Portworx upgrades may fail with Unauthorized errors due to the service account token expiring when the Portworx pod terminates in certain Kubernetes versions. This causes API calls to fail, potentially leading to stuck Kubernetes upgrades. Workaround: Upgrade the Portworx Operator to version 24.2.0 or higher, which automatically issues a new token for Portworx. Components: Install & Uninstall Affected Versions: 3.1.1, 3.2.0	Major
PD-3412	A Kubernetes pod can get stuck in the ContainerCreating state with the error message: MountVolume.SetUp failed for volume "<PV_NAME>" : rpc error: code = Unavailable desc = failed to attach volume: Volume: <VOL_ID> is attached on: <NODE_ID>, where NODE_ID is the Portworx NODE ID of the same node where the pod is trying to be created. Workaround: Restart the Portworx service on the impacted node. Components: Volume Management Affected Versions: 3.2.0	Major
PD-3408	If you have configured IOPS and bandwidth for a FlashArray Direct Access volume, and that volume is snapshotted and later restored into a new volume, the original IOPS and bandwidth settings are not honored. Workaround: Manually set the IOPS and bandwidth directly on the FlashArray for the restored volume. Components: Volume Management Affected Versions: 3.1.4, 3.2.0	Major
PD-3434	During node decommission, if a node is rebooted, it can enter a state where the node spec has been deleted, but the associated cloud drive has not been cleaned up. If this node is recommissioned, the Portworx reboot fails because both the previous and current drivesets are attached to the node.Workaround: Unmount and detach the driveset. Delete the previous cloud drive, if still present. Components: Drive & Pool Management Affected Versions: 3.2.0	Major
PD-3409	When a user create a journal device as a dedicated cloud drive and create the storage pool using the pxctl sv add-drive command, the cloud drives are not automatically deleted when the storage pool is deleted. Workaround: Manually remove the drives after deleting the pool. Components: Drive & Pool Management Affected Versions: 3.2.0	Major
PD-3416	When you change the zone or any labels on an existing Portworx storage node with cloud drives, Portworx may fail to start on that node. If the labels are changed, the driveset associated with the old zone might become orphaned, and a new storage driveset may be created. Workaround: To change topology labels on existing storage nodes, contact Portworx Support for assistance. Components: Drive & Pool Management Affected Versions: 3.2.0	Major
PD-3496	For Portworx installation, using FlashArray Direct Access, without a Realm specified. If the user clones a volume that is inside a FlashArray pod and clones it to a new volume that is not in a FlashArray pod, the cloned volume appearsto be bound but might not be attachable. Workaround: Include the parameter pure_fa_pod_name: "" in the StoargeClass of the cloned volumes. Components: Drive & Pool Management Affected Versions: 3.2.0	Major
PD-3494	In a vSphere local mode installation environment, users may encounter incorrect alerts stating that cloud drives were moved to a datastore lacking the expected prefix (e.g., local-i).when performing Storage vMotion of VMDKs associated with specific VMs. Workaround: This alert can be safely ignored. Components: Drive & Pool Management Affected Versions: 3.2.0	Major
PD-3365	When you run the drop_cache service on Portworx nodes, it can cause Portworx to fail to start due to known issues in the kernel. Workaround: Avoid tunning drop_cache service on Portworx nodes. Components: Storage Affected Versions: 3.1.4, 3.2.0	Minor