KubeVirt 1.8: Why Kubernetes Is Ready to Kill Legacy Virtualization

The KubeVirt 1.8 release landed at KubeCon + CloudNativeCon Europe 2026 — and this is not another incremental patch with a polished changelog and two bug fixes dressed up as features. This is the release that rewrites the architectural DNA of the project. Four years under the CNCF umbrella, and the team finally cut the cord that kept KubeVirt locked to KVM. This is no longer just a VM runner inside Kubernetes — this is a legitimate cloud native virtualization platform that can look VMware in the eye without blinking.

TL;DR: Quick Takeaways

• The Hypervisor Abstraction Layer (HAL) breaks the hard KVM dependency — KubeVirt can now work with alternative VMM backends
• Intel TDX Attestation and PCIe NUMA topology awareness make KubeVirt a serious candidate for AI/HPC and confidential enterprise workloads
• Passt is now a core component, and live NAD updates without VM restarts are finally a reality
• Tests at 8,000 VMs and Portworx running 5,000+ in production confirm: this is no longer an experiment

The Great Migration: Why 2026 Is the Year Everyone Is Running From Proprietary Platforms

The story of kubevirt vs vmware 2026 is a story about money, burnout, and vendor lock-in paranoia. When Broadcom swallowed VMware and rewrote the licensing playbook, thousands of companies simultaneously opened Google and typed vmware alternative open source. Budgets slammed shut, DevOps engineers grabbed their heads, and CNCF projects suddenly got the attention of people who used to say the word container with mild contempt. KubeVirt became the obvious hope: organizations already running Kubernetes saw a chance to stop building parallel infrastructure and fold VM workloads into an already working control plane.

# Example CRD for a VirtualMachine in KubeVirt
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: legacy-app-vm
spec:
  running: true
  template:
    spec:
      domain:
        cpu:
          cores: 4
        memory:
          guest: 8Gi

What KubeVirt Actually Is and Why It Matters for K8s Shops

Running VMs on Kubernetes is exactly what KubeVirt enables through Custom Resource Definitions, embedding virtual machines into the native cluster API. A VM becomes a Kubernetes object — managed and scheduled by the same tools as pods: kubectl, Helm, GitOps pipelines. No second control plane sitting next to ArgoCD, no vCenter quietly billing you on the side. A single control plane that understands both containers and VMs is the core pitch for organizations stuck between two infrastructure worlds.

Who Already Migrated and What Actually Happened

Arm, CoreWeave, Kubermatic — those names appeared in CNCF reports back in 2022 when the project entered incubation. The list has grown since, and Pure Storage through its Portworx unit publicly claimed 5,000+ virtual machines in production alongside reported cost reduction migrating from vmware to kubevirt of up to 50%. The number is aggressive and obviously PR-polished, but even with a generous skepticism discount applied, the trend is clear: migrating VMs to KubeVirt stopped being a bold experiment and became a mainstream infrastructure strategy.

Breaking Free from KVM: The Hypervisor Abstraction Layer Explained

The flagship feature of this release — the kubevirt hypervisor abstraction layer — is an architectural decision that had been hovering in the air for a while. KubeVirt was nailed to KVM as its only hypervisor, which created obvious limits: no Linux with KVM, no KubeVirt. HAL changes the game: there is now an abstraction between KubeVirt and the hypervisor backend, KVM-first defaults remain the default but are no longer the only option. Vladik Romanovsky of Red Hat outlined this direction at KubeCon NA 2025 — in v1.8 that exploration became a concrete, working implementation.

# Conceptual HAL configuration in KubeVirt
apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
  name: kubevirt
spec:
  configuration:
    developerConfiguration:
      useEmulation: false
    hypervisorBackend:
      name: kvm        # replaceable with alternative VMM
      featureGates:
        - HypervisorAbstractionLayer

What Is a VMM and Which Backends Are Now Possible

A VMM (Virtual Machine Monitor) is the layer that directly manages hardware on behalf of a VM. QEMU/KVM held a monopoly in the KubeVirt stack, and kubevirt multi vmm support beyond QEMU is about opening the door to alternatives: cloud-hypervisor, Firecracker, and potentially other VMMs built for specific workload profiles. KubeVirt without KVM is no longer just theory — it is an officially supported direction. This matters most for bare-metal nodes in environments where KVM is unavailable or suboptimal, and for cloud providers running custom virtualization stacks.

Why This Is a Structural Shift, Not Just a Feature

Previously, vendor neutrality in KubeVirt was more of a declaration than a fact — at the hypervisor level there was no choice. HAL turns KubeVirt into a genuinely open virtualization platform where the open-source hypervisor label is an architectural reality, not a marketing sticker. This also repositions the project competitively: organizations with non-standard virtualization requirements can now build a long-term strategy around KubeVirt without hitting KVM as a hard ceiling. For CNCF graduation — a milestone Romanovsky explicitly mentioned at KubeCon NA 2025 — this is exactly the kind of maturity signal the process requires.

Hardware-Level Performance: Intel TDX and NUMA for AI Workloads

If HAL is about architectural freedom, then kubevirt confidential computing intel tdx is about enterprise-grade paranoia in the best sense. The Confidential Computing Working Group added Intel TDX Attestation support: a VM can now cryptographically prove it is running on confidential hardware. This is not we have encryption — this is hardware-level isolation proof that financial organizations, healthtech companies, and any enterprise under regulatory pressure actually require. The same release adds PCIe NUMA topology awareness, and that part is what makes AI engineers actually pay attention.

# Confidential VM configuration with Intel TDX
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      domain:
        launchSecurity:
          tdx: {}
        cpu:
          cores: 8
          numaTopologyPolicy: restricted
        memory:
          guest: 32Gi

PCIe NUMA Topology Awareness: What This Means for AI and HPC

PCIe NUMA topology awareness is about keeping GPU and memory in the same NUMA domain as the VM consuming them. Without this, you get inter-node bus latency, and your expensive GPU cluster runs below capacity for no good reason. With correct NUMA configuration, cloud native virtualization performance for AI workloads approaches what the community describes as near-native performance — the gap between bare-metal and VM environments shrinks to statistically irrelevant numbers. How to optimize KubeVirt for AI workloads now starts precisely here: NUMA configuration combined with the GPU assignment support that landed in earlier releases.

Why This Closes the Enterprise Credibility Gap

Historically, proprietary virtualization platforms won against open-source specifically on enterprise features: isolation, attestation, predictable performance. KubeVirt production readiness in 2026 is no longer a question of can KubeVirt do X. It is a question of how mature is the implementation and is there enterprise support available. Intel TDX plus NUMA is a direct and concrete answer to both questions for sensitive workloads and high-performance computing scenarios.

Network and Storage Overhaul: Live Network Updates and Smarter Backups

The engineering depth in v1.8 shows clearly in networking and storage. KubeVirt live update network attachment is now real: engineers can update Network Attachment Definition (NAD) references on running VMs without restarting them. That sounds modest until you remember that any network change previously meant downtime. For production environments with strict SLAs, this is not a convenience feature — it is a hard operational requirement. Passt, the user-space networking plugin, was also promoted from plugin to core component in the same release, signaling long-term commitment to this networking path.

# Live-update NAD reference on a running VM
kubectl patch vm my-vm --type merge -p '{
  "spec": {
    "template": {
      "spec": {
        "networks": [{
          "name": "secondary",
          "multus": {
            "networkName": "updated-nad-v2"
          }
        }]
      }
    }
  }
}'

Passt as Core: What Changes at the Architecture Level

Promoting passt to core is not just a code relocation. It means user-space networking now carries the same support commitment as the main project components. Simultaneously, KubeVirt was decoupled from NAD definitions at the virt-controller level — removing unnecessary API calls and permissions that were previously required for VM activation at scale. For a cloud-native stack running large deployments, this is not abstract optimization — it is measurable reduction of control plane pressure at the hundreds-of-VMs level.

Incremental Backup with CBT: Finally a Backup Story Worth Telling

KubeVirt incremental backup CBT (Changed Block Tracking) is what everyone building a serious backup process for Kubernetes VMs has been waiting for. The feature uses QEMU and libvirt backup capabilities to track only the blocks that changed since the last snapshot — instead of a full image copy every time, you get just the delta. In practice this means dramatically faster backup jobs and a significantly smaller storage footprint. The ContainerPath volume type also lands in v1.8, allowing container paths to be mapped directly for VM storage — framed by the team as an escape hatch for cloud provider credential injection patterns.

The Scale Realities: 8,000 VMs in Tests and 5,000 in Portworx Production

KubeVirt scale and performance 2026 is no longer a topic for speculative conference talks. The team expanded their test framework to 8,000 virtual machines, and the KubeVirt test framework 8,000 VMs run showed linear memory growth for both virt-api and virt-controller components. Linear is a good word here: it means predictable, and predictable means capacity planning becomes an engineering task rather than a guessing game. The team also committed to publishing these memory consumption figures with every release going forward.

# Approximate memory scaling estimates (v1.8 benchmarks)
# Linear growth confirmed at 8,000 VM scale

virt-api:        base 512Mi + ~1.5Mi per 100 VMs
virt-controller: base 256Mi + ~2Mi  per 100 VMs
virt-handler:    per-node, ~128Mi base + per-VM overhead

# At 8,000 VMs:
# virt-api:        ~632Mi
# virt-controller: ~1.8Gi (across replicas in production clusters)

Portworx for KubeVirt: What 5,000 VMs in Real Production Actually Means

Portworx for KubeVirt at scale is currently the most public documented example of a production deployment where KubeVirt plays a central infrastructure role rather than a backup plan. Pure Storage announced Portworx for KubeVirt at Red Hat Summit 2025, then reported running more than 5,000 virtual machines in production environments. The claimed up-to-50% cost reduction versus traditional virtualization is aggressive, but even with a healthy skepticism discount — infrastructure consolidation around a single Kubernetes control plane delivers real savings on licensing and operational overhead.

Can KubeVirt Actually Replace VMware in Production Right Now

The honest answer to can kubevirt replace vmware in production is: it depends on what you are running and for whom. For Kubernetes-first organizations with typical enterprise VM workloads, v1.8 closes many of the remaining gaps and the answer is increasingly yes. For shops critically dependent on vSphere-specific features, complex vSAN configurations, or thousands of legacy VMs with exotic requirements — this is still a migration project with planning, pain, and timeline. But the direction of travel is obvious, and each KubeVirt release shortens the distance.

What Comes Next: CNCF Graduation and the v1.9 Horizon

The team hints that the next release will be larger still — and this is coming off a v1.8 that is already substantial. CNCF graduation, explicitly mentioned by Romanovsky at KubeCon NA 2025, remains an open question, but HAL, improved scale metrics, and a growing list of production users are exactly the maturity signals that graduation requires. KubeVirt cloud native virtualization as a concept is moving from interesting experiment into serious infrastructure bet — and the community is clearly aware of the moment it is in.

FAQ

What is the Hypervisor Abstraction Layer in KubeVirt 1.8 and why does it matter?

The HAL in the kubevirt hypervisor abstraction layer is an architectural layer that separates KubeVirts core logic from the specific hypervisor backend. Before v1.8, KubeVirt was hardwired to KVM as the only supported option, with no pluggable alternative.

With HAL, KVM-first defaults remain intact but the door is open to integrate alternative VMMs like cloud-hypervisor or Firecracker. This makes KubeVirt a genuinely vendor-neutral platform and is a key step toward CNCF graduation maturity requirements.

Can you run KubeVirt without KVM after the v1.8 release?

Technically yes — HAL is built precisely for this. KubeVirt without KVM is now an officially supported direction rather than a workaround or unsupported hack.

Practically, KVM remains the most mature and battle-tested backend. Alternative VMM integrations are early-stage, and for production workloads it is worth waiting for more mature implementations and validated configurations before moving away from KVM defaults.

How does KubeVirt 1.8 improve performance for AI and HPC workloads?

Two key additions: PCIe NUMA topology awareness and GPU assignment improvements. NUMA awareness ensures GPU and memory share the same NUMA domain as the VM using them — critical for cloud native virtualization performance in AI training and inference tasks.

Combined with near-native performance benchmarks from correctly configured deployments, the gap between bare-metal and VM environments for typical ML workloads becomes minimal. Intel TDX Attestation also adds hardware-level isolation for teams processing sensitive training datasets.

What is Changed Block Tracking and why does KubeVirt need it?

KubeVirt incremental backup CBT tracks only the disk blocks that changed since the last backup snapshot — instead of copying a full VM image every time, only the delta is transferred and stored.

For production deployments running hundreds of VMs, this is the difference between backups that disrupt operations and backups that run quietly in the background. Faster execution and dramatically smaller storage footprint make CBT a foundational feature for any serious DR strategy on KubeVirt.

How production-ready is KubeVirt in 2026?

KubeVirt production readiness in v1.8 is no longer a matter of faith or optimism. Tests at 8,000 VMs with linear memory scaling, 5,000+ VMs in Portworx production, and a growing enterprise user list all point in one direction.

For Kubernetes-first organizations with standard VM workloads, KubeVirt is a mature choice. For complex legacy environments with exotic requirements, it still requires careful migration planning. But the gap with proprietary platforms is closing fast, and each release adds substantial arguments for making the switch.

Is migrating from VMware to KubeVirt worth it for cost savings alone?

Pure Storage claims up to 50% savings with cost reduction migrating from vmware to kubevirt. A realistic estimate for a typical enterprise, accounting for migration effort and team retraining, lands closer to 20–35%.

The bigger win is often not the license cost but infrastructure consolidation: one control plane instead of two parallel stacks, one set of tools, one team. For organizations already running Kubernetes, the question why are we paying for VMware separately becomes harder to answer with every KubeVirt release.