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@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: > > 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.
