virtqemud and virtproxyd roles

virtqemud 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 domains, consoles, disks attached to a domain, CPU model negotiation, or migration handoff.

systemctl status virtqemud.service virtqemud.socket
journalctl -u virtqemud -n 200
virsh -c qemu:///system list --all

virtproxyd: when the proxy matters

virtproxyd is relevant when clients connect through compatibility sockets or remote transports that need an old public face but a new internal route.

Typical cases include:

• Existing automation that still assumes libvirtd socket names.
• Remote TLS/TCP entry points.
• Mixed estates where some hosts are modular and others are not.

Common sockets to verify

ss -lx | grep -E "virtqemud|virtproxyd|libvirt"
systemctl list-sockets "virt*" "libvirtd*"

If the proxy socket is live but the driver daemon is not, clients may connect successfully and then fail during the real operation.

A good troubleshooting sequence

1. Confirm the URI the client used.
2. Check whether that URI lands on a proxy or directly on virtqemud.
3. Read the matching systemd unit and journal.
4. Only then inspect the domain XML or network/storage side effects.