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/ :|