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

libvirt

Virtualisation Linux Kvm Qemu Security Selinux Api

libvirt is an open-source library, daemon, and toolset that provides a unified, stable API for managing virtualisation infrastructure — virtual machines, storage volumes, virtual networks, and host devices — across multiple hypervisor backends. It was originally written by Daniel Berrange at Red Hat and has since become the standard virtualisation management layer on Linux, underpinning KubeVirt, OpenStack Nova, oVirt/RHEV, Proxmox, and the virsh / virt-manager administrative tools. The core value proposition is hypervisor abstraction: the same libvirt API call creates a VM on KVM/QEMU, Xen, LXC, or (historically) VMware ESXi, without the management layer caring about the underlying implementation. In practice, the KVM/QEMU driver is the dominant use case on Linux; the others are progressively less-maintained but remain supported. libvirt communicates with hypervisors through driver-specific mechanisms — with QEMU, it generates the full QEMU command line from the domain XML definition and manages the QEMU process lifecycle, communicating with the running VM through the QEMU Monitor Protocol (QMP) over a Unix socket.

All libvirt-managed resources are described in domain XML: a declarative specification of every aspect of a VM — CPU topology (sockets, cores, threads, NUMA topology, CPU pinning), memory (size, hugepages, NUMA binding), boot order and firmware (UEFI or BIOS, Secure Boot, SMM), disk devices (virtio-blk, virtio-scsi, IDE with format qcow2/raw and source as file, block device, or network), network interfaces (virtio-net, bridge, SR-IOV VF, macvtap, VDPA), PCI and USB device passthrough, graphics (VNC, SPICE), video, serial/console, watchdog, RNG, and TPM devices (either passthrough of the host’s physical TPM, or an emulated software TPM via swtpm). The XML is the authoritative source of truth; virsh dumpxml <domain> outputs the running domain’s effective configuration, and virsh define domain.xml creates a persistent VM from a specification. Storage is managed through storage pools (directories, LVM VGs, NFS mounts, Ceph RBD clusters, iSCSI targets) and storage volumes allocated from them; network connectivity through virtual networks (virsh net-*) that libvirt manages as Linux bridges, VLAN-tagged bridges, macvtap, or OVS bridges, with iptables/nftables rules and dnsmasq instances for NAT networks managed automatically. The daemon architecture in libvirt 6.0+ uses a modular daemon model — separate daemons per driver (virtqemud, virtnetworkd, virtstoraged, virtnodedevd, etc.) instead of the monolithic libvirtd — improving isolation and privilege separation at the cost of a more complex service dependency graph.

libvirt’s security integration is its most relevant feature in the context of this glossary. The sVirt security model automatically assigns each QEMU process a unique SELinux MCS label pair (system_u:system_r:svirt_t:s0:c<X>,c<Y>) at VM start time, and dynamically relabels all disk images and devices the VM will access to match those categories (system_u:object_r:svirt_image_t:s0:c<X>,c<Y>). The SELinux policy is written so that a QEMU process in one category pair cannot access files labelled with a different category pair — meaning a compromised VM process cannot read another VM’s disk image even if it escapes its own namespace and gains access to the host filesystem as the qemu user. On Ubuntu and Debian, the equivalent mechanism uses AppArmor profiles via the virt-aa-helper tool, which generates a per-VM AppArmor profile at startup and loads it dynamically. libvirt also integrates with firewalld over D-Bus to open and close ports for VM network access, with the host TPM (both physical passthrough and swtpm-emulated software TPM for Secure Boot + measured boot in guests), and with UEFI firmware images (OVMF for standard UEFI, OVMF with SEV or TDX configuration for SEV-SNP and TDX confidential VMs). KubeVirt uses libvirt as its hypervisor management layer — the virt-launcher pod runs a libvirtd instance and communicates with it via the libvirt API, making libvirt the execution engine that both conventional KubeVirt VMs and KubeVirt confidential VMs ultimately run through.

Related

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.

LSM (Linux Security Module)

Linux Kernel Security Mac Selinux Apparmor
Linux Security Modules (LSM) is a hook-based framework integrated into the Linux kernel since 2.6 (2003) that provides a general mechanism for implementing Mandatory Access Control (MAC) without modifying the core kernel. Its origin is the NSA’s presentation of SELinux at the 2001 Linux Kernel Summit: Linus Torvalds accepted the need for flexible access control but refused to hardcode a single security model, directing instead the development of a framework into which any security model could be plugged. The result is LSM: a set of strategically placed hook functions throughout the kernel’s execution paths — over 240 hooks in recent kernels — at points where security-relevant decisions occur: file open, process creation, capability checks, socket operations, IPC access, memory mapping, and more. Each hook is a call into the currently active security module(s), which examine the operation’s context and return allow or deny. The core kernel enforces whatever the security module decides.

RHCOS (Red Hat Enterprise Linux CoreOS)

Linux Security Openshift Immutable Selinux Luks Tpm Boot
RHCOS (Red Hat Enterprise Linux CoreOS) is the operating system that runs on every OpenShift control plane and worker node. It is not a general-purpose Linux distribution — it is a purpose-built, immutable, container-optimised OS designed to run exclusively as a managed node in an OpenShift cluster. Its security posture is architecturally different from a hardened RHEL installation: rather than hardening a mutable system through configuration management, RHCOS makes the OS layer structurally resistant to modification by design. The root filesystem’s /usr tree is read-only (enforced at mount time by rpm-ostree and, in recent versions, by composefs over the OSTree object store), /etc and /var are writable but managed exclusively by the Machine Config Operator (MCO), and no package manager is available at runtime for ad-hoc software installation. An operator who wants to change any node-level configuration — kernel arguments, sysctl settings, systemd units, certificates, kubelet configuration — creates a MachineConfig object in the OpenShift API; the MCO renders it into an Ignition config, applies it to the target MachineConfigPool (master, worker, or custom), and drains and reboots the affected nodes in a rolling fashion. Direct SSH access to nodes for configuration changes is explicitly unsupported and actively discouraged — oc debug node/<name> is the supported emergency access path, dropping into a privileged container on the node’s host namespaces under audit.