[libvirt] RFC: Libvirt extensions for QEMU tracing
Daniel P. Berrange
berrange at redhat.com
Tue Oct 26 09:48:58 UTC 2010
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.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
More information about the libvir-list
mailing list