Since we are at a transition period where some users may be running
monolithic libvirtd and others already the modular topology we need a
section that allows users to figure out which is in use.
This will be particularly important in the document about enabling
logging, as the active log file depends on which daemon is in use.
Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
---
docs/daemons.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/docs/daemons.rst b/docs/daemons.rst
index c8ae3b0cef..1446c1f92c 100644
--- a/docs/daemons.rst
+++ b/docs/daemons.rst
@@ -435,6 +435,53 @@ host first.
$ systemctl enable virtproxyd-tls.socket
$ systemctl start virtproxyd-tls.socket
+Checking whether modular/monolithic mode is in use
+==================================================
+
+To determine whether modular or monolithic mode is in use on a host running
+``systemd`` as the init system you can take the following steps:
+
+#. Check whether the modular daemon infrastructure is in use
+
+ First check whether the modular daemon you are interested in is running:
+
+ #. Check ``.socket`` for socket activated services
+
+ ::
+
+ # systemctl is-active virtqemud.socket
+ active
+
+ #. Check ``.service`` for always-running daemons
+
+ ::
+
+ # systemctl is-active virtqemud.service
+ active
+
+ If either of the above is ``active`` your system is using the modular daemons.
+
+#. Check whether the monolithic daemon is in use
+
+ #. Check ``libvirtd.socket``
+
+ ::
+
+ # systemctl is-active libvirtd.socket
+ active
+
+ #. Check ``libvirtd.service`` for always-running daemon
+
+ ::
+
+ # systemctl is-active libvirtd.service
+ active
+
+ If either of the above is ``active`` your system is using the monolithic
+ daemon.
+
+#. To determine which of the above will be in use on the next boot of the system,
+ substitute ``is-enabled`` for ``is-active`` in the above examples.
Proxy daemon
============
--
2.34.1
