Portworx Fusion Controller Release Notes

1.1.0

October 06, 2026

New Features

• Hot Plug Disks for KubeVirt VMs
  Portworx Fusion Controller now supports hot attachment and detachment of Fusion-backed disks for running KubeVirt VMs without restarting the VMs. The controller automatically updates the associated FusionWorkload and provisions storage on the appropriate FlashArray. For more information, see Hot plug disks for a KubeVirt VM.

• Precreated PVC Support for KubeVirt VMs
  Portworx Fusion Controller now supports using precreated Fusion-backed PVCs with KubeVirt VMs, allowing storage to be provisioned independently of VM creation and managed separately throughout its lifecycle. The controller tracks the VM storage through a FusionWorkload and provisions the volume on the appropriate FlashArray based on the associated Fusion preset. For more information, see Create a KubeVirt VM using a pre-created PVC.

• Fusion-Backed Storage for Kubernetes Workloads
  Portworx Fusion Controller now supports provisioning Fusion-backed persistent storage for Kubernetes StatefulSet and Deployment workloads. The Fusion Controller provisions and manages FlashArray storage based on the Fusion preset associated with the StorageClass, applying predefined QoS, placement, and replication policies to each workload. For more information, see Provision storage for container workloads.

Known issues (Errata)

Issue Number	Issue Description	Severity
PWX-55670	During burst workload creation, a Fusion volume creation request can time out after Fusion has already created the volume. If Kubernetes retries the request before the webhook records the result, Fusion can create another volume because volume creation is not idempotent. Repeated retries can therefore create multiple Fusion volumes for a single PVC. User Impact: Multiple Fusion volumes can be created for a single PVC, while only one volume is associated with the PVC. The additional volumes remain orphaned and continue to consume storage capacity. Workaround: No workaround. Components: IX - Fusion-Intg Affected Versions: 1.1.0	Major

1.0.0

April 06, 2026

Portworx Fusion Controller provides a unified, application-aware platform that combines Fusion’s fleet-level management with Portworx’s Kubernetes-native data services. Portworx Fusion Controller connects Kubernetes clusters to Fusion fleets, enabling access to storage presets and workloads. It automates configuration management, provisions volumes using Fusion APIs, and applies quality-of-service and replication policies through standard Kubernetes PVC and StorageClass workflows.

Known issues (Errata)

Issue Number	Issue Description	Severity
PWX-51741	When the combined <namespace>-<vm-name> used by Fusion exceeds 27 characters (resulting in a workload name longer than the FlashArray Volume Group 63-character limit after the vm- prefix and UID are appended), Fusion truncates the name and might drop the UID suffix. This causes naming collisions and places the Fusion CR in a Creating or Provisioning state; the corresponding datavolume(s) stay Pending and the workload never completes provisioning. User Impact: Virtual machines fail to provision and remain stuck in the Provisioning or Creating state. The associated DataVolumes and PVCs stay in a Pending state, preventing the workload from becoming operational. This blocks VM creation, migration, and automation workflows. Workaround: Cap workload names at 39 characters using the formula vm-<namespace-vmname>-<8char-uid>, preserving an 8-char UID suffix and truncating the namespace-vmname portion so VG names never exceed the FlashArray 63-character limit and uniqueness is preserved. Components: IX - Fusion-Intg Affected Versions: 1.0.0	Minor
PWX-52530	Fusion MutatingAdmissionWebhook requests can fail due to OpenShift’s fixed 13-second timeout limit. When the webhook makes synchronous calls to the Fusion backend during VM or volume operations, delays in backend response can cause the request to exceed this limit and be terminated. User Impact: VM and volume operations, such as attaching volumes, can fail or be aborted under load when the Fusion backend does not respond within the timeout window. In some cases, failures may not be clearly reported, making troubleshooting difficult. Workaround: Wait for Fusion API load to decrease, then retry the failed operation. The operation typically succeeds once the backend responds within the timeout window. Components: IX - Fusion-Intg Affected Versions: 1.0.0	Minor