On Tue, Oct 26, 2010 at 10:48:58AM +0100, Daniel P. Berrange wrote: > On Tue, Oct 26, 2010 at 12:15:30PM +0530, Prerna Saxena wrote: > > Hi, > > Tracing infrastructure is now a part of upstream QEMU, which allows > > options to choose different trace backends to handle trace-events of > > interest. The choice of 'simple' trace backend allows users to > > dynamically enable/disable trace events for a running qemu instance as > > well as to set options for logging traces to a desired file via the qemu > > monitor. > > While the QMP interfaces are still under discussion > > (http://www.mail-archive.com/qemu-de...@nongnu.org/msg44535.html), I > > propose the following extensions for virsh to make use of human-monitor > > tracing commands: > > > > 1. virsh trace-events DOMAIN-ID [set TRACE-EVENT ON ] > > ---------------------------------------------------- > > - Implements QEMU monitor command 'trace event' to change state of a > > particular trace-event. > > - Eg, virsh trace-events DOMAIN-ID set ABC on > > : changes state of trace-event 'ABC' to enabled. > > - When specified without arguments, it implements QEMU monitor > > command to show all currently available trace events and their state > > for a > > specific instance. > > - Eg, virsh trace-events DOMAIN-ID > > : lists all trace-events with their state for that instance. > > > > 2. virsh trace-file DOMAIN_ID [set FILENAME | --enable | --disable] > > ------------------------------------------------------------------- > > - Implements the qemu monitor command : trace-file > > - Without any arguments, it lists the currently active trace output > > file with its state. > > - The 'set' subcommand changes the output file to FILENAME. > > - The --enable and --disable switches respectively enable and > > disable writing of trace data to output file. > > > > The catch is, these are only available for 'simple' trace backend for > > qemu, so one would need to be careful of handling failures when these > > commands are passed to qemu instances compiled with a different trace > > backend. > > As such I'm not really convinced this is going to be useful. I don't > really see distros choosing to build the simple trace backend, when > the other backends (LTT-NG, or soon DTrace) are so much more flexible > and functional. Certainly in both Fedora and RHEL we'd just go for > a DTrace/SystemTAP tracing backend because that gives you end-to-end > tracing across the entire stack (virt-manager, libvirt, qemu/kvm > and kernel), as opposed to an isolated QEMU specific tool.
I agree. The simple trace backend is good for developers who want to quickly instrument QEMU without dependencies. And I think a QMP interface is appropriate so that scripts can automate tracing (rather than using the human monitor). But I don't see a strong case for support in libvirt when distros will ship SystemTap or LTT-ng UST. Stefan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
