From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btwoO-0006eH-S9 for qemu-devel@nongnu.org; Tue, 11 Oct 2016 09:09:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btwoK-0006i5-J1 for qemu-devel@nongnu.org; Tue, 11 Oct 2016 09:09:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btwoK-0006hP-CF for qemu-devel@nongnu.org; Tue, 11 Oct 2016 09:09:36 -0400 Date: Tue, 11 Oct 2016 14:09:32 +0100 From: "Daniel P. Berrange" Message-ID: <20161011130932.GE14917@redhat.com> Reply-To: "Daniel P. Berrange" References: <20160926162846.GL18393@redhat.com> <20160929024530.GC6412@lemon> <874m4xmi29.fsf@dusky.pond.sub.org> <20161001121043.GA26716@lemon> <87k2doimqu.fsf@dusky.pond.sub.org> <20161011125101.GG5814@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161011125101.GG5814@lemon> Subject: Re: [Qemu-devel] top(1) utility implementation in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Markus Armbruster , prashanth sunder , qemu-devel@nongnu.org On Tue, Oct 11, 2016 at 08:51:01PM +0800, Fam Zheng wrote: > On Tue, 10/04 09:42, Markus Armbruster wrote: > > >> What's the advantage over simply using another QMP monitor? Naturally, > > >> injecting arbitrary QMP commands behind libvirt's back isn't going to > > >> end well, but "don't do that then". Information queries and listening > > >> to events should be safe. > > > > > > In order to avoid a Libvirt "tainted" state at production env, of course > > > assuming qemu-top is useful there at all. > > > > Adding another QMP-like protocol seems like a rather steep price just > > for avoiding "tainted". > > > > Any chance we can provide this feature together with libvirt instead of > > behind its back? > > That would be the best, but I am not sure how to make an appropriate interface. IMHO the QMP monitor just isn't a good fit for performance monitoring due to its inherant inefficiency wrt serialization/deserialiation. This is already a problem with the limitation usage libvirt makes of QMP when we're collecting data from a number of guests. I also think it is a bad choice for exposing adhoc debugging facilities too - dynamic instrumentation is far more flexible as it avoids us having to maintain long term stable QMP schemas for instrumenting internal, ever changing data structures. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|