On Mon, Jan 17, 2022 at 04:39:16PM +0100, Peter Krempa wrote: > Modular daemons are now the default in many new installations, thus we > need to include steps how to determine that modular daemons are used and > modular-daemon specific locations for the config files and admin URIs. > > Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx> > --- > docs/kbase/debuglogs.rst | 94 +++++++++++++++++++++++++++++++--------- > 1 file changed, 73 insertions(+), 21 deletions(-) > > diff --git a/docs/kbase/debuglogs.rst b/docs/kbase/debuglogs.rst > index fc75ef14a4..ea7c2c1d52 100644 > --- a/docs/kbase/debuglogs.rst > +++ b/docs/kbase/debuglogs.rst > @@ -87,38 +87,87 @@ more information than lack something important. > Libvirt daemons logging configuration > ===================================== > > -Persistent setting > ------------------- > +Libvirt daemons can be configured either via a config file or via the > +administration API. The configuration location depends on multiple factors. > > -The daemon configuration files location is dependent on `connection > -URI <https://libvirt.org/uri.html>`__. For ``qemu:///system``: > +Session vs. system daemons > +-------------------------- s/\.// > > +The libvirt daemons run either on ``system`` level or on ``session`` (user) s/^The// s/on/in the/g s/level/mode/g > +level, depending on the configuration of the host and the available permission > +levels. s/the available/available/ > > +The `connection URI <https://libvirt.org/uri.html>`__ influences which daemon > +the client is communicating with. s/is communicating/will communicate with "A few facts about the two runtime modes" > > -- open ``/etc/libvirt/libvirtd.conf`` in your favourite editor > -- find & replace, or set these variables: > +``system`` daemon e.g ``qemu:///system`` URI > > -:: > + * config files are usually placed in ``/etc/libvirt/`` > > - log_filters="3:remote 4:event 3:util.json 3:rpc 1:*" > - log_outputs="1:file:/var/log/libvirt/libvirtd.log" > + * ``virt-admin`` URI ending in ``/system`` should be used. > > -- save and exit > -- restart libvirtd service There should be a subsubsection for both IMO, how about: "System mode - all connection URIs will end with '/system', e.g. ``qemu:///system``` - config files are usually placed..." I deliberately left out the virt-admin part, because you're mentioning it again in 'Modular vs monolithic daemons', it's enough if virt-admin is mentioned once only. ...analogically, the same apples to the 'session' mode section below... > +``session`` daemon e.g. ``qemu:///session`` URI > > -:: > + * config files are usually placed in ``$XDG_CONFIG_HOME/libvirt/`` directory > + > + * ``virt-admin`` URI ending in ``/session`` should be used > + > +Modular vs. monolithic daemons > +------------------------------ > + > +While the config file name for the monolithic daemon is simple, in case when > +modular daemons are used, there's a lot of options. > + > +All libvirt daemons support the logging configuration per this document, but > +in most cases it's required to configure logging for the appropriate. How about: "While there is only a single 'libvirtd.conf' configuration file in case of the monolithic daemon setup, each of the modular daemons has their own configuration file giving you a lot of possibilities how to configure them individually including logging. Realistically though, logging will have to be configured only for a single or a couple of daemons in case debug logs are requested." > + > +Refer to `documentation about daemons <../daemons.html#checking-whether-modular-monolithic-mode-is-in-use>`__ > +to figure out which is in use by your system. > + > + Modular daemons Same as with system vs session --> should be a subsubsection > + > + The configuration of modular daemons is in file named after the daemon. E.g. > + for ``qemu:///system`` connection this is the ``virtqemud`` daemon and > + correspondingly: How about: "Configuration files in the modular daemons setup are named after individual daemons, each prefixed with 'virt', e.g. in case of the ``qemu:///system`` hypervisor connection, the underlying daemon handling it is called ``virtqemud`` and so the configuration file will be named ``virtqemud.conf``. For runtime configuration with ``virt-admin`` (see below) ``virtqemud:///system`` or ``virtqemud:///session`` URIs would be used depending on which runtime mode is used for the daemons (see above)." ...analogically, you can use the same with a few changes for the monolithic subsection... > + > + * ``virtqemud.conf`` config file is used > + > + * ``virtqemud:///system`` or ``virtqemud:///session`` admin URI is used > > - systemctl restart libvirtd.service > + Monolithic daemon > + > + * ``libvirtd.conf`` config file is used > + > + * ``libvirtd:///system`` or ``libvirtd:///session`` admin URI is used > + when the modular qemu hypervisor driver ``virtqemud`` > + > +Persistent setting > +------------------ > + "In order to setup libvirt logging persistently, follow the steps below:" > +- open the appropriate daemon config file in your favourite editor :: > + > + /etc/libvirt/virtqemud.conf > + /etc/libvirt/libvirtd.conf > + $XDG_CONFIG_HOME/libvirt/libvirtd.conf > + $XDG_CONFIG_HOME/libvirt/virtqemud.conf > + > +- find & replace, or set the apropriate `Log outputs`_ and `Log filters`_, e.g :: > + > + log_filters="3:remote 4:event 3:util.json 3:rpc 1:*" > + log_outputs="1:file:/var/log/libvirt/libvirtd.log" > + > +- save and exit > +- restart the corresponding service/daemon e.g. :: > + > + systemctl restart virtqemud.socket > + systemctl restart libvirtd.socket > + systemctl restart libvirtd.service > > > *Note:* Libvirt prior to the ``libvirt-4.4.0`` release didn't support globbing > patterns and thus requires more configuration. See > `Legacy (pre-4.4.0) libvirt daemon logging configuration`_. > > -However, when you are using the session mode ``qemu:///session`` or you run the > -``libvirtd`` as unprivileged user you will find configuration file under > -``$XDG_CONFIG_HOME/libvirt/libvirtd.conf``. > - > Runtime setting > --------------- > > @@ -127,13 +176,16 @@ after the daemon restarts, since the new session can make the anomaly > "disappear". Therefore, it's possible to enable the debug logs during runtime > using libvirt administration API. To use it conveniently, there's the > ``virt-admin`` client provided by the ``libvirt-admin`` package. Use the > -package manager provided by your distribution to install this package. Once you > -have it installed, run the following as root to see the set of log filters > -currently being active: > +package manager provided by your distribution to install this package. > + > +**Important**: Substitute ``virt-admin -c $ADMIN_URI`` per above guidance in s/per above/according to the guideline in the sections above > +place of ``virt-admin`` in the examples below if needed. > + > +The following command allows to query the list of log filters currently active: "...list of currently active log filters:" Erik
