[PATCH 0/2] kbase: debuglogs: Ask for more data and add filter examples

Peter Krempa (2): kbase: debuglogs: Include more data to attach to bugreports kbase: debuglogs: Add some more example filters settings docs/kbase/debuglogs.rst | 54 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 50 insertions(+), 4 deletions(-) -- 2.26.2

Promote the 'What to attach?' section to a first level heading and request also the XML config of a VM, coredump backtrace if something crashed and ask to not tear down the environment for the possibility to ask for additional data. Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/kbase/debuglogs.rst | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/docs/kbase/debuglogs.rst b/docs/kbase/debuglogs.rst index decc53a69b..523adfcacc 100644 --- a/docs/kbase/debuglogs.rst +++ b/docs/kbase/debuglogs.rst @@ -136,13 +136,20 @@ setting which depends on the host configuration, *journald* in our case: Logging outputs: 2:journald What to attach? -~~~~~~~~~~~~~~~ +--------------- Now you should go and reproduce the bug. Once you're finished, attach: - ``/var/log/libvirt/libvirtd.log`` or whatever path you set for the daemon logs. -- If the problem is related to a domain attach - ``/var/log/libvirt/qemu/$dom.log`` then. Or substitute ``qemu`` with whatever - hypervisor you are using. +- If the problem is related to a domain named ``$dom`` attach: + + - ``/var/log/libvirt/qemu/$dom.log`` (Or substitute ``qemu`` with whatever + hypervisor you are using.) + - The XML configuration of the vm/domain obtained by ``virsh dumpxml $dom`` + +- If the problem involves a crash of ``libvirtd`` or any other component also + attach the core dump backtrace if possible (e.g. using ``coredumpctl``). - If you are asked for client logs, ``/tmp/libvirt_client.log``. +- Ideally don't tear down the environment in case additionall information is + required. -- 2.26.2

On Mon, Aug 03, 2020 at 03:00:46PM +0200, Peter Krempa wrote: [...]
What to attach? -~~~~~~~~~~~~~~~ +---------------
Now you should go and reproduce the bug. Once you're finished, attach:
- ``/var/log/libvirt/libvirtd.log`` or whatever path you set for the daemon logs. -- If the problem is related to a domain attach - ``/var/log/libvirt/qemu/$dom.log`` then. Or substitute ``qemu`` with whatever - hypervisor you are using. +- If the problem is related to a domain named ``$dom`` attach: + + - ``/var/log/libvirt/qemu/$dom.log`` (Or substitute ``qemu`` with whatever + hypervisor you are using.) + - The XML configuration of the vm/domain obtained by ``virsh dumpxml $dom`` + +- If the problem involves a crash of ``libvirtd`` or any other component also
nit: s/component/component,/
+ attach the core dump backtrace if possible (e.g. using ``coredumpctl``).
s/core dump backtrace/backtrace from a coredump/
- If you are asked for client logs, ``/tmp/libvirt_client.log``. +- Ideally don't tear down the environment in case additionall information is
nit: s/additionall/additional/ With at least the typo fixed: Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com>
+ required.
-- 2.26.2
-- /kashyap

Show various usage of filters including some useful examples. Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/kbase/debuglogs.rst | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/docs/kbase/debuglogs.rst b/docs/kbase/debuglogs.rst index 523adfcacc..8991feb17c 100644 --- a/docs/kbase/debuglogs.rst +++ b/docs/kbase/debuglogs.rst @@ -153,3 +153,42 @@ Now you should go and reproduce the bug. Once you're finished, attach: - If you are asked for client logs, ``/tmp/libvirt_client.log``. - Ideally don't tear down the environment in case additionall information is required. + +Example filter settings +----------------------- + +Some filter setting suggestions for debugging more specific things. Unless it's +explicitly stated, these apply on libvirt 4.4.0 and later. Please note that some +of the filtrs below may not contain enough information for filing a libvirt bug. + +Targetted logging for debugging QEMU vms +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Specifying only sections some sections allows for a targetted filter +configuration which works on all versions and is sufficient for most cases. + +:: + + 1:libvirt 1:qemu 1:conf 1:security 3:event 3:json 3:file 3:object 1:util + +Less verbose logging for QEMU vms +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Some subsystems are very noisy and usually not the culprit of the problems. They +can be silenced individually for a less verbose log while still logging +everything else. Usual suspects are the JSON code, udev, authentication and such. +A permissive filter is good for development use cases. + +:: + + 3:remote 4:event 3:util.json 3:util.object 3:util.dbus 3:util.udev 3:node_device 3:rpc 3:access.accessmanager 3:util.netlink 1:* + + +Minimalistic QEMU QMP monitor logging +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This filter logs only QMP traffic and skips most of libvirt's messages. + +:: + + 2:qemu.qemu_monitor 3:* -- 2.26.2

On Mon, Aug 03, 2020 at 03:00:47PM +0200, Peter Krempa wrote: [...]
+Example filter settings +----------------------- + +Some filter setting suggestions for debugging more specific things. Unless it's +explicitly stated, these apply on libvirt 4.4.0 and later. Please note that some +of the filtrs below may not contain enough information for filing a libvirt bug.
s/filtrs/filters/ I guess the intention of your note on these logs "may not contain enough info to file a bug" is to proactively prevent people from filing bugs with insufficient info. But still, that sentence hangs in the air for me, I don't know what to do with it as a newbie bug-reporter :-) (Perhaps it's a "bear in mind to not rush to file a bug".)
+Targetted logging for debugging QEMU vms +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nit: s/vms/VMs/
+ +Specifying only sections some sections allows for a targetted filter
I think you meant: s/only sections some sections/only some sections/
+configuration which works on all versions and is sufficient for most cases. + +:: + + 1:libvirt 1:qemu 1:conf 1:security 3:event 3:json 3:file 3:object 1:util
Thanks!
+Less verbose logging for QEMU vms +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nit: s/vms/VMs
+ +Some subsystems are very noisy and usually not the culprit of the problems. They +can be silenced individually for a less verbose log while still logging +everything else. Usual suspects are the JSON code, udev, authentication and such. +A permissive filter is good for development use cases. + +:: + + 3:remote 4:event 3:util.json 3:util.object 3:util.dbus 3:util.udev 3:node_device 3:rpc 3:access.accessmanager 3:util.netlink 1:* + + +Minimalistic QEMU QMP monitor logging +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This filter logs only QMP traffic and skips most of libvirt's messages. + +:: + + 2:qemu.qemu_monitor 3:*
With the awkward phrasing fixed: Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com>
-- 2.26.2
-- /kashyap
participants (2)
-
Kashyap Chamarthy
-
Peter Krempa