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