Since its 2016 founding, KubeVirt has enabled organizations to run legacy virtual machines alongside containerized workloads on the same Kubernetes platform. The CNCF incubating project, now backed by contributors from Nvidia, Microsoft, AMD, Intel, SUSE and others, is preparing for a significant evolution as it works toward full CNCF project graduation. The enhancement pipeline has grown from a small set of items to more than a hundred proposals across versions 1.8 through 1.10, managed through the KubeVirt Enhancement Proposal (VEP) process to maintain core stability while the project expands.
Beyond its original mission, KubeVirt has become a foundation for broader infrastructure ecosystems. Projects such as Open Sovereign AI Cloud (OSAC) leverage it for VM, cluster, and bare-metal services, while Cluster API Provider KubeVirt (CAPK) uses KubeVirt VMs as Kubernetes nodes. Flight Control demonstrates edge deployment by running virt-launcher without the full KubeVirt control plane.
Devices, Dynamic Resource Allocation, and new hardware
GPU assignment to VMs through Kubernetes Dynamic Resource Allocation has reached beta status in v1.9, moving beyond traditional device-plugin approaches. The same allocation model is being extended to generic host devices, network devices including SR-IOV, and CPU resources. Future releases will allow a single VM to request GPUs, network interfaces, and CPUs as a coordinated set, with Kubernetes handling allocation automatically. Work is underway to generate these resource claims directly from VM specifications and vendor policies, eliminating the need for users to manually write ResourceClaim objects.
That follows the design principle that has guided the project from the beginning: to prefer Kubernetes native solutions and mechanisms rather than building isolated virtualization workarounds.
This approach has enabled KubeVirt to eliminate project-specific implementations in favor of existing cluster capabilities. Examples include Swap in Kubernetes, ImageVolumes, volume populators, and other features that allowed the removal of KubeVirt-only code paths.
Contributors including engineers from Nvidia have been working to support newer Nvidia hardware such as Grace Hopper, Grace Blackwell, and Vera Rubin systems. This work originated in the Accelerated Infrastructure Enablement working group and is moving into the main project.
Confidential VMs and trusted execution
Organizations increasingly need to run sensitive applications and AI workloads on shared infrastructure while protecting data and models during execution. Confidential computing leverages hardware-backed trusted execution environments to provide isolation, including defense against privileged host software within the platform's threat model. Remote attestation enables workload owners to verify the environment before entrusting it with secrets. KubeVirt is expanding confidential VM support and exploring integration with attestation and secret-release services, including Trustee from the Confidential Containers project.
For AI, the trust boundary should extend across the full execution path—CPUs, accelerators, and the interconnects between them. Workload owners need to verify that environment through attestation before releasing sensitive data or model keys. KubeVirt offers an opportunity to bring confidential VMs, protected accelerators, and attestation together through familiar Kubernetes workflows. Collaboration with projects such as Confidential Containers and Trustee can make these protections more accessible while helping workload owners control access to their data and models.
Fan Zhang, co-lead of Kubevirt's AIE and Confidential Compute working groups
Support spans Intel Trust Domain Extensions (TDX), AMD Secure Encrypted Virtualization including SEV-SNP, IBM Secure Execution, and emerging Arm Confidential Compute Architecture (CCA) support. In KubeVirt v1.9, the AMD SEV and SEV-SNP feature gate reached beta status, Intel TDX support remained alpha, and IBM Secure Execution achieved general availability. Arm CCA enablement continues under development.
Capability discovery helps determine where a VM can run; attestation helps workload owners decide whether to trust the environment in which it runs.
Future work includes more consistent discovery of trusted execution environment capabilities across cluster nodes to help Kubernetes place confidential VMs on suitable infrastructure. Additional proposals address attestation initialization data, evidence handling, and integration with external verification and secret-release services such as Trustee. For accelerated workloads, the vision extends to confidential device assignment and protected communication between CPUs and accelerators, requiring coordinated support across hardware, firmware, the virtualization stack, guest software, and attestation services.
These efforts remain at various stages of discussion and implementation, with inclusion in future releases dependent on community review, integration, and testing.
Extending KubeVirt without growing core
As a mature project, KubeVirt protects its core deliberately. Features only land in kubevirt/kubevirt when the project commits to supporting them for everyone indefinitely without breaking existing clusters. This deliberate pace sometimes means the community questions whether a feature belongs in core at all, but that should not prevent someone from building it.
A feature does not land in kubevirt/kubevirt until we are willing to support it for everyone, for a long time, without breaking the clusters that already run.
KubeVirt is adopting the Kubernetes model of extensibility, allowing users to build complete features outside core while maintaining KubeVirt API guarantees. Structured plugins provide this path as cluster-scoped objects covering domain hooks, node hooks, and admission. Domain changes can be expressed as CEL expressions or sidecars when hooks need external state, with administrators able to see and control them. This capability reached alpha status in v1.9.
Pluggable virtualization stacks
The virtualization stack itself represents the other extensibility frontier. libvirt, QEMU, and KVM remain central to KubeVirt and continue as the default choice. In v1.8, the project added an in-tree Hypervisor Abstraction Layer with Microsoft's MSHV backend as alpha. The goal is making the virtualization stack pluggable so users can extend KubeVirt with Cloud Hypervisor, OpenVMM, or Firecracker out-of-tree without forking the project. This work remains ongoing.
KubeVirt enables customers to modernize VM workflows by bringing Kubernetes orchestration, storage, and networking to virtual machines. Extending these benefits to virtualization solutions built on alternative stacks adds user flexibility. Our proposal builds on work to support alternate hypervisors and aims to fully decouple KubeVirt from its underlying virtualization stack through a pluggable virtualization framework. It follows KubeVirt's move toward greater customization and flexibility. I'm excited to be working on this because it has the potential to broaden KubeVirt's adoption across organizations.
Harshit Gupta, senior software engineer, Microsoft
Pluggability requires re-architecting KubeVirt to use a plugin framework for selecting specific virtual machine monitors and hypervisors, with initial implementation work underway. KubeVirt Enhancement Proposal #82 outlines the main pluggability effort. Beyond enabling alternative virtualization platforms, maintaining backends as plugins could improve testing and simplify maintenance.
The next 10 years
The project began a decade ago with a focused mission: helping organizations migrate legacy VM workloads onto Kubernetes. Today, the mission has broadened toward enabling teams to deploy modern, next-generation platforms. From AI inference and edge deployments to hardened multi-tenant environments and emerging architectures, the community remains committed to expanding what virtual machines can accomplish natively on the platform.
What started as an ambitious experiment to orchestrate VMs through Kubernetes has grown into an entire ecosystem. The next decade will be shaped by how contributors transform these proposals into stable, production-ready capabilities.