Re: [Qemu-devel] [PATCH 6/9] log: log QMP commands and replies

[Paolo Bonzini <pbonzini@redhat.com>]

On 14/03/2016 17:10, Denis V. Lunev wrote:
> On 03/14/2016 06:26 PM, Daniel P. Berrange wrote:
>> On Mon, Mar 14, 2016 at 06:05:07PM +0300, Denis V. Lunev wrote:
>>> On 03/14/2016 05:38 PM, Daniel P. Berrange wrote:
>>>> On Mon, Mar 14, 2016 at 03:33:53PM +0100, Paolo Bonzini wrote:
>>>>> On 14/03/2016 12:21, Denis V. Lunev wrote:
>>>>>> From: Pavel Butsykin <pbutsykin@virtuozzo.com>
>>>>>>
>>>>>> This log would be very welcome for long-term diagnostics of the
>>>>>> system
>>>>>> in the production. This log is at least necessary to understand what
>>>>>> has been happened on the system and to identify issues at
>>>>>> higher-level
>>>>>> subsystems (libvirt, etc).
>>>>>>
>>>>>> These messages will be quite useful to understand how things are
>>>>>> going.
>>>>> There is now a logging mechanism for qemu-char.c.  Have you looked
>>>>> into
>>>>> making libvirt provide a QMP log based on it?
>>>>>
>>>>> The timestamping of patch 9 could be useful for character devices
>>>>> as well.
>>>> libvirt QEMU driver already has logging support for recording all
>>>> the data
>>>> it both sends and receives over QMP, which should be sufficient for any
>>>> day to day troubleshooting of QMP issues. So I doubt duplicating that
>>>> info from QEMU side too is really beneficial for debugging issues when
>>>> libvirt is in use.
>>>>
>>>> In libvirtd set
>>>>
>>>>    log_filters="1:qemu_monitor"
>>>>
>>>> and it'll capture everything on the QMP monitor in the default libvirtd
>>>> log file.
>>>>
>>>> The QMP data is also fed into the libvirt tracing backend, so you can
>>>> write systemtap scripts that hook on any QMP message, reply or event.
>>>> We ship a sample monitoring script examples/systemtap/qemu-monitor.stp
>>>> for this too.
>>>>
>>> you definitely sold this to me :) Thank you for pointing this out.
>>>
>>> There is the only differences in the approaches:
>>> - for example you have 20-50 VMs on the node
>>> - you have 1 problematic VM to be debugged by support (not development)
>>>
>>> In this case with my approach the load to the host IO subsystem will
>>> be less (logs from 1 VM will be written only).
>> Yep I can see your point but not sure how critical it is in practice. In
>> my experiance people often tend to just enable libvirt's QEMU debugging
>> permanently on the basis that by the time you notice a fault with a VM
>> it is too late to enable it. You often can't reproduce it, so can't just
>> turn it on for 1 VM once a probem occurs, you have to proactively collect
>> the data. In case where you do want to target a single VM though, there
>> is the systemtap approach to collect info which may be sufficient
> 
> do you have any opinion on this?

Daniel is usually very convincing to me as well. :)

Paolo