KubeVirt
Run and manage KVM virtual machines as first-class Kubernetes workloads.
- Category: Orchestration & Scheduling
- CNCF maturity: Incubating
- Language: Go (
go.mod:1,go 1.24.0) - License: Apache-2.0 (
LICENSE:1) - Repository: kubevirt/kubevirt
- Documented at commit:
55a003d(main HEAD, 2026-06-24)
What it is
KubeVirt is a Kubernetes add-on that runs full virtual machines next to containers on the same cluster. It defines a set of custom resources, the central one being VirtualMachineInstance (VMI), and a set of controllers that turn those resources into running KVM/QEMU guests. A VM becomes a regular Kubernetes object that you create, watch, and delete with kubectl.
Each VM runs inside its own Pod. KubeVirt places libvirt and QEMU inside that Pod, so the guest inherits Kubernetes scheduling, Pod networking, persistent volumes, and eviction. There is no separate hypervisor control plane to operate alongside the cluster.
It is for teams that already run Kubernetes and need to keep workloads that cannot be containerised, such as legacy VM images, appliances, or guests that need a full kernel. The project's stated design rule is to prefer Kubernetes conventions over virtualization conventions when the two conflict (see v1.0 announcement).
When to use it
- You run Kubernetes and have workloads that must stay as VMs (legacy images, full-kernel guests, appliances) but want one control plane for both.
- You want VMs to share the cluster's scheduler,
NetworkPolicy,StorageClass, and monitoring stack instead of a separate virtualization platform. - You are consolidating off a standalone hypervisor and want a Kubernetes-native target.
- It is a weaker fit when you do not run Kubernetes already: standing up a cluster only to host VMs adds a layer a traditional hypervisor would not.
- It is a weaker fit when nodes cannot expose hardware virtualization and you cannot accept software emulation's performance cost.
In this deep-dive
- History: origin, milestones, and why it exists.
- Architecture: components and how requests flow.
- Adoption & Ecosystem: who runs it and what surrounds it.
- Internals: the code paths that matter, read from source.
- Getting Started: install and a first working setup.