KubeVirt Update Adds Support for Additional Backend Hypervisors

March 26, 2026 Mike Vizard CNCF incubating projects, ContainerPath volume, Hypervisor Abstraction Layer, incremental backup KubeVirt, Intel TDX Attestation, KubeCon Europe 2026, Kubernetes 1.35 support, KubeVirt AI applications, KubeVirt multi-hypervisor support, KubeVirt v1.8, KVM on Kubernetes, passt binding KubeVirt, PCIe NUMA Kubernetes, Ryan Hallisey NVIDIA, software-defined infrastructure 2026, virt-controller scalability, virtual machine isolation, vLLM KubeVirt

by Mike Vizard

An update to KubeVirt, an open source project that was originally created to enable IT teams to encapsulate Kernel-based virtual machines (KVMs) in a container, has now been extended to provide support for other types of backend hypervisors.

Announced this week at the KubeCon + CloudNativeCon Europe conference, the Hypervisor Abstraction Layer in version 1.8 of KubeVirt will enable support for additional types of virtual machines beyond KVM.

The latest update also adds support for version 1.35 of Kubernetes and Intel TDX Attestation to enable confidential computing that is used to encrypt data in memory.

Additionally, Version 1.8 of KubeVirt now supports PCIe NUMA topology awareness, which is often needed to deploy artificial intelligence (AI) applications. It also now includes an incremental backup tool and support for ContainerPath volume to enable IT teams to map containers to specific storage resources for virtual machines.

Finally, the `passt` binding has been promoted from a plugin to a core binding to enable networks to be reconfigured without having to restart a virtual machine, while at the same time improving performance by decoupling network access device (NAD) definitions to reduce application programming interface (API) calls made by virt-controller.

Ryan Hallisey, a senior software engineer and technical lead at NVIDIA and a maintainer of KubeVirt, said the project has evolved over the years to enable IT teams to deploy more high-performance applications using virtual machines that are deployed on a Kubernetes cluster.

In fact, tests show the KubeVirt control plane performs well even as VMI counts grow. For example, when comparing a 100 VMI job to an 8000 VMI job, the average virt-api memory only grows from 140MB to 170MB and average virt-controller memory only grows from 65MB to 1400MB.

Originally developed by Red Hat, KubeVirt, since 2019, has been advanced under the auspices of the Cloud Native Computing Foundation (CNCF). It is still an incubating-level project that has not yet officially graduated, but the update cadence is now set at three times a year to align better with Kubernetes, noted Hallisey.

Other goals also include adding a plug-in capability that will make it simpler to add resources to a Kubernetes pod and developing a live-migration capability to make it simpler to move virtual machines from one physical host to another, noted Hallisey.

Nevertheless, many IT teams are running KubeVirt to reduce the total cost of IT by running monolithic applications designed to run on a hypervisor alongside container-native applications running on Kubernetes clusters. That approach eliminates the need to support two distinct types of platforms to run both classes of applications.

It’s not clear to what degree other providers of virtual machine hypervisors might one day officially support KubeVirt. However, there are tools that make it simpler to convert an application from one virtual machine to another.

Most Kubernetes clusters are deployed on top of virtual machines to ensure isolation, but it’s also feasible to encapsulate a virtual machine in a container to make it possible to run legacy applications on Kubernetes. The challenge, as always, is determining which legacy applications to move as the volume of cloud-native applications being built and deployed continues to steadily increase.