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