[PATCH] kbase: debuglogs: Add a 'TL; DR' section for enabling logging in most common case

[Peter Krempa]

On Mon, Apr 17, 2023 at 16:15:29 +0100, Daniel P. Berrangé wrote:
> On Mon, Apr 17, 2023 at 01:38:31PM +0200, Peter Krempa wrote:
> > The document grew a bit too much explaining all the mistakes we've seen
> > the users do when configuring logging. Add a section distilling the
> > configuration of the most basic scenario which we can refer to when
> > upstream issues are reported. The scenario is for a runtime setting of
> > logging into a file applied to the 'virtqemud' daemon.
> > 
> > Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> > ---
> >  docs/kbase/debuglogs.rst | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/docs/kbase/debuglogs.rst b/docs/kbase/debuglogs.rst
> > index 53d70ee748..811ccf0102 100644
> > --- a/docs/kbase/debuglogs.rst
> > +++ b/docs/kbase/debuglogs.rst
> > @@ -16,6 +16,22 @@ server side that matters as nearly all interesting work takes place there.
> >  Moreover, libvirt catches stderr of all running domains. These can be useful as
> >  well.
> > 
> > +TL;DR - Enable debug logs for most common scenario
> > +===================================================
> > +
> > +This applies to the most common scenario of ``system`` instance of
> > +``virtqemud``. Log setting is not persisted, so a restart of ``virtqemud`` or
> > +the system clears this setting::
> > +
> > +   # virt-admin -c virtqemud:///system daemon-log-outputs "3:journald 1:file:/var/log/libvirt/libvirtd.log"
> > +   # virt-admin -c virtqemud:///system daemon-log-filters "3:remote 4:event 3:util.json 3:util.object 3:util.dbus 3:util.netlink 3:node_device 3:rpc 3:access 1:*"
> > +
> > +   # # optionally disable timeout of the daemon
> > +   # virt-admin -c virtqemud:///system daemon-timeout 0
> 
> Given that we have --timeout present by default, I'd say we should make
> this a stronger recommendation, or at least mention why you would really
> really really want to use this most of the time.

I went with 'optionally' just because the admin API that does this is
relatively recent.

I can try to come up with a stronger suggestion by adding the version
when it became available.