Portworx Enterprise Release Notes
3.6.1
June 01, 2026
To install or upgrade Portworx Enterprise to version 3.6.1, ensure that your cluster meets all system requirements and is running Operator 26.2.0 or later, Stork 26.3.0 or later, and one of the supported kernels.
New Features
-
Support for installing Portworx Enterprise on Azure Gardener Kubernetes
Portworx Enterprise supports installation on Azure Gardener shoot clusters, extending enterprise-grade cloud-native storage to Kubernetes environments managed by Gardener on Azure. You can install Portworx Enterprise on a Gardener shoot cluster by using a Portworx Operator and StorageCluster specification generated through Portworx Central or by using the Portworx Helm chart.
For more information, see Installation on an Azure Gardener Cluster. -
Workload identity support for Azure Kubernetes Service and Azure Gardener
Portworx Enterprise now supports Workload Identity on Azure Kubernetes Service (AKS) and Azure Gardener clusters. This enhancement allows Portworx pods to authenticate with Azure by using federated user-assigned managed identities instead of long-lived service principal credentials, improving security and simplifying credential management.
For more information, see Workload identity for cloud operations in Portworx. -
Automatic periodic diagnostics collection
Portworx Enterprise supports automatic periodic collection of pod-level diagnostics. WhenclusterDiagsis enabled in theStorageClusterspec, the Portworx Operator automatically creates aPortworxDiagcustom resource (CR) every four hours and collects logs and YAML manifests for all Portworx pods. The collected diagnostics are uploaded to Pure1 if telemetry is enabled. The Operator automatically cleans up completed diagnostic CRs when it creates the next scheduled CR, and removes periodic pod diagnostic tarballs older than two hours from/var/coreson each node.
For more information, see Periodic diagnostics collection usingPortworxDiagCR.
Fixes
| Issue Number | Issue Description | Severity |
|---|---|---|
| PWX-54506 | Portworx node restarts could take significantly longer than expected on systems using mdadm 4.5. An upstream regression in mdadm 4.5 caused additional device scanning during RAID probing, increasing Portworx restart times from approximately 1–2 minutes to 5–9 minutes per node.User Impact: Portworx restarts could exceed configured restart or upgrade timeouts, causing automated operations and tests to fail. Resolution: Portworx Enterprise now supports mdadm 4.6, that includes the upstream fix for the RAID probing regression. This restores normal Portworx restart times and prevents timeout-related failures during restart and upgrade operations.Components: Drive & Pool Management Affected Versions: 3.6.0 and 3.6.0.1 | Critical |
| PWX-53760 | Portworx nodes encountered a condition where excessive CloudSnap entries accumulate in the KVDB cache due to incomplete cleanup. This leads to increased time spent enumerating CloudSnap entries, which can delay snapshot operations and trigger stuck requests. User Impact: In affected environments, multiple VMs may experience errors and become unresponsive or crash (BSOD). Portworx nodes may restart, and storage operations such as snapshots can stall. This can impact multiple VMs simultaneously and degrade overall cluster stability. Resolution: Portworx Enterprise now removes KVDB cache entries when the corresponding records are deleted from KVDB. This prevents excessive cache growth, reduces enumeration time, and avoids stuck requests during snapshot operations, ensuring stable snapshot processing and improved node stability. Components: Cloudsnaps Affected Versions: 3.6.0 and 3.6.0.1 | Critical |
| PWX-53892 | Portworx installation fails in environments where component drives report an optimal_io_size of 0xFFFE00 (16,773,120).User Impact: This causes the md array to expose an optimal_io_size of 4,293,918,720 (~4 GB) due to overflow during queue_limits_stack_bdev() LCM calculations. As a result, XFS formatting can fail. Resolution: Portworx now formats component devices using a fixed stripe size of 1 MiB. This prevents XFS format failures caused by excessively large optimal_io_size values.Components: Data Plane Affected Versions: 3.6.0 and 3.6.0.1 | Critical |
| PWX-51924 | Pod creation can get stuck in the ContainerCreating state due to a mount failure with the error Sentinel mount already exists but requires cleanup for volume. This occurs in rare circumstances when the server believes the client is no longer using the mount, which leaves a stale mount behind. User Impact: Pods remain stuck in the ContainerCreating state because the volume cannot be mounted. Subsequent mount attempts fail due to the presence of stale sentinel mounts from previously terminated pods. This can block application startup and require manual intervention. Resolution: Portworx now detects stale sentinel mounts during Sharedv4 volume mount operations and cleans them up before retrying the mount. This allows subsequent mount attempts to complete successfully. Components: Shared Volume (NFS) Affected Versions: 3.6.0 | Critical |
Known issues (Errata)
| Issue Number | Issue Description | Severity |
|---|---|---|
| PWX-49896 | On Azure Gardener clusters, Portworx nodes can be automatically deleted when a filesystem on a Portworx device is remounted as read-only during workloads such as SharedV4 testing. Gardener’s Machine Controller Manager (MCM) detects the User Impact: Unexpected node replacement can cause repeated node churn, quorum loss, Portworx instability, and application disruption. Workaround: Update the Gardener Shoot worker pool configuration to make node replacement less aggressive:
Components: Shared Volume (NFS) | Major |
| PWX-53236 | Workload Identity is not currently supported for Portworx on ARO clusters. ARO applies Azure Deny Assignments to the managed resource group, which block VM write operations for workload identities. As a result, Portworx cannot PATCH worker VMs during startup and fails with User Impact: Portworx pods fail to start on ARO clusters configured with Workload Identity, even when the required roles and permissions are assigned. Workaround: No workaround. Components: Operator | Major |
| PWX-53881 | Cloud snapshots may remain in the delete queue and delete very slowly, or stop deleting, when the S3-compatible object store reaches its configured quota. Portworx must first update the cloud snapshot metadata status to User Impact: Cloud snapshots can accumulate in the delete queue and may not be removed from the backend object store. This can fill the object store quota and block new cloud snapshots from being created. Workaround: Pause all cloud snapshot schedules and increase the object store quota slightly to allow Portworx to update cloud snapshot metadata and resume deletion. After deletion catches up and sufficient space is available, resume the snapshot schedules. Components: Cloudsnaps | Major |
| PWX-54330 | In multi-zone FACD CSI topology deployments, Portworx does not currently support using User Impact: In multi-zone FACD topology deployments, only a subset of expected storage nodes may be provisioned. Nodes in zones where the selected FACD pod or realm is unavailable can fail storage initialization and come up as storageless nodes. Workaround: Do not specify both Components: Drive & Pool Management | Major |
| PWX-54665 | During Kubernetes upgrades on Gardener clusters, Portworx node drains can get stuck due to PDB deadlocks when multiple storage nodes are drained in parallel. This can occur because Gardener rolls MachineDeployments per zone in parallel, while Azure Premium_LRS disks require the old VM to terminate before the disk can attach to the replacement VM. User Impact: The Gardener shoot upgrade can remain stuck in Reconcile/Error state, with old nodes cordoned and Machines stuck in Terminating because node drain cannot complete. Workaround: Set Components: Operator | Major |
| PWX-51736 | On nodes using PX-StoreV1 datastore storage pools, a Portworx service restart can occasionally leave the node in a User Impact: Affected nodes remain in a Workaround: Perform a node maintenance cycle and restart Portworx to allow the pool to mount successfully. Alternatively, manually run a PX-StoreV1 datastore device scan against all multipath device paths to rediscover the devices and recover the pool. Components: Storage | Minor |
3.6.0.1
April 22, 2026
To install or upgrade Portworx Enterprise to version 3.6.0.1, ensure that your cluster meets all system requirements and is running Operator 26.1.0 or later, Stork 26.2.0 or later, and one of the supported kernels.
Fixes
| Issue Number | Issue Description | Severity |
|---|---|---|
| PWX-53355 | The Portworx driver has a race condition during new block device export when there is concurrent I/O on the same device. This can lead to a kernel deadlock, preventing the system from completing the virtual block device export, processing incoming I/O, or processing I/O on the newly exported device. User Impact: In rare scenarios, this condition can cause Portworx nodes to report storage as down or fail to start correctly. The condition is unrecoverable without a node reboot, impacting cluster stability. Resolution: The Portworx driver now handles concurrent block device export and I/O operations correctly, preventing the race condition and ensuring reliable device initialization and I/O processing. Components: Telemetry & Monitoring Affected Versions: 3.5.1, 3.5.2, and 3.6.0 | Critical |
3.6.0
April 06, 2026
To install or upgrade Portworx Enterprise to version 3.6.0, ensure that your cluster meets all system requirements and is running Operator 26.1.0 or later, Stork 26.2.0 or later, and one of the supported kernels.
New Features
-
Secure Boot Support for Portworx Enterprise
Portworx Enterprise supports systems with UEFI Secure Boot enabled. Secure Boot allows only signed and trusted kernel modules to load during system startup, adding an extra layer of security by validating module authenticity.
Portworx Enterprise kernel modules are signed and compatible with Secure Boot. To run Portworx on Secure Boot-enabled systems, you must manually enroll the Portworx Secure Boot signing certificate into the system’s Machine Owner Key (MOK) list.
For more information, see Secure Boot for Portworx Enterprise. -
Vault Integration for FlashArray and FlashBlade Credentials
Portworx Enterprise supports storing Pure Storage FlashArray and FlashBlade credentials in Vault. Instead of providing credentials directly in configuration files, you can securely create and manage them as secrets in Vault.
When deploying Portworx Enterprise with FlashArray, create a Vault secret that contains the credentials and reference it during installation. Portworx Enterprise retrieves the credentials securely at runtime, improving security and centralizing credential management.
For more information, see Add FlashArray Configuration to a Secret Store Provider. -
Support for Multiple Secrets Providers
Portworx Enterprise supports configuring multiple secrets providers within a single deployment. You can assign a different secrets provider to each feature, enabling finer-grained control over how and where sensitive data is stored.
For example, you can useKubernetes Secretsfor volume encryption while usingVaultto store cloud provider credentials such as vSphere credentials or FlashArray access tokens.
For more information, see Configure Multiple Secrets Providers. -
Azure ARM Lock Integration for Managed Disks
Portworx Enterprise integrates with Azure Resource Manager (ARM) locks to protect Azure-managed disks (cloud drives) in AKS deployments. When disk locking is enabled, Portworx Enterprise automatically applies aCanNotDeletelock to each disk it provisions, preventing accidental or external deletion while allowing read and update operations.
For more information, see Locking Azure Cloud Drives on AKS Clusters. -
Volume Tagging Support for FADA and FACD
Portworx Enterprise supports FlashArray Cloud Drives and Direct Access volumes tagging that enables custom metadata on volumes that allows easier filtering and sorting of volumes, and enables adding more identifying information to them.
For more information, see Custom Disk Tags. -
Dynamic Resync Bandwidth Control
Portworx Enterprise supports dynamic control of resync and replica-add bandwidth. You can configure a maximum bandwidth limit to prevent resync traffic from impacting application I/O. Portworx Enterprise prioritizes application traffic and dynamically adjusts resync usage based on load, ensuring it never exceeds the configured threshold while optimizing resync completion time.
For more information, see Dynamic Resync Bandwidth Control.
Early Access Features
-
Garden Linux and Gardener Support
Portworx Enterprise introduces support for Garden Linux and Gardener environments. This enhancement extends Portworx Enterprise support to Kubernetes environments running on Garden Linux and Gardener, improving deployment flexibility and ecosystem alignment. -
Integrate Portworx Enterprise with Everpure Fusion
Portworx Enterprise supports integration with Everpure Fusion, combining Everpure Fusion’s fleet-level management with Portworx’s Kubernetes-native data services.
For more information, see Portworx Fusion Controller Documentation. -
Readahead Support for Sequential Read Workloads
Portworx Enterprise supports readahead to optimize sequential read workloads. Readahead detects sequential read I/O patterns and prefetches data from disk into memory before the application requests it. Serving data from memory reduces disk and network overhead, improves read throughput and IOPS, and lowers read latency.
For more information, see Readahead. -
New and Improved Implementation of Direct Access Volumes with PX-CSI Integration
Portworx Enterprise integrates with PX-CSI to orchestrate FlashArray Direct Access and FlashBlade Direct Access Volumes' operations.
For more information, see Integrate PX-CSI into Portworx Enterprise.
Direct Availability Features
- Kube Datastore (KDS) and Dynamic Pools for Replica 1 Volumes
Portworx Enterprise introduces Kube Datastore (KDS), a distributed datastore that provides highly available, resilient, and efficient datastores for shared storage backend (SAN) and cloud drives. KDS enables clusters to scale automatically within seconds without downtime or performance degradation, while maintaining high availability and resiliency. For more information, see Kube Datastore.
Portworx Enterprise supports KDS dynamic pools for volumes withrepl=1in environments using FlashArray Cloud Drives (FACD) and PX-StoreV2. KDS dynamic storage pools are designed for shared storage backend (SAN) environments and leverages the capabilities of the underlying FlashArray volumes to deliver superior data reduction, data protection, and resiliency.
For more information, see Dynamic Pools for Volumes with Replication Factor 1.
Improvements
| Improvement Number | Improvement Description | Component |
|---|---|---|
| PWX-43116 | Portworx Enterprise now logs detailed error information when node diagnostics fail due to Portworx-related issues, improving troubleshooting and overall user experience. The diagnostics collection has been enhanced to include additional Kubernetes objects related to storage, workloads, configuration, networking, versioning, controller state, and secrets. Diagnostics collection operates in a read-only mode against the Kubernetes API. Portworx Enterprise also automatically redacts all collected data before persisting or sharing the diagnostics bundle, ensuring that sensitive information such as secrets, tokens, keys, and certificates is masked or removed. For more information, see On-demand diagnostics using PortworxDiag custom resource. | Telemetry |
| PWX-43455 | Portworx Enterprise has enhanced Grafana dashboards to improve observability and troubleshooting:
| Monitoring |
| PWX-48856 | Portworx Enterprise now enables KVDB TLS by default for all installations, improving cluster security out of the box. Specifications generated through Portworx Central automatically include KVDB TLS, ensuring that cluster metadata communication is encrypted without requiring additional configuration. This enhancement eliminates the need for manual TLS enablement and helps meet security requirements by default. | KVDB |
| PWX-52254 | Portworx Enterprise now provides improved stability during high-load KVDB operations by increasing the default internal token timeout from 3 minutes to 15 minutes. This reduces token expiration during large-scale or delayed KVDB operations and prevents unnecessary Portworx restarts. | KVDB |
Fixes
| Issue Number | Issue Description | Severity |
|---|---|---|
| PWX-37188 | During CloudSnap backup or restore operations, CloudSnap status tracking could cause Portworx to crash with concurrent map iteration and map write error.User Impact: Portworx could restart when multiple CloudSnap backup or restore operations run at the same time as status queries. Resolution: Portworx Enterprise now correctly synchronizes access to CloudSnap status data to prevent concurrent access conflicts during backup, restore, and status query operations. Components: Storage Affected Versions: 3.0.4 | Minor |
| PWX-44589 | The KVDB dump rotation process had inconsistencies in its retention logic. Monthly grouping was based on a rolling 31-day window rather than calendar months, and retention kept older dumps instead of the most recent ones. Additionally, dump files were retained for up to one year, which could result in excessive storage consumption. User Impact: KVDB backup dump files could accumulate unnecessarily, consuming significant disk space and making retention behavior difficult to predict. Resolution: Portworx Enterprise now improves KVDB dump rotation as follows:
Components: KVDB Affected Versions: 3.2.0 | Minor |
| PWX-48515 | Lock contention in the in-memory KVDB (kv_mem.go) implementation caused performance bottlenecks during read-heavy operations. Several functions, including the /status handler and periodic liveness and readiness probes, relied on exclusive locks. This led to unnecessary contention and, in some environments, contributed to frequent container restarts due to probe timeouts.User Impact: In environments with high volume and snapshot activity, Portworx containers could experience increased latency during health checks. This could result in liveness or readiness probe failures and frequent container restarts. Resolution: Portworx Enterprise now replaces exclusive mutex locks in kv_mem.go with RWMutex. This allows multiple read operations to execute concurrently while still preserving safe write access. This significantly reduces lock contention for common read-heavy operations, improving responsiveness and stability during health checks, volume operations, and snapshot workflows.Components: Control Plane Affected Versions: 3.3.0 | Minor |
| PWX-48795 | In certain error scenarios, NFS thread handling did not log sufficient diagnostic information. Some retry failures when updating NFS threads were not logged consistently. Additionally, log messages related to thread updates were suppressed by a 12-hour threshold, limiting visibility. When the error Cannot allocate memory occurred, system memory information was not included in the logs, making troubleshooting more difficult.User Impact: Administrators had limited visibility into NFS thread update failures and memory-related issues. This made it harder to diagnose NFS overload conditions and related performance problems. Resolution: Portworx Enterprise improves logging in the NFS thread handling component. Thread update failures are now logged consistently, including during retries. The 12-hour log suppression threshold has been adjusted to improve visibility. When a Cannot allocate memory error occurs, Portworx Enterprise now logs system memory information (for example, the output of free -h) to assist with troubleshooting.Components: Control Plane, Shared Volumes Affected Versions: 3.4.0 | Minor |
| PWX-49349 | When Portworx Enterprise was configured with separate data and management network interfaces, and the management interface was assigned a link-local IP address (for example, 169.254.0.2/17), some KubeVirt VMs using Sharedv4 volumes could enter a Paused state during Portworx Enterprise or platform upgrades. This issue did not occur when the data interface used a link-local IP address. It also did not affect KubeVirt VMs using Shared Raw Block volumes. User Impact: During Portworx Enterprise or platform upgrades, a subset of KubeVirt VMs using Sharedv4 volumes could transition to a Paused state and require a manual restart to recover. Resolution: Portworx Enterprise now correctly handles link-local IP addresses configured on either the data or management interfaces. KubeVirt VMs using Sharedv4 volumes no longer enter a Paused state during upgrades when link-local IP addresses are present. Components: Shared Volume (NFS) Affected Versions: 3.4.1 | Minor |
| PWX-49486 | New nodes fail to join a cluster that was migrated from a DaemonSet-based deployment to the Operator when the original cluster name contained underscores (_). In such setups, the StorageCluster name used hyphens (to comply with Kubernetes naming constraints), while the original cluster name with underscores was preserved in the portworx.io/cluster-id annotation. This mismatch caused node identity generation to fail during cluster join.User Impact: New nodes were unable to join the cluster after migration, preventing cluster expansion or node replacement. Resolution: Portworx Enterprise now correctly identifies the StorageCluster by additionally validating the portworx.io/cluster-id annotation when resolving cluster identity. This ensures new nodes can successfully join the cluster even when the STC name differs from the original cluster name.Components: Control Plane Affected Versions: 3.5.2 | Minor |
| PWX-51883 | Portworx Enterprise reported incorrect usage metrics for Shared Raw Block (RWX Block) volumes. Metrics such as px_volume_usage_bytes and px_volume_fs_usage_bytes do not reflect actual filesystem usage because the filesystem resides inside the guest VM, which Portworx Enterprise cannot inspect.User Impact: Capacity-related alerts for Shared Raw Block volumes could be inaccurate and repeatedly triggered, even when the actual filesystem usage inside the VM was within limits. Resolution: Portworx Enterprise no longer generates capacity-full alerts for Shared Raw Block volumes. This prevents false alerts for volumes where filesystem usage cannot be accurately determined by Portworx Enterprise. Components: Control Plane Affected Versions: 3.5.2 | Minor |
| PWX-52148 | In earlier Portworx Enterprise versions, PX-StoreV2 could let the backend device optimal I/O size override the user-specified maximum pool size. As a result, pools created with max_pool_size_tb did not always use the configured limit consistently.User Impact: Pools could be created with a maximum pool size larger than the value specified in max_pool_size_tb, which resulted in inconsistent pool sizing across nodes.Resolution: Portworx now ignores the backend device optimal I/O size when calculating the maximum pool size and honors the user-specified max_pool_size_tb value consistently for all pools.Components: Control Plane Affected Versions: 3.5.2 | Minor |
| PWX-52399 | During pool resize, a node can enter pool maintenance mode. If an encrypted volume is attached at that time, encrypted volume cleanup can stall because the storage service is unavailable. User Impact: The node can get stuck in pool maintenance mode, and users must exit maintenance mode from another node and reboot the affected node to recover. Resolution: Portworx Enterprise now skips encrypted volume cleanup during pool maintenance. This prevents nodes from getting stuck during pool maintenance triggered by pool resize. Components: Drive & Pool Management Affected Versions: 3.6.0 | Minor |
| PWX-52411 | Encrypted volumes created by Portworx Enterprise did not support space reclamation using fstrim because encrypted device mappings were created without enabling discard support.User Impact: Encrypted volumes could not reclaim unused space after data deletion. As a result, storage usage could remain higher than expected, and AutoFSTrim operations could fail and generate alerts.Resolution: Portworx Enterprise now enables discard support for encrypted volumes to allow fstrim operations. For encrypted volumes created in Portworx Enterprise 3.5.x or earlier releases, detach and reattach the volumes once after upgrading your cluster to 3.6.0 or later, to apply the fix and restore fstrim functionality.Components: Control Plane Affected Versions: 3.5.2 | Minor |
| PWX-52744 | On every Portworx Enterprise restart, a false SvMotionMonitoringSuccess alert could be generated even when no Storage vMotion operation occurred.User Impact: Users could see unnecessary SvMotionMonitoringSuccess alerts after a Portworx Enterprise restart, which could cause confusion even though no Storage vMotion operation was performed.Resolution: Portworx Enterprise now prevents false SvMotionMonitoringSuccess alerts during restart when no Storage vMotion operation has occurred.Components: Control Plane Affected Versions: 3.6.0 | Minor |
Known issues (Errata)
| Issue Number | Issue Description | Severity |
|---|---|---|
| PWX-47702 | If Portworx Enterprise restarts during volume creation, the volume can be left in an intermediate non-idempotent state that prevents the operation from recovering automatically, which causes the PVC to remain in a Pending state. User Impact: The PVC does not bind, and pods that reference it remain stuck waiting for storage. Workaround: Delete the affected PVC (and the corresponding Portworx volume, if it remains present) and recreate the PVC to retry provisioning after Portworx stabilizes. Components: Shared Volume (NFS) | Minor |
| PWX-47913 | On a storageless node, KVDB can fail to bootstrap with the error: User Impact: KVDB failover or rebalance to the affected storageless metadata node can fail. As a result, the cluster can remain under-replicated for KVDB members, and the affected node can be reported incorrectly under nodes using local drives even though it is a storageless node. Workaround: Restart Portworx on the affected storageless node. This clears the stale state and allows KVDB provisioning to succeed. Components: Volume and Drive Management | Minor |
| PWX-51772 | During continuous pool failovers, a pool failover plan can fail after deactivation completes if the source node comes back online while the failover plan is still in progress. In this case, Portworx Enterprise attempts to resume the same plan and try to lock the same volumes again, even though those volume create locks are already held by the cluster coordinator. This lock conflict can cause the plan to transition to a failed state. User Impact: Pool failover or rebalance operations can fail and leave plans in a Workaround: Retry the failed pool failover or pool migration operation. Components: Dynamic Pools | Minor |
| PWX-51808 | Pool expansion can fail if the drives in a pool do not report the same size after a previous expansion attempt only partially completes on the backend. In this condition, Portworx Enterprise detects a size mismatch across the pool drives and marks the resize operation as failed. User Impact: The affected pool can go offline, and subsequent pool expansion attempts can fail with a size mismatch error. This can prevent capacity expansion until all drives in the pool are brought to the same size. Workaround: Manually resize the affected drives on the FlashArray so that all pool drives have the same size, and then retry the pool expansion. Components: Drive & Pool Management | Minor |
| PWX-51866 | When you run a PX Backup (CloudSnap) while a storage pool failover is in progress, the backup for volumes on the moving pool may fail. User Impact: The affected disk backup fails intermittently, which can cause the VM backup job to complete with failures and require a rerun. Workaround: Retry the backup after the pool failover completes. Components: Dynamic Pools | Minor |
| PWX-51924 | Pod creation can get stuck in the User Impact: Pods remain stuck in the Workaround: Manually unmount the sentinel mount to clean up the stale mounts on the affected node and restart the pod. In some cases, restarting Portworx on the node can also clear stale mount state. Components: Shared Volume (NFS) | Minor |
| PWX-52266 | After a rebalance or pool migration failure, a storage pool can remain offline on the source node. If you restart the source node or attempt a maintenance cycle, Portworx can fail to initialize the pool with an error. User Impact: The affected pool stays offline, and the source node might fail to recover through a maintenance cycle. This can leave the node in a degraded state until the pool conflict is cleared. Workaround: Do not use a maintenance cycle to recover the affected pool. Instead, schedule a new pool migration for the offline pool. This can recover the pool and clear the conflict. Components: Dynamic Pools | Minor |
| PWX-52422 | On a storageless node labeled with User Impact: KVDB replacement can fail on the affected metadata node, which can stall operations that depend on successful KVDB failover. In migration scenarios, this can cause node drain jobs to fail or remain pending and can delay migration completion. Workaround: Restart Portworx on the affected node where KVDB failover does not complete. Components: KVDB | Minor |
| PWX-52423 | During a Portworx upgrade or NFS server restart, a SharedV4 (service) hotplug volume mount can become stale during server failover or restart. This can result in stale NFS file handles and cause KubeVirt live migration to fail. User Impact: Live migration of VMs that use SharedV4-backed hotplug volumes can fail. The affected hotplug disks can become inaccessible until recovery, disrupting VM mobility operations. Workaround: Restart the virtual machine to remount the affected hot-plug volumes and clear the stale NFS file handle condition. Components: Shared Volume (NFS) | Minor |
| PWX-52427/PWX-52921 | Portworx depends on a node being marked User Impact: Unintended pool failovers can occur when a node is cordoned while the MCP is inaccurately reported as updating. This can lead to unnecessary pool movement and potential disruption. Failover occurs only when the node is marked unschedulable (cordoned). Workaround: No workaround. Components: Dynamic Pools | Minor |
| PWX-52679 | When a large number of VMs are started simultaneously on PX-StoreV1 clusters, KubeVirt VMs with hotplug volumes may fail to start. This occurs because when multiple VMs are started simultaneously, virt-launcher pods are scheduled first, while hotplug pods remain in a Pending state due to scheduler queue delays and volume enumeration latency. As a result, the VirtualMachineInstance (VMI) times out while waiting for the hotplug pod to be scheduled, causing the VM startup to fail. User Impact: KubeVirt VMs with hotplug volumes may fail to start during bulk operations. This can delay or disrupt large-scale VM deployments, as VMs repeatedly fail and re-enter the scheduling queue, increasing overall startup time and system load. Workaround: Start the VMs in smaller batches of 20 VMs at a time for workloads that use hot-plug disks instead of initiating all VMs simultaneously. Starting more than 20 VMs in a batch can cause some VMs to fail to start due to timeouts resulting from delayed Stork scheduling. Components: Stork & DR | Minor |
| PWX-52863 | During pool expansion on PX-StoreV2, Portworx requires entering pool maintenance mode because online expansion is not supported for PX-StoreV2 or px-cache pools. In this state, when encrypted volumes are present, I/O operations take longer time and Portworx can hit request timeouts such as User Impact: This issue occurs specifically during PX-StoreV2 pool expansion workflows that require maintenance mode. Portworx may restart during the transition, interrupting or delaying the expansion operation. The system typically recovers after the restart, and there is no functional data loss, but the expansion operation may fail and require a retry. Workaround: No workaround. After the restart, Portworx Enterprise typically recovers and the pool expansion operation can be retried. Components: Drive & Pool Management | Minor |