Managing virtual machines on Red Hat OpenShift with Service Mesh

Managing virtualized workloads alongside containerized applications remains a persistent challenge for IT operations, often creating siloed management environments. At Red Hat Summit 2026, I had the opportunity to take the stage during the OpenShift Spotlight session and demonstrate how Red Hat OpenShift is bridging this divide, by allowing organizations to treat a virtual machine (VM) and a container as first-class citizens on a single platform.

Alan Cowles presents during the OpenShift Spotlight at Red Hat Summit 2026.

Bridging the virtual-container gap

My demonstration focused on a fictional Travel Agency application running seven virtual machines. This legacy application supported the booking and billing functionality and had VMs dedicated to the different sub-functions required for the application to run. For example, there was a VM dedicated to running an application for booking rental cars, while another focused solely on flight reservations, with still another dedicated to arranging accommodations at hotels.

It's been observed that, in most cases, organizations are forced to maintain separate management consoles for VMs and containers. This is because they either host their container platforms within their virtualization solution, or run both on bare-metal infrastructure side-by-side, managed by separate teams. This can create a "toggle tax" that drains operational efficiency. In the demonstration, I showcased how Red Hat OpenShift mitigates this by integrating virtual machines directly with the platform's native features like service mesh.

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. With Red Hat OpenShift Service Mesh, I injected sidecar containers to the running VMs, and thus provided additional functionality that was previously unavailable. Initially, the traffic graph was empty—the sidecar containers hadn't been injected yet! With a quick visit to the command line on my imaginary keyboard, I was able to inject a service mesh sidecar container, and within a few moments, the environment transformed. The VM’s pod view expanded from two containers to three, adding an istio-proxy container alongside the guest-console and compute containers that make up the VM. Once injected, the service mesh graph began to populate with new data, and provided a comprehensive visualization of the entire application flow, including database and support services. 

 The traffic graph function of OpenShift Service Mesh outlines a comprehensive view of the travel agency’s application workflow. 

After exploring the network connectivity through the service mesh, I showed the audience that OpenShift Service Mesh was not only good for the visualization of network traffic flows, but for shaping it as well. To demonstrate this, I showed a canary deployment of an updated version of the Travel Agency application. I provisioned a new "cars v2" VM and, making use of the traffic shaping capabilities of the service mesh, scripted a deployment routing 90% of traffic to the virtual machine running the legacy version of the cars application, and only 10% to version 2 (“kicking the tires” on the car, if you will). Once I felt comfortable with the new version, I entered another command to shift the traffic flow to an 80/20 split, favoring the new version of the application, which would proceed the logical next step of retiring the VM responsible for running the legacy version of the application.

While the demonstration showed a lot of complex interaction between container services and the virtual machines, its main takeaway is that it was able to exhibit that OpenShift doesn't just "run" VMs—it treats them as a native component of the modern, programmable application fabric, enabling sophisticated deployment strategies without requiring complete application rewrites.

Running VMs in OpenShift allows the travel agency to test new features as native components in OpenShift with modern rollout strategies instead of forcing application rewrites. 

You can explore this workflow and see the platform's capabilities firsthand with this interactive arcade demo.

Perspectives from the field: The Abacus journey

The best part about being able to demonstrate this is that the technical path I’ve outlined isn't merely theoretical. It mirrors the strategic shift taken by one of our customers. CTO Paul Ponzeka from Abacus, a managed service provider for the financial and healthcare sectors, joined me on stage at the OpenShift Spotlight session and had a brief chat with Red Hat's Stu Miniman about Abacus' journey migrating to OpenShift, driven by a need for agility and a reaction to unsustainable vendor practices.

Paul Ponzeka, CTO, Abacus, sits down to talk about their journey from legacy VM providers to Red Hat OpenShift Virtualization. (20:16)

When asked why Abacus sought change, Ponzeka offered a candid market assessment, quipping, "VMware and Broadcom walk into a bar..." He elaborated on the difficult reality many service providers faced: "We saw 2x price increases, we were shrunk out of the service provider platform…fundamentally we needed to change."

For Ponzeka, the move wasn't just about escaping price hikes—it was about upskilling his team to handle a more modern, efficient architecture. He noted the transition also brought unexpected performance improvements. "We actually got significantly better performance by moving to OpenShift. We started bringing some of our bigger ports to line speed," he shared.

Ultimately, Abacus found that by moving to OpenShift, they could bring customers' containerized workloads back on-premise, running them on bare metal next to line-of-business VMs. This turned a migration necessity into a new product line, proving that breaking free from legacy constraints is the first step toward true infrastructure modernization.

Conclusion

OpenShift's VM integration is a strategic enabler for organizations seeking to escape vendor lock-in while modernizing their infrastructure. The demonstration I led helped provide an example of how legacy applications can still thrive in the world of the modern cloud-native platform, and the testimonial by Ponzeka also proved for Abacus, that what begins as a migration can evolve into competitive advantage, transforming infrastructure constraints into new business opportunities. By treating VMs and containers as equals within a unified application platform, companies can preserve existing investments while gaining the agility and cost efficiency of cloud-native operations. 

Learn more about Red Hat OpenShift Virtualization 

• Explore the product
• Watch the entire OpenShift Spotlight session
• Check out more resources in the learning hub