
In the virtualization workshops I run, I have been asked one question many times: "Is it ready for production?" Now KubeVirt is a CNCF graduated project, and that makes the answer kind of obvious.
That makes running VMs on Kubernetes boring. For a CTO or a CIO, boring is the best word a platform can get.
Ten years in the making
KubeVirt has been around for a while. Red Hat started it in 2016. It joined the CNCF Sandbox in September 2019, moved to Incubating in April 2022, and the CNCF announced its graduation at KubeCon + CloudNativeCon North America 2026.
Today it has 2,088 contributors from 520 organizations, with NVIDIA, Microsoft, AMD and Intel among them. It runs in production at ByteDance, Cloudflare, CoreWeave and NVIDIA. Swisscom built a sovereign managed Kubernetes service on KubeVirt and Kube-OVN: 390 clusters and 2,100 worker nodes.
It is tested, it works, and big companies bet on it.
What graduation tells a CTO
Graduation takes work. To get there, the project had to pass a third-party security audit and set up a formal steering committee, on top of years of adoption across many companies.
For a risk officer that answers three questions:
- Did someone outside the project check the code? Yes, an independent security audit.
- Who decides the future of the project? A steering committee with open governance.
- Does anyone run it for real? Yes, at a scale most of us will never need.
"Is it safe to use?" now has a public answer you can show your board.
Open source to the rescue, again
If your next virtualization renewal brings terms you never asked for, signing anyway can feel like the safe choice. Moving thousands of VMs looks riskier than paying more.
Open source has broken this pattern before. Linux did it for Unix servers. Kubernetes did it for container orchestration. KubeVirt can do it for virtualization: the code is open, the governance is neutral and several vendors offer support for it.
You pick the partner. And if the partner stops being a good fit, you can change it without rebuilding your platform.
One platform, one team
Feeling safe is the first argument. Simpler IT is the second, and it is the one I see leaders underestimate.
Most companies run two stacks today: a hypervisor for VMs and Kubernetes for containers. That means two consoles, two monitoring setups, two backup tools, two teams and two sets of skills to hire for.
With KubeVirt a VM is one more Kubernetes object. So:
- the same GitOps pipeline deploys VMs and containers
- the same RBAC, policies and audit logs cover both
- the same monitoring and alerting see both
- one platform team runs it all
That last point is where the money is. Fewer tools to buy and maintain, fewer handoffs between teams, one roadmap instead of two. Plus your VMs get the automation your containers already have.
What graduation does not do for you
Boring still needs a plan. Graduation proves the project is mature, and the migration plan is still yours to write. Before you move the first VM, check four things:
- Storage: live migration and snapshots need storage that supports them at your scale.
- Networking: VLANs and fixed IPs must keep working, so design the network before the move. VPCs and other advanced networking need a CNI built for them, such as Kube-OVN.
- Backup and DR: make sure you have it covered and know how you will implement it. Production needs it. Implement, test and repeat.
- People: your virtualization team needs Kubernetes skills. Budget the training.
Treat them as the migration plan.
Boring is the goal
In ten years KubeVirt went from an experiment to a graduated project with thousands of contributors. For CTOs and CIOs that means a real option at the next renewal: one open platform for VMs and containers, run by one team, with no single vendor holding the keys.
Boring infrastructure lets your team spend its time on the things that make you money. That is the kind of boring I want!