OPTIONS
libvirtd command-line options
The supported daemon switches and what each changes.
section 05 / 14
manual group: virtualization support
living notes: enabled
deep links: enabled
Reference core
verify upstream ↗- -h, --help
- Display command-line usage and exit.
- -d, --daemon
- Run in the background and write the daemon PID file.
- -f, --config FILE
- Read daemon configuration from FILE instead of the default location.
- -l, --listen
- Enable traditional TCP/IP listening. Do not use this option when systemd socket activation owns the listeners.
- -p, --pid-file FILE
- Write the daemon PID to FILE.
- -t, --timeout SECONDS
- Exit after an idle period when no clients are connected and no domains are running.
- -v, --verbose
- Enable verbose daemon messages.
- --version
- Display libvirtd version information and exit.
Living manual · why this matters
Which options actually change behavior?
Most libvirtd flags control process startup, configuration selection, listener ownership or diagnostics. They do not configure domains, networks or storage; those resources are managed through libvirt APIs, XML and clients such as virsh.
Operator checks
$ libvirtd --help$ libvirtd --verbose$ libvirtd --config /etc/libvirt/libvirtd.conf$ systemctl cat libvirtd.serviceWhat to notice
- --listen is a startup-mode choice, not a generic 'enable networking' switch.
- --timeout interacts with on-demand activation expectations.
- --config changes the daemon configuration path; driver configuration such as qemu.conf remains a separate concern.
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 domaRemote 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 choicesReferenceFiles, 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 | CompReferenceLibvirt ecosystem toolsLibvirt is an API ecosystem, not only virsh. Choose the tool that owns the task while keeping libvirt definitions as the common control surface. | Tool | Use | | | | | virt install | Define and install guests | | virt ma