Cloud Parts

KubeVirt

Adds virtual machines to Kubernetes as ordinary resources, so VMs and containers share one cluster, one API and one set of tools.

What it is
Virtual machines,Container orchestration
Type
Open source
Made by
Cloud Native Computing Foundation
License
Apache 2.0
Facts checked
6 October 2026
Website Source code

What it is

KubeVirt is an add-on that teaches an existing Kubernetes cluster to run full virtual machines. It adds custom resources: a VirtualMachine you can stop and start while its disks persist, and the VirtualMachineInstance that represents it while it runs. When an instance is created, virt-controller makes a normal pod for it, and Kubernetes schedules that pod like any other. On the chosen node, the virt-handler DaemonSet tells the pod’s virt-launcher container to start the VM, which it does through a libvirt daemon inside the pod running QEMU with KVM. The VM process therefore lives inside the pod’s cgroups and namespaces, and Kubernetes handles scheduling, networking and storage while KubeVirt adds only the virtualisation.

Disks come from persistent volume claims, or from a “container disk”, a VM image shipped in a container registry. The companion Containerized Data Importer (CDI) adds a DataVolume resource that fills a volume from a URL, a registry, an upload or a clone of another volume. A running VM can live-migrate to another node, started by creating a VirtualMachineInstanceMigration object, as long as its volumes are shared (ReadWriteMany). Red Hat started KubeVirt in 2016 and builds OpenShift Virtualization on it; SUSE, NVIDIA, Cloudflare and CoreWeave are among its listed users. It is a CNCF incubating project, reached version 1.0 in July 2023 and now releases three times a year in step with Kubernetes.

Why teams pick it

  • One control plane for VMs and containers: the same kubectl, RBAC, GitOps, monitoring and storage classes for both
  • Runs Windows guests and other workloads that don’t fit in a container, such as CI runners or virtual desktops, next to containers
  • Live migration, snapshots, VM export and disk import through standard Kubernetes objects
  • Backed by several vendors: OpenShift Virtualization (Red Hat), SUSE’s products and others ship it

Watch out for

  • Nodes need hardware virtualisation (bare metal or nested virtualisation); a software-emulation fallback exists for testing
  • Live migration needs ReadWriteMany storage and doesn’t work with every network binding
  • More moving parts: a VM is a pod plus a libvirt and QEMU stack, and features such as disk import live in separate add-ons like CDI
  • These are full VMs with their own operating systems to patch, not lightweight sandboxes for containers

Alternatives

What all virtual machines have in common →
Amazon EC2AWSAWS’s virtual machines: pick an instance type, boot an image, and you have a server in minutes.HashiCorp VagrantCommercialA command-line tool that builds the same development virtual machine for everyone from a `Vagrantfile` kept in the repo.

How it fits with other technologies

A small VM booted from a container disk · yaml

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vm-cirros
spec:
  runStrategy: Always            # Halted keeps it defined but stopped
  template:
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk: { bus: virtio }
        memory:
          guest: 128Mi
      volumes:
        - name: containerdisk
          containerDisk:              # a VM image in a container registry
            image: quay.io/kubevirt/cirros-container-disk-demo

See it in a real stack

No architecture uses KubeVirt yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2016–2023

By 2016 containers and Kubernetes were becoming the standard way to run new software, but most companies still had large estates of virtual machines that couldn’t easily be rewritten. Running both meant two platforms, two teams and two sets of tools. At the end of 2016 engineers at Red Hat asked whether VMs could run inside containers and be deployed by Kubernetes.

Their answer was to extend Kubernetes rather than build beside it: VMs became custom resources, each VM ran inside a pod, and Kubernetes kept doing the scheduling, networking and storage. The first release, v0.1.0, came in December 2017. KubeVirt joined the CNCF as a sandbox project in September 2019 and moved to incubating in April 2022.

Version 1.0 shipped in July 2023, after the project switched from monthly releases to three a year to match Kubernetes. KubeVirt now sits under OpenShift Virtualization and products from SUSE, Oracle and others.

Why it’s built this way

A VM is a pod
Wrapping each VM in a pod lets the existing scheduler, network plugins and volume drivers handle it, so KubeVirt only adds the virtualisation and not a second cluster manager.
Extend the API with custom resources
Defining VMs as Kubernetes objects, with controllers that reconcile them, means users manage VMs through the same API and tools as everything else.
Reuse libvirt and QEMU
Instead of writing a new hypervisor, each virt-launcher pod runs the mature libvirt and QEMU stack, which brings broad guest support, including Windows, and features such as live migration.

Timeline

  1. 2016

    Project starts at Red Hat at the end of the year

  2. 2017

    First release, v0.1.0, in December

  3. 2019

    Accepted into the CNCF as a sandbox project (September)

  4. 2022

    Moves to CNCF incubating (April)

  5. 2023

    KubeVirt 1.0; releases now follow the Kubernetes cadence

Sources10 · facts checked 6 October 2026

Improve this page on GitHub