Red Hat’s Service Mesh Turns VMware Migration Into a Kubernetes-Native Problem

Broadcom’s VMware pricing overhaul has spent more than two years pushing enterprise infrastructure teams toward the exits. The harder problem has never been finding an alternative hypervisor: it’s untangling a data center where virtual machines and containers already depend on each other, without a rewrite and without a months-long cutover window. At Red Hat Summit 2026, Red Hat used a live demo and a real customer’s migration story to argue that the fix isn’t a new migration tool at all. It’s treating VMs as just another workload behind the same Service Mesh already managing containers.

The cost of staying on VMware

The pressure behind that pitch is well documented. A survey of 450 VMware users across 14 countries, conducted by Michael Warrilow, principal analyst at Virtified (formerly of Gartner), found that half of respondents intend to reduce their reliance on VMware by 2028, according to reporting from The Register. Warrilow attributed much of that shift to Broadcom’s decision to sell VMware only as complete Cloud Foundation 9 (VCF 9) bundles rather than a la carte licenses: “Some users feel the cost of VCF 9 is beyond their means,” he said, or object to paying for tools they never asked for.

Timing adds to the pressure. VMware 8.x reaches end of support in October 2027, so any organization still running it has to decide, in the next year or so, whether to pay for an upgrade or start planning an exit. Warrilow also warned that Broadcom tends to pull discounts back, or withhold them entirely, once it notices a customer shrinking its VMware footprint, which removes one of the easier ways to soften the cost of staying put.

What Red Hat demonstrated at Summit 2026

Red Hat’s answer, laid out in a blog post by Alan Cowles, Principal Technical Marketing Manager, doesn’t start from a new product. OpenShift Virtualization, Red Hat’s commercial layer on top of the CNCF Incubating project KubeVirt, has run VMs as Kubernetes pods for years. What Red Hat demoed during its “OpenShift Spotlight” session at Summit 2026 was narrower: proving that Service Mesh, the tooling that already handles traffic routing, security, and observability for containers, works on those VM-backed pods with no special-casing.

The demo used a fictional Travel Agency application built from seven VMs handling booking, billing, rental cars, flights, and accommodations. As Cowles put it, “Because virtual machines in OpenShift are running in containers themselves, it’s easy to apply any advanced tooling provided by OpenShift to virtualized workloads just as you would to any containerized workload.”

Sidecar injection doesn’t care if it’s a VM or a container

The mechanism is standard Istio, the technology underlying Red Hat OpenShift Service Mesh. Istio’s own documentation explains that “in order to take advantage of all of Istio’s features, pods in the mesh must be running an Istio sidecar proxy.” Labeling a namespace with istio-injection=enabled triggers a mutating webhook admission controller that automatically attaches an istio-proxy container to every new pod created there, VM-backed or not; a pod that previously showed 1/1 READY becomes 2/2 READY once the sidecar is running, and individual workloads can be included or excluded with the sidecar.istio.io/inject label.

In the demo, once that sidecar was attached to the Travel Agency VMs, Red Hat says “the service mesh graph began to populate with new data, and provided a comprehensive visualization of the entire application flow,” the same dependency map an operator would get from a fully containerized application.

Shifting traffic without touching the application

The second half of the demo showed a canary rollout between two versions of the same VM: traffic started at a 90/10 split favoring the legacy version, then moved to 80/20 as confidence in the new version grew, using OpenShift Service Mesh’s traffic management rather than any change to the VM or the application running inside it. That is the same progressive-delivery pattern Service Mesh already offers container workloads; the news here is that it applies to a legacy VM without anyone touching its code.

Abacus already made the jump

Red Hat’s post pairs the demo with a real customer. Abacus, a managed service provider serving financial and healthcare clients, moved off VMware after what CTO Paul Ponzeka described as unsustainable terms from VMware under Broadcom, including a roughly doubled licensing bill and being removed from VMware’s service provider program. The result, in Ponzeka’s telling, wasn’t just cost avoidance: “We actually got significantly better performance by moving to OpenShift. We started bringing some of our bigger ports to line speed.” Abacus was able to bring containerized customer workloads back on premises, running them on bare metal alongside its line-of-business VMs, which the company says opened up a new product line it couldn’t previously offer.

What the demo doesn’t show

None of this is independent benchmarking. Red Hat’s post names no specific OpenShift, Service Mesh, or Istio version, and the Travel Agency application was built for a stage demo, not measured under production load. Abacus is one migrated customer telling its own story on Red Hat’s blog, not a controlled comparison against staying on VMware or moving to a rival platform; OpenShift Virtualization is competing for the same VMware defectors as Nutanix, Proxmox, and Microsoft’s Hyper-V, among others.

The migration math Warrilow modeled while still at Gartner, for organizations running 2,000 or more VMs, does not disappear just because traffic-shifting works cleanly in a lab demo: $300 to $3,000 per VM if the work goes to outside service providers, and 18 to 48 months from start to finish. What Red Hat is actually selling here is narrower and more believable. Once VMs are running as pods, an enterprise doesn’t need a separate toolchain to observe, secure, and gradually migrate them. It can reuse the Service Mesh it already has for containers, and treat the rest of the VMware exit as an ordinary Kubernetes rollout instead of a special, one-time project.