public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* Systemtap + tracing processes inside a qemu guest
@ 2011-10-10  9:10 Richard W.M. Jones
  2011-10-10 13:35 ` Frank Ch. Eigler
  0 siblings, 1 reply; 4+ messages in thread
From: Richard W.M. Jones @ 2011-10-10  9:10 UTC (permalink / raw)
  To: systemtap


I have a program (libguestfs) where the architecture is something
like this:


   +--------------+          +----------------------------+
   | program on   |          |    +-----------------+     |
   | host         <-------------->  daemon in guest |     |
   |              |  socket  |    +-----------------+     |
   +--------------+          | qemu                       |
                             +----------------------------+

I've instrumented the host program with DTRACE macros according to [1]
and that works well.  However to get the complete picture I'd like to
instrument the daemon too.  The aim would be to get timing information
across both the host program and the daemon:

  0.001s program event #1 send message
  0.005s daemon event #1 receive message
  0.010s daemon event #2 send reply
  0.025s program event #2 receive reply

(Note: I'm not interested in the qemu process itself, only in kernel +
userspace programs running inside the qemu virtual machine.)

What's possible at the moment?

I've read 'stapsh.c' and bug 13078 [2].  I'm not clear how to put it
all together, or even if this is possible right now.

Rich.

[1] http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps
[2] http://sourceware.org/bugzilla/show_bug.cgi?id=13078

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Systemtap + tracing processes inside a qemu guest
  2011-10-10  9:10 Systemtap + tracing processes inside a qemu guest Richard W.M. Jones
@ 2011-10-10 13:35 ` Frank Ch. Eigler
  2011-10-10 13:41   ` Richard W.M. Jones
  0 siblings, 1 reply; 4+ messages in thread
From: Frank Ch. Eigler @ 2011-10-10 13:35 UTC (permalink / raw)
  To: Richard W.M. Jones; +Cc: systemtap

"Richard W.M. Jones" <rjones@redhat.com> writes:

> [...]
> However to get the complete picture I'd like to
> instrument the daemon too.  The aim would be to get timing information
> across both the host program and the daemon:
>
>   0.001s program event #1 send message
>   0.005s daemon event #1 receive message
>   0.010s daemon event #2 send reply
>   0.025s program event #2 receive reply
> [...]
> What's possible at the moment?

You're looking for probing two separate systems (the host and the
guest) together.  The general model does not stretch that far right
now (and probably would not be easy to extend it that way).  The
closest thing would be running separate scripts, one on the host, and
one on the guest via --remote, and merging the events together after
the fact.

- FChE

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Systemtap + tracing processes inside a qemu guest
  2011-10-10 13:35 ` Frank Ch. Eigler
@ 2011-10-10 13:41   ` Richard W.M. Jones
  2011-10-10 13:55     ` Frank Ch. Eigler
  0 siblings, 1 reply; 4+ messages in thread
From: Richard W.M. Jones @ 2011-10-10 13:41 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: systemtap

On Mon, Oct 10, 2011 at 09:35:30AM -0400, Frank Ch. Eigler wrote:
> "Richard W.M. Jones" <rjones@redhat.com> writes:
> 
> > [...]
> > However to get the complete picture I'd like to
> > instrument the daemon too.  The aim would be to get timing information
> > across both the host program and the daemon:
> >
> >   0.001s program event #1 send message
> >   0.005s daemon event #1 receive message
> >   0.010s daemon event #2 send reply
> >   0.025s program event #2 receive reply
> > [...]
> > What's possible at the moment?
> 
> You're looking for probing two separate systems (the host and the
> guest) together.  The general model does not stretch that far right
> now (and probably would not be easy to extend it that way).  The
> closest thing would be running separate scripts, one on the host, and
> one on the guest via --remote, and merging the events together after
> the fact.

Can you point me to an example of using --remote in this simpler case
(just into a qemu guest)?

Could events from inside the qemu guest be somehow transferred to the
host kernel so that we can collect them all in one place?  (I don't
really know exactly how this works ...)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Systemtap + tracing processes inside a qemu guest
  2011-10-10 13:41   ` Richard W.M. Jones
@ 2011-10-10 13:55     ` Frank Ch. Eigler
  0 siblings, 0 replies; 4+ messages in thread
From: Frank Ch. Eigler @ 2011-10-10 13:55 UTC (permalink / raw)
  To: Richard W.M. Jones; +Cc: systemtap

Hi -

On Mon, Oct 10, 2011 at 02:40:43PM +0100, Richard W.M. Jones wrote:
> [...]
> Can you point me to an example of using --remote in this simpler case
> (just into a qemu guest)?
> Could events from inside the qemu guest be somehow transferred to
> the host kernel so that we can collect them all in one place?  [...]

Sort of; you can run a single script on both kernels:

host% stap --remote ssh://root@GUEST/ --remote direct://  SCRIPT.stp

where SCRIPT.stp can contain both host-side and guest-side probes,
perhaps with "?" (optional) probe point punctuation.  See also
the --remote-prefix flag.

- FChE

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-10-10 13:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-10  9:10 Systemtap + tracing processes inside a qemu guest Richard W.M. Jones
2011-10-10 13:35 ` Frank Ch. Eigler
2011-10-10 13:41   ` Richard W.M. Jones
2011-10-10 13:55     ` Frank Ch. Eigler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).