Re: Shared value between host and guests

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3034 bytes --]

On Mon, Jan 29, 2018 at 08:59:16AM +0800, Wanpeng Li wrote:
> 2018-01-26 22:03 GMT+08:00 Stefan Hajnoczi <stefanha@gmail.com>:
> > 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]