Skip to content
libvirtd(8) manual
InteractiveCommands
LIBVIRTD(8)FILESlibvirtd.com

FILES

Configuration, sockets, certificates, and PID files

Important root and per-user paths used by libvirtd and its drivers.

section 07 / 14
manual group: virtualization support
living notes: enabled
deep links: enabled

Reference core

verify upstream ↗

When run as root

/etc/libvirt/libvirtd.conf
Default configuration file for root-run libvirtd.
/etc/libvirt/qemu.conf
QEMU driver configuration when the QEMU driver is installed.
/etc/libvirt/lxc.conf
LXC driver configuration when the LXC driver is installed.
/etc/libvirt/libxl.conf
libxl driver configuration when the libxl driver is installed.
/run/libvirt/libvirt-sock
Read-write local libvirt Unix socket.
/run/libvirt/libvirt-sock-ro
Read-only local libvirt Unix socket.
/etc/pki/CA/cacert.pem
Common system CA certificate path used by libvirtd TLS configuration.
/etc/pki/libvirt/servercert.pem
Common libvirtd TLS server certificate path.
/etc/pki/libvirt/private/serverkey.pem
Common libvirtd TLS private-key path.
/run/libvirtd.pid
Default PID file unless changed with --pid-file.

When run as non-root

$XDG_CONFIG_HOME/libvirt/libvirtd.conf
Per-user daemon configuration.
$XDG_CONFIG_HOME/libvirt/qemu.conf
Per-user QEMU driver configuration when present.
$XDG_RUNTIME_DIR/libvirt/libvirt-sock
Per-user libvirt Unix socket.
$HOME/.pki/libvirt/cacert.pem
Per-user TLS CA certificate.
$HOME/.pki/libvirt/servercert.pem
Per-user TLS server certificate.
$HOME/.pki/libvirt/serverkey.pem
Per-user TLS private key.
$XDG_RUNTIME_DIR/libvirt/libvirtd.pid
Per-user daemon PID file.

If XDG_CONFIG_HOME is unset, libvirt uses the user configuration hierarchy under ~/.config. Runtime paths depend on XDG_RUNTIME_DIR.

Living manual · why this matters

Which file is authoritative for the thing you are changing?

libvirtd.conf controls the monolithic daemon, while driver-specific configuration such as qemu.conf controls driver behavior. Domain, network and storage definitions have their own managed state. Socket paths and certificate locations matter during connection and permission diagnosis, but generated runtime state should not be hand-edited casually.

Operator checks

$ sudo ls -l /etc/libvirt$ sudo ls -l /run/libvirt$ systemctl cat libvirtd.socket$ virsh dumpxml DOMAIN$ virsh net-dumpxml default

What to notice

  • Configuration files and persistent libvirt object definitions are different layers.
  • Per-user session mode uses user-owned configuration and runtime locations.
  • Permissions, DAC ownership and SELinux labels can make a correct path unusable.
Domain XML workbench →Security reference →

Deep reference

Keep going without losing the layer.

all docs →
Domain XMLCPU, memory, and device modelThe domain XML describes a virtual machine contract: machine type, firmware, CPU compatibility, memory, and each presented device. Inspect the effective model CPU choices host passthrough exposes host CPU features closelDomain XMLSafe domain XML editingDomain XML is the authoritative persistent guest definition. Capture it, validate the proposed file, define it, and confirm that libvirt normalized what you intended. Change procedure virsh edit guest01 is appropriate foVirtual StorageAttach and detach guest disks safelyDevice changes have two scopes: the active QEMU process and the persistent domain definition. State the intended scope before issuing the command. Preflight Attach in both scopes Confirm the guest sees the new block deviVirtual StoragePool and volume workflowsThese workflows cover the storage commands operators reach for most often. Create and start a directory pool pool define as Use pool define as to create the pool definition before you build or start it. pool start Use poVirtual Storageqcow2, raw, and allocation behaviorDisk format affects allocation, snapshot support, portability, and failure behavior. The filesystem, storage backend, and caching mode matter as much as the filename suffix. Inspect image truth qcow2 supports sparse alloVirtual StorageStorage pools and backendsLibvirt pools abstract where guest disks live. The pool type tells you which backend owns the bytes and which operational failure modes to expect. Common pool types | Type | What it maps to | Operational note | | | | | |
← previousSIGNALSSignals accepted by the daemon and their operational effect.next →EXAMPLESSmall, copy-ready examples for daemon checks and virtualization inventory.
Manual indexLiving labCommands