manoverviewReviewed March 6, 2026

libvirtd overview and the compatibility daemon

libvirtd is the historical management daemon for libvirt. On many modern hosts it still exists, but often as a compatibility layer in front of modular daemons such as virtqemud, virtnetworkd, and virtstoraged. What libvi

libvirtdlibvirtdaemoncompatibility

libvirtd is the historical management daemon for libvirt. On many modern hosts it still exists, but often as a compatibility layer in front of modular daemons such as virtqemud, virtnetworkd, and virtstoraged.

What `libvirtd` still means

Operators still say "check libvirtd" because the name survived in service units, log habits, and documentation. That is fine as shorthand, but the actual control path may already be modular.

A useful rule is simple: treat libvirtd as the public compatibility name unless you have confirmed the host still runs a single monolithic daemon.

Control path

On a classic host, clients connect to libvirtd and the daemon fans out internally to the correct driver.

On a modular host, clients often reach virtproxyd, which forwards requests to the driver-specific daemon. For QEMU/KVM, that usually means virtqemud.

BASH

systemctl status libvirtd
systemctl status virtqemud
systemctl status virtproxyd
virsh -c qemu:///system uri

Quick verification

Use the host's own sockets and units before you guess.

BASH

systemctl list-unit-files "virt*" "libvirtd*"
ss -lx | grep libvirt
journalctl -u libvirtd -u virtqemud -u virtproxyd -n 100

If virsh works but libvirtd.service is inactive, that often means socket activation or proxying is doing the real work.

When not to blame `libvirtd`

Do not stop at the compatibility daemon when the issue is clearly lower in the stack:

Guest boot failures usually require virsh dumpxml, disk path checks, and hypervisor logs.
Network failures usually require virsh net-dumpxml, bridge inspection, and firewall review.
Access failures often come from polkit, TLS, SASL, SELinux, or filesystem labeling.

What libvirtd still means

Operators still say "check libvirtd" because the name survived in service units, log habits, and documentation. That is fine as shorthand, but the actual control path may already be modular.

A useful rule is simple: treat libvirtd as the public compatibility name unless you have confirmed the host still runs a single monolithic daemon.

Control path

On a classic host, clients connect to libvirtd and the daemon fans out internally to the correct driver.

On a modular host, clients often reach virtproxyd, which forwards requests to the driver-specific daemon. For QEMU/KVM, that usually means virtqemud.

BASH

systemctl status libvirtd
systemctl status virtqemud
systemctl status virtproxyd
virsh -c qemu:///system uri

Quick verification

Use the host's own sockets and units before you guess.

BASH

systemctl list-unit-files "virt*" "libvirtd*"
ss -lx | grep libvirt
journalctl -u libvirtd -u virtqemud -u virtproxyd -n 100

If virsh works but libvirtd.service is inactive, that often means socket activation or proxying is doing the real work.

When not to blame libvirtd

Do not stop at the compatibility daemon when the issue is clearly lower in the stack:

Guest boot failures usually require virsh dumpxml, disk path checks, and hypervisor logs.

Network failures usually require virsh net-dumpxml, bridge inspection, and firewall review.

Access failures often come from polkit, TLS, SASL, SELinux, or filesystem labeling.