ReadingResearchRadarInvestment framework
Sign in / Sign up
← Back to reading
NewsMaterial4 min readDisconfirmAI Editorial

KubeVirt Maintainers: GPU Scheduling and Confidential Computing Will Follow a Kubernetes-Native Path

Vladik Romanovsky, Senior Engineer at Red Hat and KubeVirt maintainer, outlines the design principles for the project's next phase: replacing virtualization-specific patches with Kubernetes-native mechanisms (dynamic resource allocation, confidential VMs, structured plugins) to unify GPU coordination for AI workloads and model protection under the cluster's existing APIs. AMD SEV-SNP has entered beta in v1.9, IBM Secure Execution has reached GA, while Intel TDX remains in alpha.

2026-10-26 22:00 GMT+8

In a project roadmap statement published in October 2026, KubeVirt maintainer Vladik Romanovsky brought a design principle that has guided the project for a decade back into focus: prioritizing Kubernetes-native solutions and mechanisms over building isolated virtualization workarounds. This principle takes on specific meaning as AI workloads enter the KubeVirt ecosystem—GPU scheduling, confidential computing, VMs as sandboxes, and scalability are all migrating from KubeVirt-specific implementations to the APIs and controller systems already present in Kubernetes clusters.

Regarding GPU resource allocation, KubeVirt v1.9 has advanced the functionality for VMs to claim GPUs via Kubernetes Dynamic Resource Allocation (DRA) to the beta stage. Previously, GPU allocation relied on the device-plugin mechanism, requiring KubeVirt to handle device hot-plugging at the virtualization layer itself. Romanovsky stated that this same claim model is being extended to generic host devices, SR-IOV network devices, and CPUs; the near-term goal is to allow a single VM to request a GPU, NIC, and CPU simultaneously, with Kubernetes allocating them as a coordinated set of resources. Additionally, the project is exploring enabling KubeVirt to automatically generate ResourceClaim objects based on VM specifications and vendor policies, rather than requiring users to write them manually. Romanovsky also cited examples such as Swap in Kubernetes, ImageVolumes, and volume populators, noting that these mechanisms allow the team to remove KubeVirt-specific paths and directly reuse capabilities already available in the cluster. Nvidia engineers have also participated in adapting KubeVirt to run on new hardware such as Grace Hopper, Grace Blackwell, and Vera Rubin; related features were first developed in the Accelerated Infrastructure Enablement working group before being gradually merged upstream.

Sign in / Sign up
ReadingResearchRadarInvestment framework

Confidential computing represents another native path currently being implemented. Users desire to run sensitive AI applications and models on shared infrastructure while protecting data and model weights during execution. KubeVirt is expanding support for confidential VMs and exploring integration with remote attestation and secret-release services, including Trustee from the Confidential Containers project. Fan Zhang, co-lead of the KubeVirt AIE and Confidential Compute working groups, pointed out that for AI, the trust boundary should cover the entire execution path—including CPUs, accelerators, and the interconnects between them; workload owners must verify the environment through attestation before releasing sensitive data or model keys. In v1.9, feature gates for AMD SEV and SEV-SNP graduated to beta, Intel TDX support remains in alpha, IBM Secure Execution reached General Availability (GA), and Arm CCA is still under development.

At the architecture level, Romanovsky explained why the KubeVirt core is deliberately protected: a feature will not land in the kubevirt/kubevirt repository unless the community is willing to support it long-term for everyone without breaking clusters that are already running. Structured plugins offer a solution following the Kubernetes extensibility philosophy—users can write complete features outside the core while still receiving KubeVirt API guarantees. Plugins are cluster-scoped objects containing domain hooks, node hooks, and admission controls; domain changes can be implemented using CEL expressions, or sidecars when hooks require external state. Administrators can view and control these. This mechanism was in the alpha stage in v1.9.

The pluggable virtualization stack represents a deeper architectural change. libvirt, QEMU, and KVM remain the default stack for KubeVirt; v1.8 added an in-tree Hypervisor Abstraction Layer and the Microsoft MSHV backend (alpha). Harshit Gupta, Senior Software Engineer at Microsoft, stated that their proposal aims to fully decouple KubeVirt from the underlying virtualization stack through a pluggable virtualization framework, allowing Cloud Hypervisor, OpenVMM, or Firecracker to run as external backends without forking KubeVirt. This work corresponds to KubeVirt Enhancement Proposal #82 and is currently ongoing.

Romanovsky explicitly marked the boundaries of this roadmap: these features are at different stages of discussion and implementation, and whether they enter future versions depends on community review, integration, and testing. He also noted that the CNCF sponsored the publication of this article.

For AI infrastructure teams, the practical significance of this roadmap is that if DRA, confidential computing, and structured plugins mature as expected, GPU coordinated allocation, model key protection, and custom virtualization backends will be managed uniformly under Kubernetes-native APIs, rather than scattered across KubeVirt-specific workarounds. This reduces operational complexity but also means teams must accept the progressive process of features moving from alpha to GA, as well as the impact of community governance rhythms on delivery timelines.

Sources

  • thenewstack.ioThe New Stack↗
Continue researching →