[PATCH] kbase: debuglogs: Add a 'TL; DR' section for enabling logging in most common case
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@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 + +For any other configuration please read the rest of the document. If you want +to persist the log level and log outputs settings edit +``/etc/libvirt/virtqemud.conf`` and look for ``log-filters`` and ``log-outputs`` Logging settings in libvirt =========================== -- 2.39.2
On 4/17/23 13:38, 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@redhat.com> --- docs/kbase/debuglogs.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Michal
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@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.
+ +For any other configuration please read the rest of the document. If you want +to persist the log level and log outputs settings edit +``/etc/libvirt/virtqemud.conf`` and look for ``log-filters`` and ``log-outputs``
Logging settings in libvirt =========================== -- 2.39.2
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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@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.
participants (3)
-
Daniel P. Berrangé -
Michal Prívozník -
Peter Krempa