Executive Summary
KubeVirt reached CNCF Graduated on 10 November, six years after it entered the Sandbox. The label matters for one reason. A graduated project publishes a stability contract for its API, and for virtual machines on Kubernetes that contract is the thing a buyer signs up for. A hypervisor replacement runs three to five years, and until this week the KubeVirt surface was a project promise rather than a foundation guarantee.
The evidence behind it is solid. Two thousand contributors across 520 organizations, production estates at ByteDance, Cloudflare, CoreWeave and NVIDIA, and a Swisscom service running 390 clusters and 2,100 worker nodes with 160 TB of persistent storage. Against that sits the number we reported on Monday, eight percent of VM-running organizations managing those machines with KubeVirt. Graduation does not move that number. It decides whether the eight percent can defend the choice in a procurement review, and it lands in the same week as a competing neutral VM API from Broadcom.
The Cloud Native Computing Foundation moved KubeVirt to Graduated on Tuesday. Red Hat wrote the first version in 2016, which makes the project ten years old and gives it six years of climbing from Sandbox to Incubating to stable.
Most graduations are a badge. This one changes what an operator can put in a procurement document for KubeVirt on Kubernetes, because the label makes a promise about the API surface rather than a statement about popularity.
Graduation puts a contract around objects you already apply
KubeVirt adds virtual machines to a cluster through custom resources and controllers. You apply a VirtualMachine object to the API server that already holds your pods. A controller renders it into a VirtualMachineInstance. A node agent starts a virt-launcher pod, and QEMU with KVM runs the guest inside that pod. No second control plane, no second scheduler. The VM inherits the pod lifecycle, its cgroups and its network.
That design is why the label carries weight. A hypervisor replacement is a three to five year commitment, and an operator signing one is borrowing the platform risk appetite for that whole term. A young project can change a custom resource between releases. A graduated project publishes the contract that stops it.
Most of the capability arrived before the label. Version 1.8 in March added a hypervisor abstraction layer, Intel TDX attestation for confidential VMs, storage-agnostic incremental backup, and performance work that puts AI and HPC workloads in VMs close to native speed. Backup, attestation and hardware abstraction are the three things a regulated buyer asks about first.
The install base is thin and the foundation is now crowded
Adoption is the harder number. A Linux Foundation study out this week put KubeVirt at 8 percent of respondents who run virtual machines. Graduation does not move that. It removes an objection, which is a slower and less visible kind of progress.
The competitive picture moved too. Broadcom contributed its own VM API to the CNCF Sandbox on 9 November, days before this. That project builds on VM Operator, the controller Broadcom already ships for vSphere inside VMware Cloud Foundation, and its stated goal is a provider-neutral API. So the foundation now hosts two neutral VM interfaces, one graduated and one in the Sandbox, and the largest VM estate in the market is writing one of them.
Whichever surface an operator standardizes on, the useful question is the same. Can you move off it. A graduated API with a published contract is easier to leave than a sandbox API whose shape can still change under you.
The production evidence is concentrated rather than broad. ByteDance, Cloudflare, CoreWeave and NVIDIA run it. Swisscom launched a sovereign managed Kubernetes service on KubeVirt and Kube-OVN in August 2025, and that estate now runs 390 clusters, 2,100 worker nodes and 160 TB of persistent storage.
Three questions before it goes into a roadmap
Ask how much of your estate is stateless enough to leave the hypervisor entirely, because that work is cheaper than any platform change. Ask which VMs carry confidential workloads that need TDX attestation, because that shipped in the March release and it narrows the alternatives. Then ask who owns the VM API if you change platforms in three years, which is the only question graduation was ever going to answer.
Related reading. Our analysis of Broadcom putting its VM API into the CNCF Sandbox, and a look at what happens when a Kubernetes operating system starts running virtual machines.
Sources. CNCF graduation announcement, the KubeVirt project, the Swisscom case study, the source tree and the Kubernetes documentation on custom resources.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.