Daemon-owned sockets and systemd activation

How libvirtd accepts local, TCP, and TLS connections on systemd-based hosts.

section 04 / 14

manual group: virtualization support

living notes: enabled

deep links: enabled

Reference core

verify upstream ↗

libvirtd supports traditional daemon-owned sockets and systemd socket activation. With socket activation, systemd owns the listening endpoints and starts the service when a client connects.

When systemd socket activation is active, do not start libvirtd with --listen. TCP and TLS listeners are enabled through their corresponding socket units.

systemctl start libvirtd-tls.socket

systemctl start libvirtd-tcp.socket

An inactive libvirtd.service is not automatically a fault. Inspect the socket units and the active connection URI before treating the daemon as unavailable.

Living manual · why this matters

Why can an inactive service still be healthy?

With systemd socket activation the listening endpoint exists independently of the service process. A client connection can cause systemd to start libvirtd on demand and pass the already-open socket to it. Troubleshooting therefore starts with both the .socket and .service units, not the service alone.

Operator checks

$ systemctl status libvirtd.socket libvirtd.service$ systemctl status libvirtd-ro.socket libvirtd-admin.socket$ ss -lx | grep libvirt$ virsh -c qemu:///system uri$ journalctl -u libvirtd.socket -u libvirtd.service -n 100

What to notice

Do not combine --listen with systemd socket activation.
TCP and TLS listeners are separate socket units in the monolithic model.
On modular hosts, inspect virtqemud and virtproxyd sockets instead of assuming libvirtd owns the endpoint.

Open topology decoder →Diagnose a connection →

Deep reference

Keep going without losing the layer.

all docs →

Daemonslibvirtd command-line optionsThese are the libvirtd command line switches operators still run into on classic deployments, compatibility wrappers, and older automation. Listen mode Use listen only when the host is intentionally exposing traditional DaemonsSocket activation versus traditional daemon modeSystemd socket activation starts the relevant libvirt daemon only when a client connects. Traditional mode keeps the service process running all the time. How socket activation behaves With socket activation, the .socket Daemonsvirtqemud and virtproxyd rolesvirtqemud manages QEMU/KVM guests. virtproxyd exists mostly so older clients and URI expectations still work even after the daemon split. virtqemud: where guest work happens Use virtqemud logs when a failure touches doma Remote libvirtRemote TLS, TCP, and auth basicsRemote libvirt access can travel over SSH or over TLS/TCP. SSH is usually the simplest path. TLS/TCP is the right fit when you want a managed API endpoint, certificate identity, and central auth policy. Transport choices TroubleshootingGuest start failure: evidence-first triagePreserve the first error. Repeated start attempts can rotate logs, alter locks, and bury the original denial beneath secondary failures. Capture the failed transaction Check dependencies in order Classify the failure bef TroubleshootingTroubleshooting playbookUse the same order every time: confirm the URI, confirm the socket, identify the owning daemon, then inspect XML or policy. First response Permissions and polkit If root works and an unprivileged operator fails, check lo

Manual index Living lab Commands