What libvirtd actually does

How libvirtd fits between clients, libvirt drivers, QEMU/KVM, guests, networks, and storage.

section 03 / 14

manual group: virtualization support

living notes: enabled

deep links: enabled

Reference core

verify upstream ↗

libvirtd is the traditional server-side daemon for the libvirt virtualization management system. It accepts requests from clients such as virsh, virt-install, graphical management tools, and applications using libvirt language bindings.

Through libvirt drivers, the daemon manages virtualized guests and supporting resources including virtual networks, storage pools, volumes, host devices, secrets, and migration operations.

libvirtd is not a hypervisor. On a QEMU/KVM host, KVM provides kernel virtualization and QEMU executes the virtual-machine process. Libvirt supplies the stable management API and persistent resource model around them.

virsh / libvirt application
        |
connection URI
        |
libvirtd
        |
libvirt driver
        |
QEMU/KVM + guest resources

Running QEMU guests do not normally depend on the continued lifetime of the management daemon. Restarting libvirtd does not ordinarily terminate running guests.

Living manual · why this matters

Where is libvirtd in the virtualization stack?

Clients talk to libvirt through a connection URI. Libvirt dispatches management operations through drivers. On QEMU/KVM systems the QEMU driver controls QEMU processes while KVM supplies hardware-assisted CPU and memory virtualization. Virtual networks, storage, secrets, host devices, migration and domain XML all sit around that same management contract.

Operator checks

$ virsh uri$ virsh version$ virsh capabilities$ virsh list --all$ virsh dumpxml DOMAIN

What to notice

A successful API connection does not prove a guest can boot.
Persistent domain XML and the live QEMU process are related but distinct state.
Network, storage and security failures often occur below a healthy libvirt client connection.

Walk the request path →Read architecture →

Deep reference

Keep going without losing the layer.

all docs →

libvirtd Overviewlibvirtd overview and the modern daemon modellibvirtd is the traditional monolithic server side daemon for the libvirt virtualization management system. It accepts libvirt client requests and coordinates the drivers that manage virtual machines and related virtuali Architecture & ConceptsControl plane, drivers, and execution planeLibvirt is an API and driver framework. It normalizes lifecycle, storage, network, and host operations while hypervisors such as QEMU/KVM perform guest execution. Request path This separation explains why a successful AP Architecture & ConceptsFingerprint the libvirt Daemon TopologyDo not infer the active libvirt control plane from the distribution name or installed packages. Use the daemon topology decoder to classify observed systemd socket evidence before restarting a service. Classic monolithic Architecture & ConceptsModular daemons contextLibvirt split the historical all in one daemon into smaller services so each subsystem could be isolated, restarted, and permissioned more cleanly. Why libvirt split the daemon The monolithic daemon handled many unrelate Architecture & ConceptsOperator Change RehearsalAn operator rehearsal turns a proposed command into a reviewable state transition. Use the interactive rehearsal before a consequential libvirt change to expose missing evidence without touching a daemon. Establish the c Architecture & ConceptsOperator Training DrillsWhy drills exist The interactive surfaces in this manual are not puzzles for their own sake. They are short operator drills. Their job is to reinforce ordering, command composition, and dependency awareness in the same w

Manual index Living lab Commands

LIBVIRTD(8)DESCRIPTIONlibvirtd.com

DESCRIPTION