[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