Fingerprint the libvirt Daemon Topology

Do 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 path

The historical libvirtd daemon combines hypervisor and secondary drivers behind the traditional /run/libvirt/libvirt-sock endpoint. On a systemd host, socket activation may own the listener even when the service is not continuously active.

Modular direct path

The modular architecture splits drivers into daemons such as virtqemud, virtnetworkd, and virtstoraged. QEMU clients can connect to the virtqemud socket while network and storage requests cross separate daemon boundaries.

Compatibility proxy path

virtproxyd preserves the traditional libvirt socket for clients and forwards requests to the appropriate modular daemon. A reachable compatibility endpoint therefore does not prove that the downstream QEMU driver is healthy.

Conflicting evidence

Treat simultaneous monolithic and modular ownership signals as ambiguous until systemctl status, socket triggers, and ss -lxnp identify the listener. Do not enable, disable, or restart competing units to discover ownership by trial and error.

Minimum inspection set

systemctl is-active libvirtd.socket virtproxyd.socket virtqemud.socket
systemctl list-sockets 'libvirt*' 'virt*'
ss -lxnp | grep -E 'libvirt|virtqemu'
virsh -c qemu:///system uri