[libvirt] RFC: Libvirt extensions for QEMU tracing
Stefan Hajnoczi
stefanha at linux.vnet.ibm.com
Tue Oct 26 10:50:39 UTC 2010
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-devel@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
More information about the libvir-list
mailing list