On Thu, Jan 25, 2018 at 10:44:12AM -0500, Geneviève Bastien wrote:
> On 2018-01-25 04:29 AM, Stefan Hajnoczi wrote:
> > On Wed, Jan 24, 2018 at 10:56:26AM -0500, Geneviève Bastien wrote:
> >> Thanks for the hint, I didn't know about those. But the uevents are only
> >> for the host right? There is no specific value in debugfs for guest.
> > I'm not sure I understand the question.
> >
> > Uevent are emitted on the host. Given the PID field, it should be
> > possible to correlate them to a specific guest (e.g. by looking at
> > information from the user or VM management tools, or simply by looking
> > at /proc/$PID/cmdline for the QEMU -name argument that can be used to
> > identify guests on the host side).
> >
> > Stefan
> With the information from the host and those uevents, we can indeed
> easily figure out in our traces which processes are associated with a
> guest and get its command line and a lot more information.
>
> The missing piece is in the guest trace. For example, we have lttng
> traces taken on the guest and the host. We may have multiple guests and
> multiple hosts to trace. It's easy to know which traces are from hosts
> from the events, but which are from guests? And which guest trace goes
> with which of the kvm processes on which host? The guest trace contains
> no information that can be linked to the host.
>
> I was thinking that the guest could do a hypercall to the host after
> bootup to share some unique information, for instance its bootid, that
> the host could store somewhere. That information would be available in
> the traces so that we can easily associate the guest with its host
> process and the states of its virtual CPUs to that of the corresponding
> threads, and much more.
>
> I hope this describes our need a little better.
The QEMU -uuid <uuid> option makes a UUID available to the guest via
SMBIOS and fw_cfg on x86. Inside the guest you can print it like this:
# dmidecode -s system-uuid
01020304-0506-0708-090A-0B0C0D0E0F10
Maybe you can base the guest trace filename off the UUID:
guest-01020304-0506-0708-090A-0B0C0D0E0F10-trace-001.dat
On the host you can either find the UUIDs in the libvirt domain XML:
# virsh dump my-domain
<domain ...>
<uuid>0102030405060708090a0b0c0d0e0f10</uuid>
...
Or you can use the kvm.ko uevent to find the QEMU PID and then check
/proc/$PID/cmdline for the uuid. The UUID can also be fetched via the
query-uuid QMP command if you don't want to search /proc/$PID/cmdline
for -uuid <uuid>.
Maybe you can base the host trace filename off the UUID too:
host-01020304-0506-0708-090A-0B0C0D0E0F10-trace-001.dat
Then the ask of correlating traces becomes pretty easy for
post-processing scripts since they can look at the filenames.
Stefan
Attachment:
signature.asc
Description: PGP signature
