KubeVirt is an open-source extension to Kubernetes that lets you run traditional virtual machines alongside containers, managed through the same Kubernetes APIs, the same kubectl command line, and the same RBAC and namespace model you already use for Deployments and Pods. Instead of running a separate hypervisor stack next to your cluster, a VM becomes just another object Kubernetes knows how to schedule, observe and govern.

Why KubeVirt exists

Most organizations don't get to choose a clean, container-only world. Databases with restrictive licensing, legacy line-of-business applications, specialized appliances, and workloads that simply weren't built for containers all still need to run somewhere — and "somewhere" is usually a separate virtualization platform with its own console, its own access model and its own blind spots relative to the Kubernetes clusters next to it.

KubeVirt closes that gap. It doesn't try to replace your hypervisor's low-level virtualization technology — under the hood it still uses the Linux KVM hypervisor and QEMU, the same components most enterprise virtualization platforms are built on. What it changes is the control plane: instead of a hypervisor-specific manager, a virtual machine is defined as a Kubernetes custom resource, scheduled by the standard Kubernetes scheduler, and operated on with the standard Kubernetes API.

How KubeVirt works

KubeVirt adds two key custom resources to a cluster: VirtualMachine, which defines the desired state of a VM (its disk, CPU, memory, and networking, plus whether it should be running), and VirtualMachineInstance, the running instance of that definition — conceptually similar to how a Deployment manages Pods.

Underneath, three components do the work:

  • virt-controller watches VirtualMachine and VirtualMachineInstance objects and reconciles their desired state, the same reconciliation pattern every Kubernetes controller uses.
  • virt-handler runs as a DaemonSet on every node, acting as the node-local agent that starts, stops and monitors VMs on that node.
  • virt-launcher runs inside a pod — one per VM — and wraps a libvirtd/QEMU process that actually executes the virtual machine. From Kubernetes' point of view, the VM's compute footprint is a pod, which is why it can be scheduled, resource-limited and observed exactly like any other workload.

Because a VM's compute footprint is a pod, VM storage attaches through standard PersistentVolumeClaims, and VM networking attaches through the cluster's normal CNI plugin (with multi-NIC or dedicated network attachments handled through Multus where needed). Nothing about the surrounding platform — storage classes, network policy, RBAC — has to be re-learned for virtual machines.

KubeVirt vs. traditional virtualization

The technical capability is largely the same — you're still running full VMs on KVM/QEMU. What changes is the operating model: one inventory, one access-control system, and one observability stack for both containers and VMs, instead of stitching two platforms together with scripts and tribal knowledge about which team owns which console.

Common use cases

  • Legacy applications that can't be easily containerized but need to sit in the same environment, namespace and network as the containerized services around them.
  • Licensing-constrained software — databases or appliances licensed per VM or per hypervisor, where a VM is the path of least resistance.
  • Gradual containerization — moving workloads onto Kubernetes infrastructure now, and containerizing the application itself later, without a second migration.
  • Bastion hosts, jump boxes and management VMs that platform teams already run alongside cluster workloads.

How a Kubernetes management platform builds on KubeVirt

KubeVirt itself is an API — it gives Kubernetes the ability to run VMs, but day-to-day operators still need a console: somewhere to create a VM from a golden image, take a snapshot before a risky change, migrate a VM off a draining node, or see VM and container capacity side by side. That's the layer a Kubernetes management platform like AetherVirt adds on top of KubeVirt — golden images and flavors, snapshot and migration workflows, in-browser console access, and the same RBAC and audit logging already applied to containers, now covering VMs too.