KubeVirt looks ahead to 10 years: VMs, confidential AI, and new hardware

KubeVirt was born in 2016 inside Red Hat with a simple but ambitious idea: that Kubernetes could run virtual machines alongside containers. Ten years later, that goal remains valid, but the project has changed scale. Today it is an incubating CNCF project, with contributions from Nvidia, Microsoft, AMD, Intel, SUSE, and other players, and the community is working to achieve its graduation as a CNCF project. The news at hand reviews what the upcoming versions will bring and, above all, how the project is organizing itself so as not to lose its way while it grows.

From a 2016 idea to an expanding ecosystem

The original purpose has not changed: to allow legacy workloads to coexist with modern applications on the same platform. What has changed is that other projects have shown they can build on KubeVirt. Open Sovereign AI Cloud (OSAC) uses it for virtual machine, cluster, and bare-metal services; Cluster API Provider KubeVirt (CAPK) uses KubeVirt VMs as Kubernetes nodes; and Flight Control runs a virt-launcher at the edge without the need for the full KubeVirt control plane.

That growth is reflected in the project's internal numbers. Between versions v1.6 and v1.10, the proposal queue went from a handful of items to more than a hundred. Version v1.9 alone included dozens of new proposals. So that this volume does not break the core, the project relies on the VEP (KubeVirt Enhancement Proposal) process: design first, then code, a single tracker, and responsibility distributed among special interest groups (SIGs).

Devices, DRA, and accelerated hardware

One of the most interesting fronts is device management. GPUs in virtual machines can now be requested through Kubernetes Dynamic Resource Allocation (DRA) instead of using device plugins, and that functionality has been in beta since v1.9. The same model is being extended to generic host devices, network devices such as SR-IOV, and also to CPUs. The idea is that, in the near future, a VM can request GPU, NIC, and CPUs and that Kubernetes assigns them as a coordinated set.

Work is also underway so that KubeVirt builds those requests from the VM specification and a vendor policy, without forcing each user to write ResourceClaim objects by hand. The underlying philosophy is clear: prefer native Kubernetes mechanisms over isolated virtualization solutions. That makes it possible to improve the granularity of assignments and, at the same time, eliminate KubeVirt-specific paths when the cluster already offers an alternative.

In parallel, engineers from Nvidia and other contributors have worked so that KubeVirt runs on more recent Nvidia hardware, such as Grace Hopper, Grace Blackwell, and Vera Rubin. That development originated in the accelerated infrastructure enablement working group and is moving up into the main project.

Confidential VMs: protecting data and models at runtime

The second major block has to do with trust. More and more organizations want to run sensitive applications and AI workloads on shared infrastructure without exposing their data or their models during execution. Confidential computing uses hardware-backed trusted execution environments to isolate those workloads, even from privileged host software within the platform threat model. Remote attestation allows the workload owner to evaluate the evidence from that environment before handing over secrets.

KubeVirt is expanding support for confidential VMs and exploring integration with attestation and secret release services, including Trustee from the Confidential Containers project. The work covers Intel TDX, AMD SEV and SEV-SNP, IBM Secure Execution, and the Arm CCA architecture. In v1.9, the AMD SEV and SEV-SNP feature gate moved to beta, Intel TDX support remains in alpha, and IBM Secure Execution reached general availability. Arm CCA enablement continues in development.

For AI, the trust boundary must span the entire 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.

Looking ahead, contributors are exploring more consistent discovery of TEE capabilities across cluster nodes, so that Kubernetes can place confidential VMs on the right infrastructure. Other proposals address attestation initialization data, evidence handling, and integration with external verification and secret release services. For accelerated workloads, the ambition extends to confidential device assignment and protected communication between CPUs and accelerators.

What this means for an SMB

At first glance, KubeVirt may seem like a topic for large infrastructures. But it is worth reading with a practical perspective. If your company has legacy applications that you cannot rewrite overnight, KubeVirt offers a path to keep them alongside the new ones without setting up two separate platforms. If you are also exploring AI, the progress toward confidential VMs and protected accelerators anticipates a future in which the security of data at runtime will be part of the design, not an add-on.

Our recommendation is not to rush into migrating everything at once. Start by identifying legacy workloads that could coexist with containers and assess whether your team already has experience with Kubernetes. Also review what hardware you have: DRA and confidential computing capabilities depend on vendor and firmware support. And keep an eye on the ecosystem: projects such as CAPK or Flight Control can simplify integration in specific scenarios.

If you are automating processes with tools such as n8n and AI, or comparing AI models online, keep in mind that the underlying infrastructure is also evolving. A hybrid approach, with Kubernetes as the common denominator and KubeVirt for what cannot be containerized, reduces fragmentation and facilitates governance. As always, the key is to measure the real operating cost before adopting a new piece in the architecture.

Source: The New Stack. Analysis and adaptation: ForgeNEX.