SYNOPSIS
Invocation syntax
The command-line form used to launch or inspect libvirtd.
section 02 / 14
manual group: virtualization support
living notes: enabled
deep links: enabled
Reference core
verify upstream ↗libvirtd [OPTION]...
Living manual · why this matters
What should you learn from the tiny synopsis?
The synopsis is intentionally terse. The useful work is understanding which options change daemon startup, which only affect diagnostics, and which conflict with systemd socket activation. The local package and service model should always be inspected before copying a launch command from another host.
Operator checks
$ libvirtd --help$ libvirtd --version$ systemctl cat libvirtd.service$ systemctl list-unit-files 'libvirtd*' 'virt*d*'What to notice
- Directly launching libvirtd is different from allowing systemd to activate it.
- Packaged service units may supply arguments or environment that an interactive shell does not.
- Modern hosts can expose equivalent libvirt functionality through modular daemon units.
Deep reference
Keep going without losing the layer.
Host & InstallationInstall libvirt and establish the first connectionInstall the smallest host stack that matches the workload, then validate through the same system URI operators will use later. Install on a RHEL family host Package groups and modular daemon defaults vary by distributionHost & InstallationKVM host readinessProve the host can accelerate guests before debugging libvirt. CPU virtualization, kernel modules, device permissions, memory, and storage all sit below the daemon. Hardware and kernel proof A bare metal host should expoDaemonslibvirtd 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 domaReferenceFiles, 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