BUGS
Reporting problems
Where libvirt and distribution-specific problems should be reported.
section 09 / 14
manual group: virtualization support
living notes: enabled
deep links: enabled
Reference core
verify upstream ↗Bugs in libvirt or libvirtd should be reported through the upstream libvirt project or through the operating-system or vendor package that supplied libvirt. libvirtd.com is an independent reference and learning site, not the upstream bug tracker.
Living manual · why this matters
Where is the failure actually owned?
A symptom that appears through virsh may originate in libvirt itself, the distribution package, QEMU, the kernel/KVM layer, storage, networking, security policy or guest configuration. Good bug reports identify the failing layer and include versions, URI, daemon model, relevant XML and logs without leaking secrets.
Operator checks
$ virsh version$ libvirtd --version$ uname -r$ virsh uri$ journalctl -u libvirtd -u virtqemud --since -15mWhat to notice
- Reproduce before collecting a huge unrelated log bundle.
- Redact secrets, private keys and sensitive guest data.
- Distribution packaging problems may belong with the vendor even when the failing binary is libvirt.
Deep reference
Keep going without losing the layer.
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 .socketDaemonsvirtqemud 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 domaTroubleshootingGuest 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 befTroubleshootingTroubleshooting 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 loReferenceFiles, sockets, and service unitsThis page is the quick lookup table for the names operators tend to forget during an incident. Common systemd units | Unit | Purpose | | | | | libvirtd.service | Historical compatibility daemon | | libvirtd.socket | Comp