From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afVAj-0005Kk-TI for qemu-devel@nongnu.org; Mon, 14 Mar 2016 12:16:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afVAg-0002fd-Gb for qemu-devel@nongnu.org; Mon, 14 Mar 2016 12:16:45 -0400 Received: from mail-db3on0103.outbound.protection.outlook.com ([157.55.234.103]:25631 helo=emea01-db3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afVAf-0002eB-SP for qemu-devel@nongnu.org; Mon, 14 Mar 2016 12:16:42 -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> <20160314161153.GH21198@redhat.com> From: "Denis V. Lunev" Message-ID: <56E6E3DB.2060109@openvz.org> Date: Mon, 14 Mar 2016 19:16:27 +0300 MIME-Version: 1.0 In-Reply-To: <20160314161153.GH21198@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed 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: "Daniel P. Berrange" Cc: Pavel Butsykin , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino , Stefan Hajnoczi , Paolo Bonzini On 03/14/2016 07:11 PM, Daniel P. Berrange wrote: > On Mon, Mar 14, 2016 at 03:26:04PM +0000, 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 > BTW, I'm not against adding this to QEMU in general - just pointing out > that in the context of libvirt usage reference in the commit message, > it is not really needed. I'm totally ambivalent wrt adding this to QEMU > for benefit of non-libvirt usage. > > Regards, > Daniel I see. This just requires very clear commit message from my side. Thank you for a discussion. Den