On Mon, Jan 29, 2018 at 08:59:16AM +0800, Wanpeng Li wrote: > 2018-01-26 22:03 GMT+08:00 Stefan Hajnoczi <stefanha@xxxxxxxxx>: > > 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 > > How to use the kvm.ko uevent to find the QEMU PID? Add a udev rule on the host for kvm.ko EVENT=create/destroy events. These events have a PID=<pid> field that a script can use to record the QEMU instance that is associated with this guest. Please see virt/kvm/kvm_main.c:kvm_uevent_notify_change(). Stefan
Attachment:
signature.asc
Description: PGP signature
