What’s New from Portworx: Advanced AI and VM Capabilities on Kubernetes

VMs, containerized applications, and AI workloads are converging on Kubernetes. Enterprises want one platform underneath all three, not a separate stack for each. Portworx is the modern data platform for that convergence.

This post highlights the technical detail behind our KubeCon NA 2026 announcements.

Kube Datastore: Improved resilience and failover leveraging SAN storage 

Portworx manages data for VMs, containers, and AI workloads on Kubernetes across on-prem, cloud, and edge storage. Because each workload demands different storage requirements depending on where it runs, Portworx introduces Kube Datastore (KDS), now generally available on supported SAN arrays. 

KDS brings the datastore model VM admins already know to Kubernetes. Pools are carved from a shared array, and when a node fails they reattach to a healthy one with no data copy and no replica rebuild. 

KDS is Generally Available (GA)  in Portworx Enterprise 3.7.2 on Everpure FlashArray and Red Hat OpenShift.

Read more in this Kube Datastore GA announcement blog

Pre-Staged Volumes: Accelerate AI inference startup times

Starting an inference engine is more than starting a container. Before it can accept traffic, the engine has to locate model artifacts, load checkpoint files, initialize its runtime, and move weights into GPU memory. For large models the weights alone run to tens or hundreds of gigabytes.

When every new pod downloads those files independently from a remote repository or object store, scale-out is constrained by network bandwidth and storage contention.

Pre-staged volumes avoid the unwanted traffic from repeated downloads from a remote site.  Your pipeline hydrates one source PVC with a versioned model bundle from an approved repository. Portworx distributes equivalent copies across the cluster’s eligible worker nodes and confirms each required copy is ready.  Each subsequent inference pod mounts its local copy for less traffic and faster start-up.

Pre-staged volumes also change how you plan for recovery and upgrades.  When a node fails, the replacement pod can be scheduled on a surviving node that already has a ready copy.  And when a new model revision arrives, you can run a blue/green deployment workflow: stage and validate the new version, distribute it, shift consumers, then retire the previous generation after the rollback window. Pre-staged volumes will be available in early 2027.

Read More in the Portworx for AI blog.

Operations Center: Comprehensive cluster to storage observability, topology, metrics, and alerting

Troubleshooting a storage problem on Kubernetes has usually meant reconstructing it from three partial views: pxctl for cluster health, kubectl for Kubernetes resources, Grafana for performance. The problem was never a shortage of telemetry. It was turning telemetry into something actionable.

The newly introduced Operations Center, brings cluster health, alerts, infrastructure relationships, performance metrics and diagnostics into one in-cluster interface.

• Observability: Portworx UI provides visibility into pool inventory, live migration progress and hyperconvergence state, helping teams monitor storage and virtualization operations through a single interface. 
• Topology: Portworx UI provides a topology map of the cluster across storage nodes, pools, volumes, workloads and virtual machines, with health state on every object and an issue-based view that filters down to only what is affected.
• Intelligent Alerting: Portworx UI provides a single alert view across Portworx and Prometheus alerts, filtered by severity, blast radius or resource type, with every row linking straight into the topology map or a grouped issue.

Read more in this  Operations Center technical blog.

Day-one support for Red Hat OpenShift 5: Adopt the latest OpenShift release with full support from Portworx

Red Hat has launched OpenShift 5. Portworx supports it at general availability, in both Portworx Enterprise and Portworx CSI.

Day-one matters more than it sounds. A platform upgrade that outruns its data layer turns into a stalled project. Teams either hold the upgrade back or run two storage configurations side by side while they wait for support to land. Neither is a good position to be in halfway through moving VMs off VMware.

What carries over is everything underneath. Same storage classes. Same snapshot and backup configuration. Same async and sync DR. Same live migration behavior for VMs on OpenShift Virtualization. If you’ve got a migration program already in flight, the platform upgrade doesn’t mean re-planning the data layer to go with it.

Virtbench 2.0: Open source Modern Virtualization testing and benchmarking tool

Teams moving VM estates to KubeVirt need more than a successful boot to know their platform is ready. They need to understand how it will perform when VMs start together, workloads migrate, storage operations overlap, and nodes fail or require maintenance.

Kubernetes was originally built for apps that run in containers which can spin up in milliseconds and handle failure by simply restarting.  But virtual machines have different operational needs, and standard Kubernetes metrics don’t deliver the insights virtualization experts need. 

Virtbench is the open source, vendor-neutral toolkit we built to help teams establish operational readiness with metrics familiar to virtualization professionals. With version 2.0, Virtbench moves beyond isolated benchmarks toward broader operational validation, adding concurrent mixed-operation testing, expanded migration scenarios, rewritten failure-recovery testing, and a dedicated set of Day 2 operations.

There’s also an optional AI-assisted workflow. You describe a run in plain language and a deterministic planner carries it out. The planner does the necessary cluster math, and every run leaves an auditable record of what the planner decided and why.

Read more in the Virtbench 2.0 blog.

Bring your own backup – Flexibility to protect your workloads with change block tracking

Kubernetes now has an upstream standard for change block tracking (KEP-3314), which allows backup tools to find exactly which data changed since the last backup. 

With Portworx Enterprise 3.8.0, any third-party backup tool that supports the standard can copy only the data that changed instead of the whole volume. That means shorter backup windows and less data moved, especially for large volumes that change little between backups. Teams that have standardized on another backup vendor can keep it and still get efficient incremental backups.

Portworx Backup 3.2.0 also brings the same backup efficiency to other storage vendors that support the standard, such as Ceph block storage and Portworx CSI. Portworx Backup automatically chooses the right backup method for each volume, even for raw block volumes.

Portworx Backup 3.2.0 releases at the end of the week. Portworx Enterprise 3.8.0 and Portworx Backup 3.3.0 are planned for early 2027.

Backup and DR Enhancements: More granular protection and recovery for VMs

Several enhancements have been made to backup and disaster recovery operations with VMs by providing more granular protection controls for failover and recovery and providing more seamless day-to-day backup operations.

Portworx Backup 3.2.0 makes VM recovery more precise with select file restore for Windows VMs, which allows users to restore individual files or folders from a Windows VM backup without a full VM restore, providing parity and a consistent experience for both Windows and Linux VMs. 

Day-to-day VM protection is also easier to plan and more resilient. Admins can see each VM’s disk count and total size when building a backup, so large VMs go on the right schedule without manual sizing. If one VM can’t be restored, the rest of the restore still completes, and admins can see what went wrong right from the Portworx Backup UI. When a VM backup fails, Portworx Backup cleans up after it straight away, so failed backups don’t waste storage.

Portworx Backup 3.2.0 also runs in IPv6-only and dual-stack clusters, with no IPv6 install parameter required. This addresses a common requirement in federal and large-enterprise networks. Many of these enterprises run clusters across regions, so timestamps in the UI now show their timezone, and a new page lists backup schedules from every cluster in one view.

Portworx Backup 3.2.0 is planned for general availability in November 2026.

DR protection groups have been namespace or label scoped. That’s a reasonable model for applications and an awkward one for VMs, because a namespace full of virtual machines rarely has a single recovery objective. Protecting a handful of VMs meant protecting everything around them, and failing over more than you intended.

You can now select individual VMs by name for protection, migration, and failover. It’s available at the stork level today, with UI and Advanced Cluster Management integration to follow.

Faster VM migration off VMware: Array-native copy instead of migrating across the network, up to 12x faster

The default migration path reads VMDKs through VDDK, which means VM data travels out of the array, through a host, and back down again. That host is the bottleneck, and it’s a bottleneck you’re paying for on every VM in the estate.

For customers on FlashArray, storage-offload migration takes the host out of the data path and has the array copy the data natively. A 2TB VM that takes over a day through the default path completes in about 2 hours.

Multiply that across a few hundred VMs and VM migration is no longer a roadblock to running VMs on Kubernetes.

How to get started?

Most of this is easier to evaluate than it is to read about.

Virtbench runs against any KubeVirt cluster on any CSI backend, including whatever you’re running today. Start with validate-cluster, then put a boot storm against a VM population that looks like your real one. It will tell you more about your current stack in an afternoon than any vendor deck will.

If you want to see Kube Datastore and Operations Center without building anything first, the hands-on labs are open to everyone.

And if you’re planning a VM migration, a GPU buildout, or both at the same time, we’d love to hear what you’re working on.

Hands-on Labs

Dive into hands-on labs with live instructors.