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 <pbutsy...@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