Creating a smooth path to open virtualisation

Everpure (formerly Pure Storage), headquartered in Santa Clara, CA, pioneers advanced data platforms that deliver a true storage-as-a-service experience. Portworx by Everpure is the Kubernetes data platform trusted by thousands of enterprises, including many in the Fortune 500, to power mission-critical VMs, containers, and AI workloads.

When modernising our own virtualisation stack, we adopted the same open, cloud-native approach we champion for customers: building our internal platform on Kubernetes and Portworx. With Kubernetes now central to our AI initiatives, we've fully committed to a container-first strategy across the organisation.

At Everpure, we’ve spent years helping our customers modernise their data platforms. In 2023, we had to take that same hard look at ourselves. Our VM footprint had grown to more than 70,000 cores across our global data centers. VMware was our primary virtualisation layer, but we were also running workloads on OpenStack, native KVM, and Kubernetes clusters on AWS, Azure, and on premises. The tools and operational models were different for each. And then the VMware renewal conversation arrived, with cost increases that turned the next renewal into a forcing function.

The renewal pressure was the trigger, but the story was bigger. Our engineering teams wanted one platform for VMs and containers, and our developers wanted self-service instead of tickets. We wanted to avoid the cycle of vendor lock-in that brought us here in the first place.

Greg McNutt, Technical Director, explains, “VMware is the gold standard, there’s no denying that. But with costs, control, and our future plans, we needed something likely to remain open source for a long time, with a large ecosystem around it.”

We evaluated the options carefully. Nutanix entered the conversation partway through, but moving to another proprietary hypervisor would have traded one lock-in for another. Kubernetes with KubeVirt on bare metal, paired with Portworx Enterprise and FlashArray, aligned best with our goals. We were already investing in Kubernetes in the cloud, and KubeVirt gave us a credible path for our VMs. Portworx gave us an enterprise-grade data platform for both VMs and containers, and the entire stack runs on open source software.

Before we wrote any code, we agreed on principles we wanted every decision to trace back to. 

1. The platform had to be open by design, so we’d never again be held hostage by a licence cycle. 

2. It had to be flexible across hybrid cloud, running the same way on premises, on Amazon Elastic Kubernetes Service (Amazon EKS), and on Everpure Cloud Azure Native. 

3. It had to scale across workload sizes, from small services to stateful VMs over 1TB.

4. It had to be operated through GitOps, so change management was built in rather than bolted on.

The architecture we designed is deliberately layered. Bare-metal servers are provisioned from Git using Ansible, GitHub Actions, and Kubespray. Upstream Kubernetes runs the cluster, with Cilium as the Container Network Interface (CNI) and Border Gateway Protocol peering with our top-of-rack switches. KubeVirt handles virtualisation alongside containers. Portworx Enterprise manages the data plane, exposing ReadWriteMany (RWX) volumes on FlashArray through FlashArray Direct Access. Argo CD continuously reconciles everything from GitHub: the KubeVirt stack, Portworx, observability, secrets, and security scanning. Any cluster can be rebuilt from source.

To keep the experience familiar for VMware admins, we extended our homegrown VM lifecycle user interface KIF to work with KubeVirt. Teams can still create, power, resize, snapshot, and access VM consoles through the same interface they’ve used for years. Underneath, though, they’re working with Kubernetes-native objects.

Most of our real challenges came from networking. When we first tested live migration, VMs were assigned new IPs on the target node, and Secure Shell (SSH) sessions dropped. We built a custom Domain Name System (DNS) operator to update records instantly. DNS caching still caused disruptions when VM IPs changed, so we added Multus CNI for VMs that needed a stable IP on the secondary interface. The primary Cilium interface keeps handling Kubernetes-native service traffic and policy. That layered approach lets us keep the benefits of extended Berkely Packet Filter (eBPF) networking while giving critical VMs the stability they need.

Storage migration was the second big challenge. Early migrations pushed VM disks over the host network using Containerized Data Importer (CDI) and VMware Virtual Disk Development Kit (VDDK). It worked, but large VMs (over 1TB) took more than five hours to migrate across regions. That was too slow for the pace we needed. Working with our own Portworx and FlashArray teams, we integrated Forklift with FlashArray XCOPY storage offload. The FlashArray performs the copy at the storage layer, and replication pre-stages the data across sites. Migrations that used to take hours now take 40 minutes or less. Smaller VMs move in minutes, and our downtime windows went from hours to minutes.

We approached this as a multi-year program. After VMware announced changes in late 2023, we spent 2024 on evaluation and design. We then ran a pilot of about 60 VMs for nearly a year before starting the production migration in December 2025, which we’re now executing in waves.

We started by pulling usage and capacity data directly from VMware and mapping every workload to an application owner. About 40% of our footprint turned out to be Tier 4 developer VMs, the workstations and simulator environments our engineers use to build Purity. That became our first wave, giving us a big core-count win, a safe environment to harden the platform, and time to work with application owners before we touched production.

To coordinate all of it, we built our own migration tracker. What started as a reporting dashboard for managers grew into the control plane for the whole program. The tracker is a three-tier app written in React and FastAPI, running on the same Kubernetes cluster we are using for the VM migration. Today it tracks every VM, batches migrations into waves, kicks off Forklift jobs, and hands off to KIF when a VM lands on KubeVirt; we’re considering releasing it as open source.

We’ve offboarded more than 20,000 VMware cores through migration and cleanup. VM provisioning has dropped from five to eight minutes on the old stack to about one minute on KubeVirt with Portworx. VMs and containers now share one control plane, one policy engine, and one set of APIs. Developers self-serve through Okta and OpenID Connect (OIDC) instead of filing tickets. Day-two work that used to result in a steady stream of tickets, such as requests to expand volumes as disks filled up, is now handled automatically by Portworx Autopilot.

A team of just eight engineers runs the whole program. At steady state, we move about 300 VMs per day, and the tooling can push that higher when a wave calls for it.

John Chau, our VP of Engineering Infrastructure and Shared Services, sums up the business impact: “By moving our VM estate from VMware to Kubernetes with KubeVirt and Portworx, we reduced licencing costs and unified VMs and containers on a single platform. The result is faster delivery for our developers and a more scalable foundation for modern workloads.”

Three lessons stand out. First, start with developer workloads to build confidence; they have enough variety to harden the platform without putting production at risk. Next, invest in automation early because it lets a small team manage a large fleet. And finally, plan for network bottlenecks. Most virtualisation tooling still isn’t as dynamic as teams assume, and ephemeral workloads expose those gaps fast.

Sagar Srinivasa, who led much of the migration engineering, comments: “Automation is critical, not just to start the journey but to sustain it. With one Kubernetes API, our developers get faster provisioning and the full benefit of the ecosystem, instead of orchestrating across multiple platforms.”

We’re currently migrating Tier 1 and Tier 2 workloads, including DNS, Artifactory, and our build infrastructure. The goal is to land about 90% of our estate on the unified platform, with the remaining 10% going to software as a service, public cloud, or retirement as appropriate. We’re already building hybrid applications that mix VMs and containers, and we’re preparing for GPU scheduling and AI/ML workloads on the same stack. 

When customers ask us whether this path is ready for enterprise use, we can point to our own environment and answer honestly: we’ve walked it, it works, and the tooling is available to them, too.