libvirtd overview and the modern daemon model

libvirtd 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 virtualization resources.

What libvirtd is

Client programs such as virsh, virt-install, Cockpit, and applications using libvirt bindings connect to a libvirt daemon through a connection URI. On a host using the monolithic architecture, libvirtd is that daemon.

For QEMU/KVM guests, libvirt uses its QEMU driver to manage QEMU processes and KVM-backed virtual machines. libvirtd is therefore part of the management plane; it is not the hypervisor itself.

virsh / libvirt application
        |
connection URI
        |
libvirtd
        |
libvirt driver
        |
QEMU/KVM, networks, storage, devices

Monolithic versus modular daemons

Modern libvirt can replace the single libvirtd process with multiple modular daemons. QEMU management is handled by virtqemud; virtual networks by virtnetworkd; storage pools by virtstoraged; secrets by virtsecretd; and other drivers have corresponding daemons.

virtproxyd can provide compatibility for clients that expect the traditional libvirtd socket or need remote TCP/TLS proxying. It is the proxy layer; libvirtd itself should not be described as a compatibility wrapper around the modular daemons.

A host normally uses either the monolithic daemon model or the modular daemon model for a given deployment. Inspect the installed socket and service units instead of assuming which architecture is active.

Control path

Classic monolithic QEMU/KVM host:

virsh -> libvirt-sock -> libvirtd -> QEMU driver -> QEMU/KVM guest

Typical modular QEMU/KVM host:

virsh -> virtqemud-sock -> virtqemud -> QEMU driver -> QEMU/KVM guest

A compatibility or remote path can include virtproxyd before the driver daemon.

Quick verification

virsh uri
systemctl status libvirtd.socket libvirtd.service
systemctl status virtqemud.socket virtqemud.service
systemctl status virtproxyd.socket virtproxyd.service
ss -lx | grep libvirt

Units that do not exist on a particular distribution can be ignored. The important question is which socket accepts the client connection and which daemon owns the driver used by the URI.

Daemon lifetime and running guests

Restarting the management daemon does not normally terminate already-running guests. QEMU processes continue running independently of the daemon process, and persistent guest definitions are rediscovered when management returns.

When not to blame the daemon

A working client connection does not prove every virtualization subsystem is healthy.

• Guest startup failures require domain XML, disk paths, QEMU logs, firmware, and host capability checks.
• Virtual-network failures require network XML, bridge, DHCP/DNS, forwarding, and firewall inspection.
• Storage failures require pool state, volume paths, filesystem permissions, and security labels.
• Access failures can involve Unix-socket permissions, polkit, TLS/SASL, SELinux/AppArmor, or filesystem ownership.