KubeVirt in 2026: virtual machines as native Kubernetes workloads

"Kubernetes or VMs" was a migration decision for a decade. Reality 2026: licensed operating systems, legacy applications tied to specific kernels, specialized appliances, and workloads that genuinely benefit from hardware virtualization's isolation all still need to run — ideally on the same clusters, with the same tooling, under the same policies as your containers. KubeVirt extends the Kubernetes API with virtualization: VMs become CRDs, a running VM is wrapped in a regular pod, and the scheduler, RBAC, network policies, and GitOps pipelines you already operate apply to them too.

This article walks through the model, the 2026 releases (v1.8 and v1.9), and the parts that matter for a DevSecOps practice.

The model: VMs are pods (almost)

At the core sits the VirtualMachineInstance (VMI) — a running VM whose process lives inside a virt-launcher pod on a node that provides KVM. Control-plane components (virt-api, virt-controller, and a virt-handler DaemonSet per node) reconcile the usual CRDs:

• VirtualMachine — the long-lived definition with a runStrategy (Always/Halted/…), think Deployment for VMs.
• VirtualMachineInstance — the running instance itself.
• VirtualMachinePool (pool.kubevirt.io/v1beta1, new since v1.9) — replica sets of VMs with auto-healing and scale-in strategies.
• Instance types and preferences — reusable, validated VM shapes instead of hand-tuned XML per workload.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: feed-funnel
spec:
  runStrategy: Always
  template:
    spec:
      domain:
        devices:
          disks:
            - name: rootdisk
              disk: { bus: virtio }
            - name: cloudinit
              disk: { bus: virtio }
        resources:
          requests:
            memory: 2Gi
      volumes:
        - name: rootdisk
          containerDisk:
            image: quay.io/containerdisks/fedora:latest
        - name: cloudinit
          cloudInitNoCloud:
            userData: |
              #cloud-config
              packages: [nginx]

virtctl is the kubectl for VMs: virtctl console, virtctl ssh, virtctl migrate, virtctl evacuate-cancel (cancel an evacuation, new in v1.8).

Storage and backups

Ephemeral root disks come as containerDisks (an image in a registry — versioned, signed, scanned like any other container artifact). Persistent state goes through CDI DataVolumes that import from URLs, registries, or uploads into PVCs, with hotplugging for on-demand growth. The v1.8 release added incremental backups with Changed Block Tracking: backups built on QEMU's CBT capture only modified blocks, are storage-agnostic (no special CSI driver required), and shrink both backup windows and network traffic. A new VirtualMachineBackup API plus clone/restore VolumeNamePolicy options make DR pipelines declarative.

Networking

The default binding is MASQUERADE (pod-IP NAT). The headline change in v1.8: the passt binding was promoted to a core binding — user-space networking that runs unprivileged, supports seamless live migration, and removes the privileged helper paths of older bridge setups. For special cases there are bridge, macvtap, SR-IOV (telco/NFV fast path), and — new in v1.8 — the decoupling of KubeVirt from NetworkAttachmentDefinitions, which removes API calls and permissions from virt-controller (a real security improvement at scale).

Migration, scale, and accelerators

Live migration moves a running VM between nodes — the mechanism behind node drains, evacuations, and hardware maintenance that doesn't need a change window. It requires migratable (shared) storage and compatible networks; v1.8 even supports updating a network attachment on a running VM via migration.

Scale numbers from the v1.8 cycle: KWOK-based performance tests now run 8000 VMIs, with measured per-VMI control-plane memory costs published for capacity planning. For AI/HPC, v1.8 brought PCIe NUMA topology awareness so VMs get near-native device performance; v1.9 continued with an alpha IOMMUFD device plugin, NVIDIA Grace GPU passthrough (SMMUv3), and cross-architecture VMs (alpha: an ARM64 guest on an AMD64 host via QEMU TCG — scheduler prefers native, falls back to emulation).

What 2026 shipped

v1.8 (March 2026, aligned with Kubernetes v1.35):

• Confidential computing: the Confidential Computing Working Group delivered Intel TDX attestation — confidential VMs can now prove they run on genuine TEE hardware. This is the isolation story for untrusted tenant code inside multi-tenant clusters.
• Hypervisor Abstraction Layer: KubeVirt can integrate hypervisor backends beyond KVM while keeping KVM-first as default.
• passt as core binding; ContainerPath volumes (map container paths into VMs — an escape hatch for cloud-credential injection patterns); incremental CBT backups; rebootPolicy to make guest reboots visible to runStrategy; VirtualMachineTemplate deployable via virt-operator; new virtctl template commands (process/create/convert).

v1.9 (August 2026):

• Cross-architecture virtualization (alpha), IOMMUFD device management (alpha), Grace GPU passthrough.
• serviceAccountName in the VMI spec (VEP 250) — VMs can hold their own workload identity toward the Kubernetes API.
• VirtualMachinePool promoted to pool.kubevirt.io/v1beta1; simplified VirtualMachineBackup conditions; DRA devices read from a metadata file (VEP-10).

The DevSecOps angle

• Isolation as a tier, not a dichotomy. VMs give you a hardware-enforced boundary between tenants or between CI and production: run untrusted build workloads in VMIs on dedicated nodes, use TDX-attested confidential VMs where the threat model demands it, and keep normal containers elsewhere.
• Identity finally reaches VMs. With serviceAccountName, a VM's Kubernetes API access is RBAC-governed like any pod's — no more shared static credentials baked into images.
• Fewer privileged paths. passt eliminates privileged network helpers; the NAD decoupling strips permissions from virt-controller. Default-hardening you get by upgrading.
• Same supply chain. Root disks are registry artifacts — sign with cosign, scan them, pin digests. KubeVirt's releases are signed (git tag -v); the operator pins component images per release.
• The fleet play. With the Cluster API Provider for KubeVirt (CAPK), your workload clusters' nodes are KubeVirt VMs — one GitOps stack from bare metal (or any cloud with KVM) up through cluster lifecycle to application, as covered in the Cluster API article.

Take

KubeVirt stopped being a niche telco tool somewhere around the time it made live migration boring. In 2026 it covers confidential computing, multi-architecture fleets, storage-agnostic backups, and pod-grade identity for VMs — enough that "run it as a VM" no longer means "run it outside the platform". If your organization still carries a separate vSphere-shaped operational culture, KubeVirt is the on-ramp to collapsing it into the Kubernetes one.

Further reading

• KubeVirt user guide
• Announcing KubeVirt v1.8
• KubeVirt release notes
• kubevirt/kubevirt releases (GitHub)