From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afVV6-0002hM-Q7 for qemu-devel@nongnu.org; Mon, 14 Mar 2016 12:37:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afVV2-0000ce-H2 for qemu-devel@nongnu.org; Mon, 14 Mar 2016 12:37:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46671) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afVV2-0000cS-9C for qemu-devel@nongnu.org; Mon, 14 Mar 2016 12:37:44 -0400 References: <1457954501-26528-1-git-send-email-den@openvz.org> <1457954501-26528-7-git-send-email-den@openvz.org> <56E6CBD1.2060509@redhat.com> <20160314143857.GE21198@redhat.com> <56E6D323.5080803@openvz.org> <20160314152604.GG21198@redhat.com> <56E6E260.1040801@openvz.org> From: Paolo Bonzini Message-ID: <56E6E8D2.8030901@redhat.com> Date: Mon, 14 Mar 2016 17:37:38 +0100 MIME-Version: 1.0 In-Reply-To: <56E6E260.1040801@openvz.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 6/9] log: log QMP commands and replies List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: Pavel Butsykin , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino , Stefan Hajnoczi 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 >>>>>> >>>>>> 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