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@redhat.com>
---
 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

On Mon, Jan 17, 2022 at 04:39:09PM +0100, Peter Krempa wrote:
> 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@redhat.com>
> ---
>  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:

So, a user is trying to figure out which mode is on (with only a basic knowledge
of libvirt) and they need to pick a daemon of interest. I think we can improve
what you wrote a little by incorporating a more generic bit with the followin:

systemctl list-units -t service -t socket

...
virtnwfilterd.service loaded active running Virtualization nwfilter daemon
virtqemud.service     loaded active running Virtualization qemu daemon
-----------------------------------
...
virtinterfaced-admin.socket  loaded active listening Libvirt interface admin socket
virtinterfaced-ro.socket     loaded active listening Libvirt interface local read-only socket
virtinterfaced.socket        loaded active listening Libvirt interface local socket
virtlockd.socket             loaded active listening Virtual machine lock manager socket
virtlxcd-admin.socket        loaded active listening Libvirt lxc admin socket
virtlxcd-ro.socket           loaded active listening Libvirt lxc local read-only socket
virtlxcd.socket              loaded active listening Libvirt lxc local socket
virtnetworkd-admin.socket    loaded active listening Libvirt network admin socket
virtnetworkd-ro.socket       loaded active listening Libvirt network local read-only socket
virtnetworkd.socket          loaded active listening Libvirt network local socket
virtnodedevd.socket          loaded active listening Libvirt nodedev local socket
virtnwfilterd-admin.socket   loaded active running   Libvirt nwfilter admin socket
virtnwfilterd-ro.socket      loaded active running   Libvirt nwfilter local read-only socket
virtnwfilterd.socket         loaded active running   Libvirt nwfilter local socket
virtproxyd.socket            loaded active listening Libvirt proxy local socket
virtqemud-admin.socket       loaded active running   Libvirt qemu admin socket
virtqemud-ro.socket          loaded active running   Libvirt qemu local read-only socket
virtqemud.socket             loaded active running   Libvirt qemu local socket
virtsecretd.socket           loaded active listening Libvirt secret local socket
virtstoraged.socket          loaded active listening Libvirt storage local socket

If they see a bunch of virt- prefixed sockets/services, then they're running
with in the modular mode.

Otherwise the patch is fine.

Erik

> +
> +   #. 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
> 

On Tue, Jan 18, 2022 at 16:22:08 +0100, Erik Skultety wrote:
> On Mon, Jan 17, 2022 at 04:39:09PM +0100, Peter Krempa wrote:
> > 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@redhat.com>
> > ---
> >  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:
> 
> So, a user is trying to figure out which mode is on (with only a basic knowledge
> of libvirt) and they need to pick a daemon of interest. I think we can improve
> what you wrote a little by incorporating a more generic bit with the followin:

The 'Modular driver daemons' section of this document actually
enumerates which daemons libvirt provides, so I can link to that ...

> 
> systemctl list-units -t service -t socket
> 
> ...
> virtnwfilterd.service loaded active running Virtualization nwfilter daemon
> virtqemud.service     loaded active running Virtualization qemu daemon
> -----------------------------------
> ...
> virtinterfaced-admin.socket  loaded active listening Libvirt interface admin socket
> virtinterfaced-ro.socket     loaded active listening Libvirt interface local read-only socket
> virtinterfaced.socket        loaded active listening Libvirt interface local socket
> virtlockd.socket             loaded active listening Virtual machine lock manager socket
> virtlxcd-admin.socket        loaded active listening Libvirt lxc admin socket
> virtlxcd-ro.socket           loaded active listening Libvirt lxc local read-only socket
> virtlxcd.socket              loaded active listening Libvirt lxc local socket
> virtnetworkd-admin.socket    loaded active listening Libvirt network admin socket
> virtnetworkd-ro.socket       loaded active listening Libvirt network local read-only socket
> virtnetworkd.socket          loaded active listening Libvirt network local socket
> virtnodedevd.socket          loaded active listening Libvirt nodedev local socket
> virtnwfilterd-admin.socket   loaded active running   Libvirt nwfilter admin socket
> virtnwfilterd-ro.socket      loaded active running   Libvirt nwfilter local read-only socket
> virtnwfilterd.socket         loaded active running   Libvirt nwfilter local socket
> virtproxyd.socket            loaded active listening Libvirt proxy local socket
> virtqemud-admin.socket       loaded active running   Libvirt qemu admin socket
> virtqemud-ro.socket          loaded active running   Libvirt qemu local read-only socket
> virtqemud.socket             loaded active running   Libvirt qemu local socket
> virtsecretd.socket           loaded active listening Libvirt secret local socket
> virtstoraged.socket          loaded active listening Libvirt storage local socket
> 
> If they see a bunch of virt- prefixed sockets/services, then they're running
> with in the modular mode.

This seems a bit excessive though.

> 
> Otherwise the patch is fine.