Modular daemons context

Libvirt 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 unrelated jobs: domain management, networking, storage, node devices, secrets, and remote access. Splitting that work reduces blast radius and makes failures easier to localize.

Common daemons

For a QEMU/KVM-focused host, these names matter most:

• virtqemud: domain operations for QEMU guests.
• virtproxyd: compatibility proxy for clients that still expect the older socket layout.
• virtnetworkd: virtual networks, bridges, DHCP, and related XML definitions.
• virtstoraged: pools and volumes.

Practical operator rule

When a command fails, identify which daemon owns the subsystem before reading logs.

journalctl -u virtqemud -n 100
journalctl -u virtnetworkd -n 100
journalctl -u virtstoraged -n 100

That habit is faster than tailing everything and hoping the right message appears.

Migration mindset

Many fleets contain both models at once. Standardize on these questions during triage:

1. Which socket did the client connect to?
2. Which daemon owns the failing subsystem?
3. Is the host using socket activation?
4. Is virtproxyd translating older expectations for the client?