Every infrastructure conversation eventually arrives at the same uncomfortable truth: compute is the easy part, and storage is where things get hard. I sat down with Greg Muscarella, GM of Everpure Portworx, at Pure Accelerate 2026, and that tension was the thread running through our entire conversation. His pitch, boiled down, is that Portworx is the piece Kubernetes has been missing all along.
Let me set the stage the way he did, because the framing matters.
What Portworx actually is
Strip away the marketing and Portworx is a storage abstraction layer—a pooling and virtualization layer for storage in Kubernetes. If you’ve got any workload running in Kubernetes that needs persistence, Portworx makes that storage easier to consume, and not just for the platform engineering team but for developers too. Instead of wrestling with multiple interfaces, you get a single layer to manage all of it.
Muscarella was careful to distinguish this from just “putting bits somewhere.” Portworx often relies on a backend to do the actual storing—an array, a cloud block store like AWS EBS, whatever you’ve got—while it handles the data services and presents one virtualized pool on top. Think aggregation and portability, not another silo.
He went back to the origin story to make the point land. When Google released Kubernetes, inspired by its internal Borg system, persistence at Google was someone else’s problem. In the enterprise, it very much isn’t. The Container Storage Interface (CSI) filled part of that gap, but it has real shortcomings. Each array brand has its own CSI. Even within one brand, each array can have its own storage class. You end up with siloed storage, which is exactly the thing Kubernetes was supposed to help you escape on the compute side.
The 71% question
I came into the interview with a research stat pulled from the Portworx 2026 Voice of Kubernetes Report, a survey of more than 500 Kubernetes experts: 71% of organizations are planning to modernize or migrate their VMs to Kubernetes. I asked Muscarella if that number surprised him.
It didn’t. His reasoning was matter-of-fact. Nobody bats an eye when you say the future of compute orchestration is containers—everyone agrees that’s the destination. So running VMs on Kubernetes, which used to sound weird, starts making sense once you accept where people want to end up. What’s changed lately is motivation. Licensing costs went up, but so did storage, servers, and power. The cost pressures are coming from every direction at once, and they’re pushing people toward a move many already wanted to make.
He shared a great full-circle example. One customer had a third-party application that was natively containerized, but they’d been forced to stuff it into VMs just to run it on their VM infrastructure. After moving everything to OpenShift and Portworx, they could finally rip the application back out of the VM and run it natively as a container—undoing the workaround they’d built years earlier.
The peanut butter and jelly of OpenShift and Portworx
Muscarella didn’t hide his enthusiasm for the Red Hat partnership. He called OpenShift and Portworx “the peanut butter and jelly,” and the metaphor fits the division of labor:
- OpenShift and the broader Kubernetes ecosystem handle compute orchestration.
- Portworx provides the storage pooling and virtualization that makes workloads portable, persistent, and more efficient.
The CSX story from the Day 2 keynote is the proof point. When you’ve got a mission-critical workload like Positive Train Control—where stopping the data flow literally stops the trains—you need a data layer that won’t blink. Muscarella noted that Portworx sits directly inside the OpenShift console, which is a big deal for customers who don’t want yet another pane of glass to learn.
I asked who drives these deals, Red Hat or Portworx. His honest answer: it’s a mix, but Red Hat usually gets in earlier. People think about the compute side first. Say “virtualization solution” and folks immediately think OpenShift or Nutanix or Rancher. Storage is the thing nobody remembers to ask about up front, even though every compute platform needs compute, storage, and networking. So Red Hat is often in the account first, and Portworx follows.
About that VMware exodus
You can’t have this conversation in 2026 without the Broadcom-shaped elephant in the room, and Muscarella’s read matched what I’ve been hearing all week. The “mass exodus” framing is overblown. The reality is a spectrum.
Some customers genuinely can’t stand the situation and are going 100% elsewhere—those are the loud, ugly breakups you read about in the press. Others are staying on VMware because it’s honestly the right call for them, and they’re just optimizing licenses. And a big chunk is somewhere in the middle, moving a percentage of workloads to OpenShift or Nutanix for multi-vendor leverage. He summed up the customer base in four buckets: those who’ve finished the migration, those in the middle of it, those still planning, and those scratching their heads wishing it would all go away.
His advice for the fence-sitters was the most quotable moment of the interview. “It’s never gonna get easier than today,” he said. Then he reached for a Rush lyric: “If you choose not to decide, you still have made a choice.” His warning was that the migration takes longer than people think, so starting early buys you a buffer you’ll be grateful for.
Dan Kogan, Everpure’s VP of Cloud and New Products, gave me a complementary view in a separate conversation. He thinks the exodus talk is “a little bit overblown” and that things have stabilized, partly because Broadcom came back to the table on pricing for customers it wanted to keep. His point: there’s no one-size-fits-all answer, and Everpure is fine with that because it has storage integrations across VCF, Nutanix, OpenShift, Azure, and AWS regardless of which way a customer jumps.
VMs, containers, and AI—all three, no trade-offs?
I put the hard question to Muscarella directly: can Portworx handle AI workloads, VMs, and containers all landing on Kubernetes without trade-offs? He qualified it honestly rather than giving me a clean yes.
AI workloads already run on Kubernetes—he sees almost nobody doing anything weird there. Training tends to be specialized and he’s not seeing tons of customers do it, but inference is growing fast and takes many flavors: serving models, bringing contextual data into the inference stack, KV cache, and so on. Portworx adds value across those. The candid part: Portworx is very mature on the container side, comfortably so, but he expects the VM side to keep growing as they add capabilities. He’s not overselling where the product is today.
A couple of technical pieces are worth knowing about. There’s KubeDataStore, which Muscarella described as a more storage-efficient way to operate—faster, cheaper, less waste—whether you’re sitting on arrays, other block stores, or cloud backends. And the roadmap leans into being a better abstraction layer: offloading snapshots, replication, or encryption to the array or cloud backend when it makes sense, while still handling things at the host level for cross-array or cross-cloud moves where the underlying hardware doesn’t match.
The one message
I always ask for the single takeaway, and Muscarella did something I appreciated—he refused to give me just one. Instead he handed me three, each tuned to a different angle the article might take. If the piece was about modern virtualization, the takeaway was that the combined Kubernetes-plus-Portworx platform is ready for those workloads today. If it was about AI, the story was that more AI means more containers, more applications, and more data, and Kubernetes is the layer that lets you manage all of it.
But this is the Portworx story, and for that, his middle answer is the one that lands. Portworx is the missing piece that handles storage for Kubernetes in a genuinely enterprise-grade way—not just “storage is available,” but all the data services someone coming from a VMware world would expect, with the efficiency and portability to back them up.
His closing image is the one I’ll keep. Kubernetes does a beautiful job moving compute around—run this container on this node, that node, another cluster entirely. But data has mass. It doesn’t move as fast or as freely. Portworx, he said, is “the magic layer that makes your storage as portable as your compute.” For anyone planning a Kubernetes future while staring down a VMware decision, that’s the sentence worth pinning to the wall.
##
