↓ Skip to main content
Le Site de François
  1. Index/

KubeVirt

Kubernetes Virtualization Kvm Cncf Openshift Confidential-Computing

KubeVirt is a CNCF project that makes Kubernetes a native hypervisor management plane, allowing KVM virtual machines to be declared, scheduled, and operated through the Kubernetes API without a separate virtualisation management layer. The motivating use case is organisational convergence: teams running a mix of legacy VM workloads and modern containerised services no longer need two separate platforms (an OpenStack or vSphere cluster for VMs, a Kubernetes cluster for containers) with separate networking, storage, RBAC, and CI/CD integration. With KubeVirt, both workload types live in the same cluster, share the same kubectl and GitOps tooling, and are subject to the same scheduling, resource quota, and network policy primitives. KubeVirt reached 1.0 in 2023 and is the engine behind Red Hat OpenShift Virtualization, the downstream product used by organisations migrating away from VMware.

KubeVirt introduces a hierarchy of Custom Resource Definitions and a set of controllers that map the VM lifecycle onto Kubernetes primitives. A VirtualMachine (VM) is the user-facing resource: it holds the VM template spec (CPU, memory, firmware, disks, NICs) and a desired running state, and acts like a Deployment for the VM — it owns a VirtualMachineInstance when running and can restart it if it terminates unexpectedly. A VirtualMachineInstance (VMI) represents a single running VM; it is the unit of scheduling, and once created it is expected to be running — deleting it is equivalent to powering it off. For each VMI, the virt-controller creates a dedicated virt-launcher pod on the scheduled node, inside which QEMU runs sandboxed in a cgroup. On every KVM-capable node, the virt-handler DaemonSet watches for VMIs scheduled to its node, manages their lifecycle by calling libvirt APIs, and keeps the cluster-side VMI object in sync with the actual domain state. Disk images and boot volumes are managed by the Containerised Data Importer (CDI) via DataVolume resources, which import, clone, or upload disk images from HTTP endpoints, container registries, or existing PVCs into PersistentVolumes that the virt-launcher pod mounts as VM disks. Live migration between nodes is supported for VMs whose disks are backed by shared storage with ReadWriteMany access mode, and is the mechanism Kubernetes uses to drain nodes without powering off VMs.

KubeVirt’s confidential computing integration ties it directly into the rest of this glossary. The spec.domain.launchSecurity field in a VMI spec activates TEE-backed isolation: setting sev or snp requests an AMD SEV or SEV-SNP confidential guest; TDX support is in active upstream development. When launchSecurity is set, QEMU passes the appropriate flags to KVM to launch the VM as a confidential guest with hardware-encrypted memory, and the resulting VM has the same attestation capabilities as any other Confidential VM — it can produce a SEV-SNP attestation report or TDX Quote. The integration with Trustee for attestation-gated secret delivery to KubeVirt confidential VMs — attested TLS from inside the guest to the KBS, LUKS unlock keys released only after attestation — is demonstrated in OpenShift Virtualization and represents the convergence point between KubeVirt’s VM management plane and the CoCo attestation stack. One important constraint: live migration is disabled for confidential VMs, since the encrypted memory cannot be transferred between hosts without the destination host holding the same TEE key material, which the hardware prevents.

Related

Confidential Containers (CoCo)

Security Confidential-Computing Kubernetes Attestation Containers Cncf
Confidential Containers (CoCo) is a CNCF sandbox project that lifts hardware confidential computing — TDX, SEV-SNP, Intel SGX, IBM Secure Execution — up to the Kubernetes pod level, providing a unified software layer that abstracts away the underlying TEE technology. Its defining trust model is unusually strict: the Kubernetes control plane, the kubelet, the container runtime, and the cloud operator are all treated as explicitly untrusted. Only the hardware itself and the workload owner’s own supply chain are in scope for trust.

KVM/QEMU

Virtualization Linux Kvm Qemu Security Libvirt Openshift Seccomp Selinux
KVM (Kernel-based Virtual Machine) and QEMU (Quick Emulator) solve different halves of the same problem and are almost always used together. KVM is a Linux kernel module that turns the kernel into a hypervisor: with Intel VT-x or AMD-V, guest CPUs run on real hardware at near-native speed and guest memory is managed through extended page tables. KVM has no device model of its own — no disk, network, or firmware emulation. QEMU supplies that in userspace (virtio, USB, VGA, ACPI) and controls KVM by issuing ioctl calls on /dev/kvm — creating VMs, mapping memory, running vCPUs via KVM_RUN — while QMP exposes external management over a Unix socket. libvirt, originally from Red Hat, sits above both: it translates domain XML into QEMU command lines and lifecycle operations. The stack is the default on Linux: RHEL ships qemu-kvm, OpenShift Virtualization runs KubeVirt (virt-launcher → libvirt → QEMU), and OpenShift Sandboxed Containers uses Kata Containers with the same hypervisor to isolate pods in micro-VMs.

Kata Containers

Containers Security Virtualization Kubernetes Cncf Oci Runtime
Kata Containers is an Open Infrastructure Foundation (OpenInfra Foundation) project that replaces the Linux namespace and cgroup isolation of a conventional container runtime with a full VM boundary, while remaining entirely compatible with the OCI runtime specification and the Kubernetes CRI. From the perspective of containerd, CRI-O, or the Kubernetes kubelet, a Kata pod is indistinguishable from a runc or crun pod — the same API calls, the same lifecycle verbs, the same pod spec — but instead of calling clone() to create a new namespace, Kata starts a lightweight virtual machine. The workload runs inside that VM with its own kernel, its own device model, and a hardware-enforced isolation boundary between itself and the host kernel. The premise is that Linux namespaces, while convenient, share the same kernel as the host: a kernel vulnerability exploitable from inside a container can affect the host and every other container running on the same node. A VM boundary means that even a full guest kernel compromise cannot directly affect the host.