Published by: Pathgate
Date: April 2026
Author: Technical Team

Executive Summary

Exiting your well-known virtualization provider is most of the times considered a complex, long-term project rather than a simple switch, it can take from 12 to 36 months to execute properly. For many organizations, the challenge is no longer whether they should modernize their infrastructure, but whether they can do it without rewriting every virtual-machine-based workload or committing to another costly licensing cycle. (Tied to virtualization provider contracts, or cloud-dependant systems).

A growing alternative is to use self-hosted Kubernetes as the control plane and KubeVirt as the virtualization layer orchestration framework, allowing virtual machines and containers to run side by side on the same self-managed hardware platform.

In practical terms, KubeVirt extends Kubernetes with virtualization-specific APIs and controllers, while Kubernetes continues to handle scheduling, networking and storage. This creates a unified operational model for both legacy and cloud-native workloads.

1. Why this model matters now

› KubeVirt = K8 + KVM

A useful shorthand is that KubeVirt = Kubernetes + KVM. KVM provides the hypervisor capability in Linux, and KubeVirt bridges that capability into Kubernetes so that VMs can be orchestrated using Kubernetes-native patterns. That matters because it allows teams to preserve VM-based applications while modernizing operations around them, instead of forcing an immediate refactor into containers.

2. Why KubeVirt is operationally credible

› GitOps turns VM management into infra as code

One of the strongest reasons to run VMs under Kubernetes is not just consolidation, It is repeatability.

In practice, that means images, DataVolumes, networking, cloud-init, services and even environment-specific VM sizes can be versioned and promoted through Git-driven workflows instead of manual clicks in a proprietary VM GUI.

> A pragmatic migration pattern

The best migration pattern is usually rehost first, optimize second, refactor later.

Starting with VM workloads that are hard to containerize but operationally stable, move them onto self-hosted Kubernetes through KubeVirt, keep them as VMs, and immediately gain a unified platform, Git-backed lifecycle management and policy-driven operations.

Then, over time, refactor only the workloads that truly benefit from becoming container-native, this phased model is exactly what makes KubeVirt strategically useful: it allows modernization without demanding disruption.

3. The Business Case

> Efficiency, agility and cost control

> Networking is part of the savings story too

The cost conversation should not stop at hypervisors. In many environments, there is a second layer of accumulated spend around service exposure and load balancing. With Cilium, Kubernetes can operate without kube-proxy, and Cilium provides eBPF-based service load balancing as part of the platform.

That does not mean every advanced F5 or ADC use case disappears. But it does mean many internal applications, standard L4 exposure patterns, and a meaningful subset of north-south traffic delivery can be handled inside the same software-defined platform that already runs the workloads. The practical result is fewer moving parts, less appliance footprint, and a clearer path to cost savings across compute and networking together.

4. Our Conclusion

For organizations looking to move away from costly virtualization estates, self-hosted Kubernetes with KubeVirt offers a pragmatic middle path. It preserves VM compatibility, introduces declarative operations, aligns VM and container lifecycle management under one control plane, and opens the door to real cost reduction across compute, operations and even parts of the networking stack.

The strongest version of this strategy is not ideological. It is practical: keep the workloads that still need VMs, run them on a cloud-native control plane, deploy them through GitOps, expose services through Cilium where appropriate, and benchmark the platform with production-grade criteria. Done well, that approach can deliver exactly what many teams need most right now: a cheaper, safer and more operationally efficient way forward.

Our Strategic Recommendations:

• Use KubeVirt to consolidate control planes, not just to replace a hypervisor. The real value is not only running VMs on Kubernetes, but operating virtual machines and cloud-native workloads through one consistent platform.
• Treat virtual machines as code from day one. Use Git, Helm and Argo CD to define, version and deploy workloads idempotently, reducing drift and manual operational overhead.
• Design for cost reduction across both compute and networking. Savings should come not only from avoiding expensive virtualization licensing, but also from simplifying service exposure and reducing dependence on proprietary load-balancer appliances where Cilium can cover the requirement.

Moving from traditional virtualization to a Kubernetes-based operating model is as much an architectural and operational transition as it is a technical one. Working with a partner like Pathgate that understands Kubernetes, KubeVirt, Cilium and VM migration patterns can significantly reduce risk, accelerate delivery and help teams avoid costly design mistakes during the transition.

About Pathgate