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

["Daniel P. Berrange" <berrange@redhat.com>]

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

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|