From monolithic libvirtd to modular daemons

How virtqemud, virtproxyd, virtnetworkd, virtstoraged, and other daemons divide the old monolithic role.

section 14 / 14

manual group: virtualization support

living notes: enabled

deep links: enabled

Reference core

verify upstream ↗

Current libvirt can replace the monolithic libvirtd process with modular daemons. For QEMU/KVM, virtqemud owns QEMU management. Other daemons handle networks, storage, secrets, host devices, logging, locking, and additional drivers.

virtproxyd can provide compatibility for clients expecting the traditional libvirtd socket and can proxy remote TCP/TLS connections to modular daemons. It is the compatibility and proxy layer; libvirtd itself remains the traditional monolithic daemon.

monolithic
client -> libvirtd -> driver

modular QEMU
client -> virtqemud -> QEMU driver

compatibility / remote
client -> virtproxyd -> driver daemon

Living manual · why this matters

What changed when libvirt split the monolith?

The modular architecture divides stateful drivers into dedicated daemons. On QEMU/KVM hosts virtqemud handles QEMU management; virtnetworkd and virtstoraged handle virtual networking and storage; other daemons own secrets, node devices and filters. virtproxyd supplies remote TCP/TLS proxying and backwards compatibility for clients expecting the traditional libvirtd socket.

Operator checks

$ systemctl list-unit-files 'virt*d*'$ systemctl status virtqemud.socket virtqemud.service$ systemctl status virtproxyd.socket virtproxyd.service$ ss -lx | grep libvirt$ virsh -c qemu:///system uri

What to notice

Do not assume libvirtd.service must exist or be active on a modular host.
Remote access and local QEMU management can be owned by different daemons.
Provisioning, configuration and troubleshooting must follow the daemon model actually installed on the host.

Animate daemon topology →Open modular daemon guide →Living console →

Deep reference

Keep going without losing the layer.

all docs →

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 Architecture & ConceptsQEMU, KVM, and libvirt: division of responsibilityKVM provides kernel virtualization, QEMU models the machine and devices, and libvirt supplies a stable management contract around both. Component roles | Layer | Primary responsibility | | | | | KVM | CPU and memory virt

Manual index Living lab Commands

LIBVIRTD(8)MODERN LIBVIRTlibvirtd.com

MODERN LIBVIRT