[Bug runtime/13078] investigate qemu virtio-serial channel for talking to stap-sh

["jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=13078

--- Comment #12 from Jonathan Lebon <jlebon at redhat dot com> ---
WARNING: I'm sorry in advance for breaking heads with this post

There are two things that have come to light since the last comment:

(1) Support for hot-plugging virtio-serial ports was added in libvirt 1.1.1
[1][2]. If this works as expected (will test soon), it means that we could do
one of two things:
   - Do away with stap-vm completely and have stap hot-plug a port for the
duration of the session only. This would mean adding a dependency to libvirt.
   - Keep stap-vm (maybe part of a different package) and offload the
hot-plugging work to it (which stap would then use). It could also be used by
users to permanently add ports to their VMs (as originally envisioned), which
would still be needed for machines with a libvirt version < 1.1.1.

(2) There is a slew of functions in the libvirt API which abstract away the
virtio-serial port [3]. I was informed this is the recommended way to interact
with virtio-serial ports on the host side (and avoid the permission issue
discussed in comment 11), but would also add a dependency to libvirt.

Note that AFAIK, libguestfs does not use this API. They do not encounter
permission issues because they create their own socket and make qemu connect to
it (in fact they have the reverse issue, to make sure that qemu has permission
to connect to their socket). This wouldn't work in our case unless we have the
VM start after stap (or we could have a utility that runs on boot to create the
socket and listen on it).

---

Conclusion/recap of what we could do (non-exhaustive):

A. Keep stap-vm and use it for hot-plugging and installing permanent ports for
libvirt < 1.1.1, as well as for brokering the stream using the API (perhaps
expose a unix socket to stap, or even just stdin/out). Root would be needed for
this (e.g. setuid, or user input). I'm not sure how much work is involved if we
were to use the stream APIs, and whether stap/stapsh would need to be modified.

B. Keep stap-vm and use it for hot-plugging and installing permanent ports for
libvirt < 1.1.1, but don't use the stream API. Make it change the socket's
permission on-the-fly so that stap can then connect to it the usual way. Root
would be needed for this (e.g. setuid, or user input).

C. Don't use stap-vm, make stap hot-plug a port for the duration of the
session. Don't use the stream API, connect directly to the UNIX socket. Adds a
dependency to libvirt in stap. We would need root access for this as well.

I personally prefer option B because it involves less new code to maintain and
it's easier to understand.

Let me know what you think!

[1] https://www.redhat.com/archives/libvir-list/2013-July/msg00125.html
[2] http://libvirt.org/news.html
[3] See the virStream* functions and virDomainOpenChannel() at
http://libvirt.org/html/libvirt-libvirt.html

-- 
You are receiving this mail because:
You are the assignee for the bug.