Now that we have more than just the libvirtd daemon, we should be
explaining to users what they are all for & important aspects of their
configuration.
Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
---
docs/daemons.rst | 682 ++++++++++++++++++++++++++++++++++++++++++++++
docs/docs.html.in | 3 +
2 files changed, 685 insertions(+)
create mode 100644 docs/daemons.rst
diff --git a/docs/daemons.rst b/docs/daemons.rst
new file mode 100644
index 0000000000..a74b228025
--- /dev/null
+++ b/docs/daemons.rst
@@ -0,0 +1,682 @@
+===============
+Libvirt Daemons
+===============
+
+.. contents::
+
+A libvirt deployment for accessing one of the stateful drivers will require
+one or more daemons to be deployed on the virtualization host. There are a
+number of ways the daemons can be configured which will be outlined in this
+page.
+
+Architectural options
+=====================
+
+Monolithic vs modular daemons
+-----------------------------
+
+Traditionally libvirt provided a single monolithic daemon called ``libvirtd``
+which exposed support for all the stateful drivers, both primary hypervisor
+drivers and secondary supporting drivers. It also enables secure remote access
+from clients running off host.
+
+Work is underway for the monolithic daemon to be replaced by a new set of
+modular daemons ``virt${DRIVER}d``, each one servicing a single stateful
+driver. A further ``virtproxyd`` daemon will provide secure remote access, as
+well as backcompatibility for clients using the UNIX socket path of the
+monolithic daemon.
+
+The change to modular daemons should not affect API functionality used by
+management applications. It will, however, have an impact on host provisioning
+tools since there are new systemd services and configuration files to be
+managed.
+
+Currently both monolithic and modular daemons are built by default, but the RPC
+client still prefers connecting to the monolithic daemon. It is intended to
+switch the RPC client to prefer the modular daemons in the near future. At
+least 1 year after this switch (but not more than 2 years), the monolithic
+daemon will be deleted entirely.
+
+Operating modes
+---------------
+
+The libvirt daemons, whether monolithic or modular, can often operate in two
+modes
+
+* *System mode* - the daemon is running as the root user account, enabling
+ access to its full range of functionality. A read-write connection to
+ daemons in system mode **typically implies privileges equivalent to having
+ a root shell**. Suitable `authentication mechanisms <auth.html>`__ **must
+ be enabled** to secure it against untrustworthy clients/users.
+
+* *Session mode* - the daemon is running as any non-root user account,
+ providing access to a more restricted range of functionality. Only client
+ apps/users running under **the same UID are permitted to connect**, thus a
+ connection does not imply any elevation of privileges.
+
+ Not all drivers support session mode and as such the corresponding
+ modular daemon may not support running in this mode
+
+
+Monolithic driver daemon
+========================
+
+The monolithic daemon is known as ``libvirtd`` and has historically been the
+default in libvirt. It is configured via the file ``/etc/libvirt/libvirtd.conf``
+
+
+Monolithic sockets
+------------------
+
+When running in system mode, ``libvirtd`` exposes three UNIX domain sockets, and
+optionally, one or two TCP sockets
+
+* ``/var/run/libvirt/libvirt-sock`` - the primary socket for accessing libvirt
+ APIs, with full read-write privileges. A connection to this socket gives the
+ client privileges that are equivalent to having a root shell. This is the
+ socket that most management applications connect to by default.
+
+* ``/var/run/libvirt/libvirt-sock-ro`` - the secondary socket for accessing
+ libvirt APIs, with limited read-only privileges. A connection to this socket
+ gives the ability to query the existance of objects and monitor some aspects
+ of their operation. This is the socket that most management applications
+ connect to when requesting read only mode. Typically this is what a
+ monitoring app would use.
+
+* ``/var/run/libvirt/libvirt-admin-sock`` - the administrative socket for
+ controlling operation of the daemon itself (as opposed to drivers it is
+ running). This can be used to dynamically reconfigure some aspects of the
+ daemon and monitor/control connected clients.
+
+* ``TCP 16509`` - the non-TLS socket for remotely accessing the libvirt APIs,
+ with full read-write privileges. A connection to this socket gives the
+ client privileges that are equivalent to having a root shell. Since it does
+ not use TLS, an `authentication mechanism <auth.html>`__ that provides
+ encryption must be used. Only the GSSAPI/Kerberos mechanism is capable of
+ satisfying this requirement. In general applications should not use this
+ socket except for debugging in a development/test environment.
+
+* ``TCP 16514`` - the TLS socket for remotely accessing the libvirt APIs,
+ with full read-write privileges. A connection to this socket gives the
+ client privileges that are equivalent to having a root shell. Access control
+ can be enforced either through validation of `x509 certificates
+ <tlscerts.html>`__, and/or by enabling an `authentication mechanism
+ <auth.html>`__.
+
+NB, some distros will use ``/run`` instead of ``/var/run``.
+
+When running in session mode, ``libvirtd`` exposes two UNIX domain sockets
+
+* ``$XDG_RUNTIME_DIR/libvirt/libvirt-sock`` - the primary socket for accessing
+ libvirt APIs, with full read-write privileges. A connection to this socket
+ does not alter the privileges that the client already has. This is the
+ socket that most management applications connect to by default.
+
+* ``$XDG_RUNTIME_DIR/libvirt/libvirt-admin-sock`` - the administrative socket
+ for controlling operation of the daemon itself (as opposed to drivers it is
+ running). This can be used to dynamically reconfigure some aspects of the
+ daemon and monitor/control connected clients.
+
+Notice that the session mode does not have a separate read-only socket. Since
+the clients must be running as the same user as the daemon itself, there is
+not any security benefit from attempting to enforce a read-only mode.
+
+``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs,
+such as ``/run/user/$UID``.
+
+
+Monolithic Systemd Integration
+------------------------------
+
+When the ``libvirtd`` daemon is managed by ``systemd`` a number of desirable
+features are available, most notably socket activation.
+
+Libvirt ships a number of unit files for controlling libvirtd
+
+* ``libvirtd.service`` - the main unit file for launching the libvirtd daemon
+ in system mode. The command line arguments passed can be configured by
+ editting ``/etc/sysconfig/libvirtd``. This is typically only needed to control
+ the use of the auto shutdown timeout value. It is recommended that this
+ service unit be configured to start on boot. This is because various
+ libvirt drivers support autostart of their objects. If it is known that
+ autostart is not required, this unit can be left to start on demand.
+
+* ``libvirtd.socket`` - the unit file corresponding to the main read-write
+ UNIX socket ``/var/run/libvirt/libvirt-sock``. This socket is recommended to
+ be started on boot by default.
+
+* ``libvirtd-ro.socket`` - the unit file corresponding to the main read-write
+ UNIX socket ``/var/run/libvirt/libvirt-sock-ro``. This socket is recommended
+ to be started on boot by default.
+
+* ``libvirtd-admin.socket`` - the unit file corresponding to the administrative
+ UNIX socket ``/var/run/libvirt/libvirt-admin-sock``. This socket is
+ recommended to be started on boot by default.
+
+* ``libvirtd-tcp.socket`` - the unit file corresponding to the TCP 16509 port
+ for non-TLS remote access. This socket should not be configured to start on
+ boot until the administrator has configured a suitable authentication
+ mechanism.
+
+* ``libvirtd-tls.socket`` - the unit file corresponding to the TCP 16509 port
+ for TLS remote access. This socket should not be configured to start on boot
+ until the administrator has deployed x509 certificates and optionally
+ configured a suitable authentication mechanism.
+
+The socket unit files are newly introduced in 5.6.0. On newly installed hosts
+the UNIX socket units should be enabled by default. When upgrading an existing
+host from a previous version of libvirt, the socket unit files will be masked
+if libvirtd is currently configured to use the ``--listen`` argument, since the
+``--listen`` argument is mutually exclusive with use of socket activation.
+
+When systemd socket activation is used a number of configuration settings in
+``libvirtd.conf`` are no longer honoured. Instead these settings must be
+controlled via the system unit files
+
+* ``listen_tcp`` - TCP socket usage is enabled by starting the
+ ``libvirtd-tcp.socket`` unit file.
+
+* ``listen_tls`` - TLS socket usage is enabled by starting the
+ ``libvirtd-tls.socket`` unit file.
+
+* ``tcp_port`` - Port for the non-TLS TCP socket, controlled via the
+ ``ListenStream`` parameter in the ``libvirtd-tcp.socket`` unit file.
+
+* ``tls_port`` - Port for the TLS TCP socket, controlled via the
+ ``ListenStream`` parameter in the ``libvirtd-tls.socket`` unit file.
+
+* ``listen_addr`` - IP address to listen on, independently controlled via the
+ ``ListenStream`` parameter in the ``libvirtd-tcp.socket`` or
+ ``libvirtd-tls.socket`` unit files.
+
+* ``unix_sock_group`` - UNIX socket group owner, controlled via the
+ ``SocketGroup`` parameter in the ``libvirtd.socket`` and
+ ``libvirtd-ro.socket`` unit files
+
+* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the
+ ``SocketMode`` parameter in the ``libvirtd-ro.socket`` unit file
+
+* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via
+ the ``SocketMode`` parameter in the ``libvirtd.socket`` unit file
+
+* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the
+ ``SocketMode`` parameter in the ``libvirtd-admin.socket`` unit file
+
+* ``unix_sock_dir`` - directory in which all UNIX sockets are created
+ independently controlled via the ``ListenStream`` parameter in any of the
+ ``libvirtd.socket``, ``libvirtd-ro.socket`` and ``libvirtd-admin.socket`` unit
+ files.
+
+Systemd releases prior to version 227 lacked support for passing the activation
+socket unit names into the service. When using these old versions, the
+``tcp_port``, ``tls_port`` and ``unix_sock_dir`` settings in ``libvirtd.conf``
+must be changed in lock-step with the equivalent settings in the unit files to
+ensure that ``libvirtd`` can identify the sockets.
+
+
+Modular driver daemons
+======================
+
+The modular daemons are named after the driver which they are running, with
+the pattern ``virt${DRIVER}d`` and will become the default in future libvirt.
+They are configured via the files ``/etc/libvirt/virt${DRIVER}d.conf``
+
+The following modular daemons currently exist for hypervisor drivers
+
+* ``virtqemud`` - the QEMU management daemon, for running virtual machines
+ on UNIX platforms, optionally with KVM acceleration, in either system or
+ session mode
+* ``virtxend`` - the Xen management daemon, for running virtual machines
+ on the Xen hypervisor, in system mode only
+* ``virtlxcd`` - the Linux Container management daemon, for running LXC guests
+ in system mode only
+* ``virtbhyved`` - the BHyve management daemon, for running virtual machines
+ on FreeBSD with the BHyve hypervisor, in system mode.
+* ``virtvboxd`` - the VirtualBox management daemon, for running virtual machines
+ on UNIX platforms.
+
+The additional modular daemons service secondary drivers
+
+* ``virtinterfaced`` - the host NIC management daemon, in system mode only
+* ``virtnetworkd`` - the virtual network management daemon, in system mode only
+* ``virtnodedevd`` - the host physical device management daemon, in system mode
+ only
+* ``virtnwfilterd`` - the host firewall management daemon, in system mode only
+* ``virtsecretd`` - the host secret management daemon, in system or session mode
+* ``virtstoraged`` - the host storage management daemon, in system or session
+ mode
+
+
+Modular Sockets
+---------------
+
+When running in system mode, ``virt${DRIVER}d`` exposes three UNIX domain
+sockets:
+
+* ``/var/run/libvirt/virt${DRIVER}d-sock`` - the primary socket for accessing
+ libvirt APIs, with full read-write privileges. For many of the daemons, a
+ connection to this socket gives the client privileges that are equivalent to
+ having a root shell. This is the socket that most management applications
+ connect to by default.
+
+* ``/var/run/libvirt/virt${DRIVER}d-sock-ro`` - the secondary socket for
+ accessing libvirt APIs, with limited read-only privileges. A connection to
+ this socket gives the ability to query the existance of objects and monitor
+ some aspects of their operation. This is the socket that most management
+ applications connect to when requesting read only mode. Typically this is
+ what a monitoring app would use.
+
+* ``/var/run/libvirt/virt${DRIVER}d-admin-sock`` - the administrative socket for
+ controlling operation of the daemon itself (as opposed to drivers it is
+ running). This can be used to dynamically reconfigure some aspects of the
+ daemon and monitor/control connected clients.
+
+NB, some distros will use ``/run`` instead of ``/var/run``.
+
+When running in session mode, ``virt${DRIVER}d`` exposes two UNIX domain sockets
+
+* ``$XDG_RUNTIME_DIR/libvirt/virt${DRIVER}d-sock`` - the primary socket for
+ accessing libvirt APIs, with full read-write privileges. A connection to this
+ socket does not alter the privileges that the client already has. This is the
+ socket that most management applications connect to by default.
+
+* ``$XDG_RUNTIME_DIR/libvirt/virt${DRIVER}d-admin-sock`` - the administrative
+ socket for controlling operation of the daemon itself (as opposed to drivers
+ it is running). This can be used to dynamically reconfigure some aspects of
+ the daemon and monitor/control connected clients.
+
+Notice that the session mode does not have a separate read-only socket. Since
+the clients must be running as the same user as the daemon itself, there is
+not any security benefit from attempting to enforce a read-only mode.
+
+``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs,
+such as ``/run/user/$UID``.
+
+Modular Systemd Integration
+---------------------------
+
+When the ``virt${DRIVER}d`` daemon is managed by ``systemd`` a number of
+desirable features are available, most notably socket activation.
+
+Libvirt ships a number of unit files for controlling virt${DRIVER}d
+
+* ``virt${DRIVER}d.service`` - the main unit file for launching the
+ ``virt${DRIVER}d daemon`` in system mode. The command line arguments passed
+ can be configured by editting ``/etc/sysconfig/virt${DRIVER}d``. This is
+ typically only needed to control the use of the auto shutdown timeout value.
+ It is recommended that this service unit be configured to start on boot.
+ This is because various libvirt drivers support autostart of their objects.
+ If it is known that autostart is not required, this unit can be left to start
+ on demand.
+
+* ``virt${DRIVER}d.socket`` - the unit file corresponding to the main read-write
+ UNIX socket ``/var/run/libvirt/virt${DRIVER}d-sock``. This socket is
+ recommended to be started on boot by default.
+
+* ``virt${DRIVER}d-ro.socket`` - the unit file corresponding to the main
+ read-write UNIX socket ``/var/run/libvirt/virt${DRIVER}d-sock-ro``. This
+ socket is recommended to be started on boot by default.
+
+* ``virt${DRIVER}d-admin.socket`` - the unit file corresponding to the
+ administrative UNIX socket ``/var/run/libvirt/virt${DRIVER}d-admin-sock``.
+ This socket is recommended to be started on boot by default.
+
+The socket unit files are newly introduced in 5.6.0. On newly installed hosts
+the UNIX socket units should be enabled by default. When upgrading an existing
+host from a previous version of libvirt, the socket unit files will be masked
+if virt${DRIVER}d is currently configured to use the ``--listen`` argument,
+since the ``--listen`` argument is mutually exclusive with use of socket
+activation.
+
+When systemd socket activation is used a number of configuration settings in
+``virt${DRIVER}d.conf`` are no longer honoured. Instead these settings must be
+controlled via the system unit files
+
+* ``unix_sock_group`` - UNIX socket group owner, controlled via the
+ ``SocketGroup`` parameter in the ``virt${DRIVER}d.socket`` and
+ ``virt${DRIVER}d-ro.socket`` unit files
+
+* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the
+ ``SocketMode`` parameter in the ``virt${DRIVER}d-ro.socket`` unit file
+
+* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via
+ the ``SocketMode`` parameter in the ``virt${DRIVER}d.socket`` unit file
+
+* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the
+ ``SocketMode`` parameter in the ``virt${DRIVER}d-admin.socket`` unit file
+
+* ``unix_sock_dir`` - directory in which all UNIX sockets are created
+ independently controlled via the ``ListenStream`` parameter in any of the
+ ``virt${DRIVER}d.socket``, ``virt${DRIVER}d-ro.socket`` and
+ ``virt${DRIVER}d-admin.socket`` unit files.
+
+Systemd releases prior to version 227 lacked support for passing the activation
+socket unit names into the service. When using these old versions, the
+``unix_sock_dir`` setting in ``virt${DRIVER}d.conf`` must be changed in
+lock-step with the equivalent setting in the unit files to ensure that
+``virt${DRIVER}d`` can identify the sockets.
+
+
+Switching to modular daemons
+----------------------------
+
+If a host is currently set to use the monolithic ``libvirtd`` daemon and needs
+to be migrated to the monolithic daemons a number of services need to be
+changed. The steps below outline the process on hosts using the systemd init
+service.
+
+While it is technically possible todo this while virtual machines are running,
+it is recommended that virtual machines be stopped or live migrated to a new
+host first.
+
+#. Stop the current monolithic daemon and its socket units
+
+ ::
+
+ $ systemctl stop libvirtd.service
+ $ systemctl stop libvirtd{,-ro,-admin,-tcp,-tls}.socket
+
+#. Disable future start of the monolithic daemon
+
+ ::
+
+ $ systemctl disable libvirtd.service
+ $ systemctl disable libvirtd{,-ro,-admin,-tcp,-tls}.socket
+
+ For stronger protection it is valid to use ``mask`` instead of ``disable``
+ too.
+
+#. Enable the new daemons for the particular virtualizationd driver desired,
+ and any of the secondary drivers to accompany it. The following example
+ enables the QEMU driver and all the secondary drivers:
+
+ ::
+
+ $ for drv in qemu interface network nodedev nwfilter secret storage
+ do
+ systemctl unmask virt${drv}d.service
+ systemctl unmask virt${drv}d{,-ro,-admin}.socket
+ systemctl enable virt${drv}d.service
+ systemctl enable virt${drv}d{,-ro,-admin}.socket
+ done
+
+#. Start the sockets for the same set of daemons. There is no need to start the
+ services as they will get started when the first socket connection is
+ established
+
+ ::
+
+ $ for drv in qemu network nodedev nwfilter secret storage
+ do
+ systemctl start virt${drv}d{,-ro,-admin}.socket
+ done
+
+#. If connections from remote hosts need to be supported the proxy daemon
+ must be enabled and started
+
+ ::
+
+ $ systemctl unmask virtproxyd.service
+ $ systemctl unmask virtproxyd{,-ro,-admin}.socket
+ $ systemctl enable virtproxyd.service
+ $ systemctl enable virtproxyd{,-ro,-admin}.socket
+ $ systemctl start virtproxyd{,-ro,-admin}.socket
+
+ The UNIX sockets allow for remote access using SSH tunneling. If ``libvirtd``
+ had TCP or TLS sockets configured, those should be started too
+
+ ::
+
+ $ systemctl unmask virtproxyd-tls.socket
+ $ systemctl enable virtproxyd-tls.socket
+ $ systemctl start virtproxyd-tls.socket
+
+
+Proxy daemon
+============
+
+The monolithic daemon is known as ``libvirtd`` and has historically been the
+default in libvirt. It is configured via the file ``/etc/libvirt/libvirtd.conf``
+
+
+Proxy sockets
+-------------
+
+When running in system mode, ``virtproxyd`` exposes three UNIX domain sockets,
+and optionally, one or two TCP sockets. These sockets are identical to those
+provided by the traditional ``libvirtd`` so refer to earlier documentation in
+this page.
+
+When running in session mode, ``virtproxyd`` exposes two UNIX domain sockets,
+which are again identical to those provided by ``libvirtd``.
+
+Proxy Systemd Integration
+-------------------------
+
+When the ``virtproxyd`` daemon is managed by ``systemd`` a number of desirable
+features are available, most notably socket activation.
+
+Libvirt ships a number of unit files for controlling virtproxyd
+
+* ``virtproxyd.service`` - the main unit file for launching the virtproxyd
+ daemon in system mode. The command line arguments passed can be configured by
+ editting ``/etc/sysconfig/virtproxyd``. This is typically only needed to
+ control the use of the auto shutdown timeout value.
+
+* ``virtproxyd.socket`` - the unit file corresponding to the main read-write
+ UNIX socket ``/var/run/libvirt/libvirt-sock``. This socket is recommended to
+ be started on boot by default.
+
+* ``virtproxyd-ro.socket`` - the unit file corresponding to the main read-write
+ UNIX socket ``/var/run/libvirt/libvirt-sock-ro``. This socket is recommended
+ to be started on boot by default.
+
+* ``virtproxyd-admin.socket`` - the unit file corresponding to the
+ administrative UNIX socket ``/var/run/libvirt/libvirt-admin-sock``. This
+ socket is recommended to be started on boot by default.
+
+* ``virtproxyd-tcp.socket`` - the unit file corresponding to the TCP 16509 port
+ for non-TLS remote access. This socket should not be configured to start on
+ boot until the administrator has configured a suitable authentication
+ mechanism.
+
+* ``virtproxyd-tls.socket`` - the unit file corresponding to the TCP 16509 port
+ for TLS remote access. This socket should not be configured to start on boot
+ until the administrator has deployed x509 certificates and optionally
+ configured a suitable authentication mechanism.
+
+The socket unit files are newly introduced in 5.6.0. On newly installed hosts
+the UNIX socket units should be enabled by default. When upgrading an existing
+host from a previous version of libvirt, the socket unit files will be masked
+if virtproxyd is currently configured to use the ``--listen`` argument, since
+the ``--listen`` argument is mutually exclusive with use of socket activation.
+
+When systemd socket activation is used a number of configuration settings in
+``virtproxyd.conf`` are no longer honoured. Instead these settings must be
+controlled via the system unit files. Refer to the earlier documentation on
+the ``libvirtd`` service socket configuration for further information.
+
+
+Logging daemon
+==============
+
+The ``virtlogd`` daemon provides a service for managing log files associated
+with QEMU virtual machines. The QEMU process is given one or more pipes, the
+other end of which are owned by the ``virtlogd`` daemon. It will then write
+data on those pipes to log files, while enforcing a maximum file size and
+performing log rollover at the size limit.
+
+Since the daemon holds open anoymous pipe file descriptors, it must never be
+stopped while any QEMU virtual machines are running. To enable software updates
+to be applied, the daemon is capable of re-executing itself while keeping all
+file descriptors open. This can be triggered by sending the daemon ``SIGUSR1``
+
+Logging Sockets
+---------------
+
+When running in system mode, ``virtlogd`` exposes two UNIX domain sockets:
+
+* ``/var/run/libvirt/virtlogd-sock`` - the primary socket for accessing
+ libvirt APIs, with full read-write privileges. Access to the socket is
+ restricted to the root user.
+
+* ``/var/run/libvirt/virtlogd-admin-sock`` - the administrative socket for
+ controlling operation of the daemon itself (as opposed to drivers it is
+ running). This can be used to dynamically reconfigure some aspects of the
+ daemon and monitor/control connected clients.
+
+NB, some distros will use ``/run`` instead of ``/var/run``.
+
+When running in session mode, ``virtlogd`` exposes two UNIX domain sockets
+
+* ``$XDG_RUNTIME_DIR/libvirt/virtlogd-sock`` - the primary socket for
+ accessing libvirt APIs, with full read-write privileges. Access to the
+ socket is restricted to the unprivileged user running the daemon.
+
+* ``$XDG_RUNTIME_DIR/libvirt/virtlogd-admin-sock`` - the administrative
+ socket for controlling operation of the daemon itself (as opposed to drivers
+ it is running). This can be used to dynamically reconfigure some aspects of
+ the daemon and monitor/control connected clients.
+
+``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs,
+such as ``/run/user/$UID``.
+
+Logging Systemd Integration
+---------------------------
+
+When the ``virtlogd`` daemon is managed by ``systemd`` a number of desirable
+features are available, most notably socket activation.
+
+Libvirt ships a number of unit files for controlling virtlogd
+
+* ``virtlogd.service`` - the main unit file for launching the
+ ``virtlogd daemon`` in system mode. The command line arguments passed
+ can be configured by editting ``/etc/sysconfig/virtlogd``. This is
+ typically only needed to control the use of the auto shutdown timeout value.
+
+* ``virtlogd.socket`` - the unit file corresponding to the main read-write
+ UNIX socket ``/var/run/libvirt/virtlogd-sock``. This socket is recommended
+ to be started on boot by default.
+
+* ``virtlogd-admin.socket`` - the unit file corresponding to the administrative
+ UNIX socket ``/var/run/libvirt/virtlogd-admin-sock``. This socket is
+ recommended to be started on boot by default.
+
+When systemd socket activation is used a number of configuration settings in
+``virtlogd.conf`` are no longer honoured. Instead these settings must be
+controlled via the system unit files
+
+* ``unix_sock_group`` - UNIX socket group owner, controlled via the
+ ``SocketGroup`` parameter in the ``virtlogd.socket`` and
+ ``virtlogd-ro.socket`` unit files
+
+* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the
+ ``SocketMode`` parameter in the ``virtlogd-ro.socket`` unit file
+
+* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via
+ the ``SocketMode`` parameter in the ``virtlogd.socket`` unit file
+
+* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the
+ ``SocketMode`` parameter in the ``virtlogd-admin.socket`` unit file
+
+* ``unix_sock_dir`` - directory in which all UNIX sockets are created
+ independently controlled via the ``ListenStream`` parameter in any of the
+ ``virtlogd.socket`` and ``virtlogd-admin.socket`` unit files.
+
+Systemd releases prior to version 227 lacked support for passing the activation
+socket unit names into the service. When using these old versions, the
+``unix_sock_dir`` setting in ``virtlogd.conf`` must be changed in
+lock-step with the equivalent setting in the unit files to ensure that
+``virtlogd`` can identify the sockets.
+
+Locking daemon
+==============
+
+The ``virtlockd`` daemon provides a service for holding locks against file
+images and devices serving as backing storage for virtual disks. The locks
+will be held for as long as there is a QEMU process running with the disk
+open.
+
+To ensure continuity of locking, the daemon holds open anoymous file
+descriptors, it must never be stopped while any QEMU virtual machines are
+running. To enable software updates to be applied, the daemon is capable of
+re-executing itself while keeping all file descriptors open. This can be
+triggered by sending the daemon ``SIGUSR1``
+
+Locking Sockets
+---------------
+
+When running in system mode, ``virtlockd`` exposes two UNIX domain sockets:
+
+* ``/var/run/libvirt/virtlockd-sock`` - the primary socket for accessing
+ libvirt APIs, with full read-write privileges. Access to the socket is
+ restricted to the root user.
+
+* ``/var/run/libvirt/virtlockd-admin-sock`` - the administrative socket for
+ controlling operation of the daemon itself (as opposed to drivers it is
+ running). This can be used to dynamically reconfigure some aspects of the
+ daemon and monitor/control connected clients.
+
+NB, some distros will use ``/run`` instead of ``/var/run``.
+
+When running in session mode, ``virtlockd`` exposes two UNIX domain sockets
+
+* ``$XDG_RUNTIME_DIR/libvirt/virtlockd-sock`` - the primary socket for
+ accessing libvirt APIs, with full read-write privileges. Access to the
+ socket is restricted to the unprivileged user running the daemon.
+
+* ``$XDG_RUNTIME_DIR/libvirt/virtlockd-admin-sock`` - the administrative
+ socket for controlling operation of the daemon itself (as opposed to drivers
+ it is running). This can be used to dynamically reconfigure some aspects of
+ the daemon and monitor/control connected clients.
+
+``$XDG_RUNTIME_DIR`` commonly points to a per-user private location on tmpfs,
+such as ``/run/user/$UID``.
+
+Locking Systemd Integration
+---------------------------
+
+When the ``virtlockd`` daemon is managed by ``systemd`` a number of desirable
+features are available, most notably socket activation.
+
+Libvirt ships a number of unit files for controlling virtlockd
+
+* ``virtlockd.service`` - the main unit file for launching the
+ ``virtlockd daemon`` in system mode. The command line arguments passed
+ can be configured by editting ``/etc/sysconfig/virtlockd``. This is
+ typically only needed to control the use of the auto shutdown timeout value.
+
+* ``virtlockd.socket`` - the unit file corresponding to the main read-write
+ UNIX socket ``/var/run/libvirt/virtlockd-sock``. This socket is recommended
+ to be started on boot by default.
+
+* ``virtlockd-admin.socket`` - the unit file corresponding to the administrative
+ UNIX socket ``/var/run/libvirt/virtlockd-admin-sock``. This socket is
+ recommended to be started on boot by default.
+
+When systemd socket activation is used a number of configuration settings in
+``virtlockd.conf`` are no longer honoured. Instead these settings must be
+controlled via the system unit files
+
+* ``unix_sock_group`` - UNIX socket group owner, controlled via the
+ ``SocketGroup`` parameter in the ``virtlockd.socket`` and
+ ``virtlockd-ro.socket`` unit files
+
+* ``unix_sock_ro_perms`` - read-only UNIX socket permissions, controlled via the
+ ``SocketMode`` parameter in the ``virtlockd-ro.socket`` unit file
+
+* ``unix_sock_rw_perms`` - read-write UNIX socket permissions, controlled via
+ the ``SocketMode`` parameter in the ``virtlockd.socket`` unit file
+
+* ``unix_sock_admin_perms`` - admin UNIX socket permissions, controlled via the
+ ``SocketMode`` parameter in the ``virtlockd-admin.socket`` unit file
+
+* ``unix_sock_dir`` - directory in which all UNIX sockets are created
+ independently controlled via the ``ListenStream`` parameter in any of the
+ ``virtlockd.socket`` and ``virtlockd-admin.socket`` unit files.
+
+Systemd releases prior to version 227 lacked support for passing the activation
+socket unit names into the service. When using these old versions, the
+``unix_sock_dir`` setting in ``virtlockd.conf`` must be changed in
+lock-step with the equivalent setting in the unit files to ensure that
+``virtlockd`` can identify the sockets.
diff --git a/docs/docs.html.in b/docs/docs.html.in
index 004f099a9f..142c79bfa9 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -18,6 +18,9 @@
<dt><a href="migration.html">Migration</a></dt>
<dd>Migrating guests between machines</dd>
+ <dt><a href="daemons.html">Daemons</a></dt>
+ <dd>Overview of the daemons provided by libvirt</dd>
+
<dt><a href="remote.html">Remote access</a></dt>
<dd>Enable remote access over TCP</dd>
--
2.24.1
