● Beta — KubeEra is in active development. Profiles are live; AI-perception measurement is rolling out.
K

KubeVirt

IncubatingApp Definition & Delivery
Open source · CNCF · CNCF Incubating · Apache-2.0

KubeVirt lets you run and manage traditional VMs (KVM-based) as native Kubernetes objects, alongside your containers, using the same API, RBAC, networking, and storage stack you already run for pods.

updated 2026-07-01

What it is

KubeVirt lets you run and manage traditional VMs (KVM-based) as native Kubernetes objects, alongside your containers, using the same API, RBAC, networking, and storage stack you already run for pods. It adds CRDs like VirtualMachine and VirtualMachineInstance, and under the hood uses libvirt/QEMU on top of KVM. The pitch is simple: stop running two separate control planes — one for containers, one for VMs — and consolidate on Kubernetes.

Who builds it and why

KubeVirt originated at Red Hat and remains heavily Red Hat-driven, but it's now a genuine multi-vendor project — SUSE (Harvester is built directly on it), Nvidia, and Platform9 are active contributors, among others. 520 contributors and continuous commits through 2026 indicate this isn't a side project someone is coasting on. The motivation is straightforward: enterprises have decades of VM workloads (legacy apps, Windows workloads, licensing-locked software) that can't be containerized easily, but they still want Kubernetes as the single control plane for scheduling, GitOps, and observability. KubeVirt is the bridge.

Production readiness signal

CNCF incubating status is a real signal here — it means multiple independent adopters and a documented governance/security process, not just "someone submitted it to CNCF." v1.8.4 as the current release reflects a long, iterative release cadence rather than a 1.0 rush. It's the foundation for Red Hat OpenShift Virtualization and SUSE Harvester — both shipped, supported products running in production at real enterprises, which is stronger evidence than star count alone. 6,932 GitHub stars is modest for a project this operationally significant, which tracks: this is infrastructure plumbing adopted through vendor distributions, not something individual developers star for fun.

Who should use this

  • Platform teams consolidating VM and container workloads onto one Kubernetes control plane to kill a second ops stack (vCenter, standalone KVM/libvirt hosts).
  • Organizations migrating off VMware post-Broadcom licensing changes who want a Kubernetes-native landing zone instead of a lateral move to another proprietary hypervisor.
  • Edge/on-prem deployments where SUSE Harvester or OpenShift Virtualization already fit the stack and KubeVirt comes bundled.
  • Teams with legacy, non-containerizable workloads (old Windows apps, license-locked appliances) that still need to live inside a Kubernetes-managed environment for compliance, scheduling, or GitOps consistency.

Who should NOT use this

  • Container-only shops with no VM workloads — this adds real operational complexity (libvirt, QEMU, nested virtualization, live migration edge cases) for zero benefit.
  • Teams on public cloud managed Kubernetes (EKS, GKE, AKS) where nodes don't support nested virtualization by default — you'll be fighting the platform before you fight KubeVirt.
  • Anyone expecting vSphere-level VM tooling maturity: vMotion-equivalent live migration, DRS-style resource balancing, and mature backup/snapshot ecosystems are still catching up in KubeVirt-land.
  • Small teams without existing Kubernetes operational maturity — running KVM/QEMU debugging on top of Kubernetes debugging is a two-skillset problem, not a simplification, if you're not already fluent in both.
  • Latency-sensitive, hypervisor-tuned workloads (HFT, real-time systems) where a dedicated, hand-tuned hypervisor will always outperform a general-purpose Kubernetes-scheduled VM.

Alternatives

  • OpenStack — the traditional open-source VM orchestration stack; more mature for pure-VM environments but no native container convergence.
  • VMware vSphere/vCenter — the incumbent enterprise hypervisor platform; more mature tooling, but proprietary and increasingly expensive since the Broadcom acquisition.
  • Proxmox VE — simpler, self-contained KVM management for smaller shops that don't need or want a Kubernetes control plane at all.

Pricing

Fully open source, Apache-2.0, no license cost. Support and hardening come via distributions: Red Hat OpenShift Virtualization and SUSE Harvester both wrap KubeVirt with commercial support contracts — evaluate those if you need an SLA rather than upstream community support.

Frequently asked

What is KubeVirt?+
KubeVirt lets you run and manage traditional VMs (KVM-based) as native Kubernetes objects, alongside your containers, using the same API, RBAC, networking, and storage stack you already run for pods. It adds CRDs like VirtualMachine and VirtualMachineInstance, and under the hood uses libvirt/QEMU on top of KVM.
Who builds KubeVirt?+
KubeVirt originated at Red Hat and remains heavily Red Hat-driven, but it's now a genuine multi-vendor project — SUSE (Harvester is built directly on it), Nvidia, and Platform9 are active contributors, among others.
Is KubeVirt production ready?+
CNCF incubating status is a real signal here — it means multiple independent adopters and a documented governance/security process, not just "someone submitted it to CNCF." v1.8.4 as the current release reflects a long, iterative release cadence rather than a 1.0 rush.
Who should use KubeVirt?+
Platform teams consolidating VM and container workloads onto one Kubernetes control plane to kill a second ops stack (vCenter, standalone KVM/libvirt hosts).
Who should not use KubeVirt?+
Container-only shops with no VM workloads — this adds real operational complexity (libvirt, QEMU, nested virtualization, live migration edge cases) for zero benefit.
What are the alternatives to KubeVirt?+
OpenStack — the traditional open-source VM orchestration stack; more mature for pure-VM environments but no native container convergence. VMware vSphere/vCenter — the incumbent enterprise hypervisor platform; more mature tooling, but proprietary and increasingly expensive since the Broadcom acquisition.
How much does KubeVirt cost?+
Fully open source, Apache-2.0, no license cost. Support and hardening come via distributions: Red Hat OpenShift Virtualization and SUSE Harvester both wrap KubeVirt with commercial support contracts — evaluate those if you need an SLA rather than upstream community support.