From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afV4b-0007ag-TJ for qemu-devel@nongnu.org; Mon, 14 Mar 2016 12:10:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afV4Y-00019L-GB for qemu-devel@nongnu.org; Mon, 14 Mar 2016 12:10:25 -0400 Received: from mail-am1on0143.outbound.protection.outlook.com ([157.56.112.143]:52644 helo=emea01-am1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afV4X-00017C-UQ for qemu-devel@nongnu.org; Mon, 14 Mar 2016 12:10:22 -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> From: "Denis V. Lunev" Message-ID: <56E6E260.1040801@openvz.org> Date: Mon, 14 Mar 2016 19:10:08 +0300 MIME-Version: 1.0 In-Reply-To: <20160314152604.GG21198@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: Paolo Bonzini Cc: Pavel Butsykin , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino , Stefan Hajnoczi 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 > > Regards, > Daniel Paolo, do you have any opinion on this? Den