← Blog
#Kubernetes#KubeVirt#Virtualization#Confidential Computing#Cloud Native

KubeVirt v1.8: Multi-Hypervisor Abstraction and Confidential Computing Land in Kubernetes VM Management

webhani·

KubeVirt v1.8 was announced at KubeCon + CloudNativeCon Europe 2026, aligned with Kubernetes v1.35. The headline addition is a Hypervisor Abstraction Layer (HAL) that decouples KubeVirt from KVM as its sole backend, alongside meaningful advances in Confidential Computing and NUMA-aware resource allocation for AI workloads.

What KubeVirt Does

KubeVirt is a CNCF project that extends Kubernetes to manage Virtual Machines alongside containers, using the same API surface. A VirtualMachine resource is schedulable, networkable, and governable with the same RBAC and NetworkPolicy tooling you apply to Pods.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: workload-vm
spec:
  running: true
  template:
    spec:
      domain:
        cpu:
          cores: 4
        memory:
          guest: 8Gi
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
      volumes:
        - name: rootdisk
          containerDisk:
            image: quay.io/kubevirt/ubuntu-container-disk:latest

The value proposition: manage containerized services and legacy VM workloads through a single control plane, without running a separate VMware or OpenStack layer.

Hypervisor Abstraction Layer

Before v1.8, KubeVirt was hardwired to KVM. The new Hypervisor Abstraction Layer defines a clean interface that allows alternative hypervisor backends to plug in while preserving KubeVirt's existing user-facing API.

Three practical implications:

Cross-cloud flexibility: Some cloud environments disable or restrict nested KVM. HAL makes it possible to bridge to a cloud-native hypervisor layer without forking KubeVirt or maintaining custom patches.

Non-x86 architectures: KVM is x86-centric. HAL opens the path for alternative backends on ARM64 and RISC-V platforms where KVM's feature set is constrained.

Reduced long-term vendor coupling: By defining the hypervisor surface as an interface, KubeVirt's control-plane logic becomes independent of specific hypervisor behavior — easier to maintain and easier to negotiate with hardware vendors.

KVM remains the default. Existing deployments are unchanged. HAL is additive infrastructure.

Confidential Computing with Intel TDX

The v1.8 Confidential Computing Working Group added Intel TDX (Trust Domain Extensions) Attestation support. VMs can now cryptographically attest that they are executing inside a confidential hardware environment.

What this enables:

  • Financial and healthcare data processing: Prove that sensitive computation happens only inside a Trusted Execution Environment (TEE), isolated from the host kernel and hypervisor.
  • Multi-tenant compliance: Demonstrate physical isolation between tenant workloads with a cryptographic receipt rather than a policy document.
  • Third-party data sharing: Allow external parties to verify your software stack remotely before sharing encrypted data.
# Conceptual confidential VM configuration
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      domain:
        launchSecurity:
          tdx: {}

For teams in regulated industries — finance, healthcare, government — this closes a significant gap between KubeVirt and VMware's Confidential Computing capabilities.

PCIe NUMA Topology Awareness for AI/HPC

v1.8 adds PCIe NUMA topology awareness for device allocation. When assigning GPUs or high-bandwidth NICs to VMs, KubeVirt now prefers devices on the same NUMA socket as the assigned CPUs.

Cross-socket GPU-to-CPU communication crosses the interconnect fabric, adding latency and reducing bandwidth. For distributed ML training and HPC workloads, NUMA-local placement is the difference between near-native and noticeably degraded throughput. The KubeVirt community describes the improvement as achieving "near-native performance" for AI/ML workloads on GPU-dense nodes.

If your team runs distributed training or large-scale inference inside Kubernetes-managed VMs, this change is worth testing against your current configuration.

The VMware Migration Context

Since Broadcom's acquisition of VMware, licensing changes have pushed many organizations to evaluate Kubernetes-native alternatives. KubeVirt v1.8 addresses this with:

  • Native Kubernetes API integration — GitOps, RBAC, and network policies work out of the box with VM resources
  • Enterprise-grade Confidential Computing for regulated workloads
  • Hypervisor flexibility via HAL, reducing long-term infrastructure lock-in

The remaining gaps are real: VMware's vSAN-equivalent storage management and live migration capabilities are still less mature in KubeVirt. This is a compelling option for organizations already committed to Kubernetes-centric infrastructure, less so as a drop-in feature-complete replacement for a full VMware deployment.

Practical Next Steps

If you're evaluating KubeVirt v1.8 for your environment:

  1. Test HAL with your target cloud: If you're on a provider with restricted nested KVM, the HAL abstraction is the key capability to validate early.
  2. Pilot TDX Attestation on a non-production workload: Verify that your hardware supports Intel TDX before planning a regulatory compliance story around it.
  3. Benchmark NUMA placement on GPU nodes: Run your existing distributed training benchmarks before and after enabling NUMA-aware allocation to measure the actual throughput delta.

Summary

KubeVirt v1.8 moves VM management on Kubernetes meaningfully closer to enterprise-grade. HAL removes the KVM-only architectural constraint, TDX Attestation makes regulated workloads viable, and NUMA-aware allocation gives AI teams a performance path that was previously unavailable. For any team running or evaluating Kubernetes as their single control plane for both containers and VMs, v1.8 is a significant maturity milestone worth reassessing.

← Back to Blog