KubeVirt is a Kubernetes add-on that runs full virtual machines as native cluster workloads, alongside containers. VMs are defined declaratively as Custom Resources and scheduled, networked, and stored using the same primitives as Pods. Under the hood each VM is a QEMU/KVM process managed by libvirt, wrapped in a regular Pod — so it benefits from Kubernetes scheduling, namespaces, RBAC, services, and storage.

It exists to bridge two worlds: workloads that can't (yet) be containerized — legacy apps, Windows, appliances, kernels needing full isolation — can live in the same cluster and CI/CD flow as your containers, instead of a separate hypervisor stack.

KubeVirt is installed and reconciled by the virt-operator. Its runtime components run in the kubevirt namespace:

The mental model maps onto Kubernetes:

KubeVirt ships an operator + a CR that triggers the actual install:

On bare-metal distros like k3s it works out of the box once kvm and vhost_net modules are loaded on the nodes. Most useful deployments also install CDI (see below) for disk image management.

virtctl is the companion CLI for the VM-specific operations kubectl can't do (console, VNC, image upload, migration). Grab the binary from the releases page or install it as a kubectl plugin via krew:

A minimal VM booting a CirrOS container disk with cloud-init:

spec.template is the VMI spec (analogous to a Pod template). domain describes the virtual hardware: CPU, memory, disks, and interfaces.

spec.runStrategy controls the VM's desired power state (mutually exclusive with the older boolean spec.running):

Lifecycle is driven with virtctl (or kubectl virt):

Inspect with plain kubectl:

Deleting a VMI stops/destroys that running instance; deleting the VM removes the definition entirely.

virtctl create vm scaffolds manifests, which pairs well with instance types:

To expose a VM through a Kubernetes Service, label the VMI template so the pod is selectable, then create the Service (or use the shortcut):

Service types ClusterIP (default), NodePort, and LoadBalancer are supported — see the Kubernetes Service concept.

A disk device in the domain references a volume by name. Common volume sources:

Disk bus is typically virtio (best performance); disks can also be presented as lun, cdrom, or carry a serial. Volumes can be hot-plugged into a running VM with virtctl addvolume/removevolume.

CDI is the companion project that gets real disk images into PVCs. A DataVolume is a higher-level object that provisions a PVC and populates it — importing from a URL/registry, cloning another PVC, or receiving an upload.

Reference it from a VM as a dataVolume volume, or inline it as a dataVolumeTemplates entry so the VM owns its disk's lifecycle. Other source types: registry (container image), pvc (clone), blank, and upload. Upload a local image directly:

Each interface in domain.devices.interfaces binds to a network. The default is the pod network via a binding method:

Secondary networks attach via Multus + a NetworkAttachmentDefinition:

Interfaces can also be hot-plugged at runtime. Standard Kubernetes NetworkPolicy applies to VMI pods.

Move a running VM between nodes without downtime (memory is copied while it runs, then control hands over). Requires the LiveMigration feature gate and, crucially, ReadWriteMany (RWX) storage so both nodes can access the disk — e.g. Rook/Ceph or Longhorn.

Or declaratively:

Migration is what makes node maintenance (drain/upgrade) non-disruptive for VMs.

With a CSI driver that supports VolumeSnapshotClass, you can snapshot a VM's disks and configuration:

Restore (stop the VM first):

Even without a snapshot-capable storage class, the VM's configuration is still captured.

Rather than repeating CPU/memory and device tuning in every VM, factor them out into reusable resources (similar to T-shirt sizes + OS profiles):

KubeVirt can even infer the right instance type/preference from a labeled boot volume (inferFromVolume). A community set of common instance types and preferences can be deployed ready-made. On creation the referenced spec is snapshotted into a ControllerRevision, so later edits to the instance type don't silently change running VMs.

KubeVirt is the engine behind larger platforms like OpenShift Virtualization. It composes naturally with the rest of a cluster — define VMs as YAML manifests in GitOps, give them RWX storage for migration, and manage them with kubectl/virtctl. See also general Virtual Machine concepts.