[PATCH 1/8] docs: daemons: Add section on figuring out whether modular or monolithic daemon is in use

Peter Krempa pkrempa at redhat.com
Thu Jan 20 14:19:13 UTC 2022


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 at 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.




More information about the libvir-list mailing list