Version 1.8 of KubeVirt was announced at KubeCon + CloudNativeCon Europe 2026. The release is aligned with Kubernetes v1.35, and the most significant addition is a Hypervisor Abstraction Layer (HAL) that allows the project to use backends other than KVM. In an announcement post on the CNCF blog, the maintainers announced the new release, broken down by their SIGs (special interest groups): compute, networking, storage, and scale & performance.
KubeVirt is an open source CNCF project that extends Kubernetes to run traditional virtual machines alongside containerised workloads on the same platform. It adds custom resource definitions to the Kubernetes API so that VMs are treated as native objects, managed and scheduled using the same tools as containers. The project targets organisations that have adopted Kubernetes but still carry VM-based workloads that cannot easily be rewritten as containers, giving them a single control plane rather than two parallel infrastructure stacks.
KubeVirt has been tightly coupled to KVM as its underlying hypervisor until now. The new Hypervisor Abstraction Layer (HAL) allows project users to integrate alternative backends while preserving the existing KVM-first defaults. Vladik Romanovsky of Red Hat outlined this direction at KubeCon NA 2025, noting that the project was “exploring support for multiple VMMs beyond QEMU/KVM.” The v1.8 release sees that exploration turn into a concrete implementation.
There are also improvements to Confidential Computing, improving KubeVirt’s suitability for sensitive workloads. The Confidential Computing Working Group has added support for Intel TDX Attestation, allowing VMs to cryptographically certify that they are running on confidential hardware. The same release adds PCIe NUMA topology awareness alongside other resource improvements aimed at AI and HPC workloads, allowing those workloads to achieve what the community describes as near-native performance.
Turning to the networking side of the project, the user-space network connectivity binding plugin, passt , has been promoted from a plugin to a core component. Engineers can now live-update Network Attachment Definition (NAD) references without restarting VMs, enabling network changes to be applied to running VMs. The project has also decoupled KubeVirt from NAD definitions at the virt-controller level, reducing API calls and removing permissions previously required for VM activation at scale.
Storage engineering has two significant new features. The ContainerPath volume type allows container paths to be mapped directly for VM storage, with the announcement framing this as an “escape hatch” for cloud provider credential injection patterns. The second addition is Incremental Backup with Changed Block Tracking (CBT), which uses QEMU and libvirt backup capabilities to produce storage-agnostic incremental VM backups. The post claims this enables faster backups and a big reduction in storage footprint.
The scale and performance work in v1.8 includes increasing their test framework to 8,000 virtual machines. The post suggests a linear increase in memory usage for the virt-api and virt-controller components. They presented these figures as scaling estimates and indicated an intent to publish them for each release, so that memory consumption can be better understood in the context of production readiness.
Pure Storage’s Portworx unit announced Portworx for KubeVirt at Red Hat Summit 2025, positioning KubeVirt as a practical alternative hypervisor and claiming up to 50% cost reduction. The company later reported running more than 5,000 virtual machines on KubeVirt in production environments, describing how a cost mandate had driven its migration from traditional virtualisation to a KubeVirt-powered strategy.
On the benchmark front, the v1.8 release aligns with a talk scheduled at KubeCon EU 2026 by Bhumitra Nagar and Dhruv Bhatnagar of Pure Storage. Titled “KubeVirt Benchmarking at Scale: A Vendor-Neutral End-to-End Testing Framework for Cloud Native Virtualisation,” the talk presents a framework for testing KubeVirt at scale across vendors. This work responds to the same gap that the community’s own KWOK benchmarks aim to fill, but approaches it from a storage and vendor neutrality angle.
The v1.8 release represents four years of work under the aegis of the CNCF. InfoQ reported in 2022 that the project had moved to CNCF incubation status, noting that, at the time, production-level solutions were already in use at organisations including Arm, CoreWeave, and Kubermatic. Since then, the project has added GPU assignment, NUMA support, live migration, and common instance types. CloudNativeNow noted in mid-2025 that KubeVirt is “designed for teams focused on DevOps that have or want to adopt Kubernetes and also have virtual machine workloads that cannot be easily containerised.” The Hypervisor Abstraction Layer in particular positions the project to extend beyond a Linux KVM dependency, while the Confidential Computing and AI performance work addresses enterprise requirements that have historically steered organisations towards proprietary virtualisation platforms.
“It’s wonderful to see new contributors coming forward with exciting ideas and engage with the project to see them through,” the KubeVirt Community writes in the release announcement. The post also notes that “the next release is looking to be larger still.” Whether the project reaches CNCF graduation, a milestone Romanovsky mentioned at KubeCon NA 2025, depends on how that process continues to mature.
