[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qmp-shell TUI (was: Re: Call for Google Summer of Code 2021 project

From: John Snow
Subject: Re: qmp-shell TUI (was: Re: Call for Google Summer of Code 2021 project ideas)
Date: Thu, 14 Jan 2021 12:48:03 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

On 1/14/21 8:52 AM, Stefan Hajnoczi wrote:
On Wed, Jan 13, 2021 at 01:59:43PM -0500, John Snow wrote:
On 1/13/21 3:53 AM, Stefan Hajnoczi wrote:
On Tue, Jan 12, 2021 at 9:10 PM John Snow <jsnow@redhat.com> wrote:
2. Ability to watch QMP activity on a running QEMU process, e.g. even
when libvirt is directly connected to the monitor.

That *WOULD* be extremely cool, and moves a lot closer to how mitmproxy

(Actually, mitmproxy could theoretically be taught how to read and
understand QMP traffic, but that's not something I know how to do or would
be prepared to mentor.)

Is this possible to do in a post-hoc fashion? Let's say you are using
production environment QEMU, how do we attach the QMP listener to it? Or
does this idea require that we start QEMU in a specific fashion with a
second debug socket that qmp-shell can connect to in order to listen?

... Or do we engineer qmp-shell to open its own socket that libvirt connects
to ...?

Here is the QEMU command-line that libvirt uses on my F33 system:

   -chardev socket,id=charmonitor,fd=36,server,nowait
   -mon chardev=charmonitor,id=monitor,mode=control

Goals for this feature:

1. No manual steps required for setup.
2. Ability to start/stop monitoring traffic at runtime without
    restarting QEMU.
3. Available to unprivileged users.

Excellent goals, and I agree completely.

I think the easiest way to achieve this is through a new QEMU monitor
command. Approaches that come to mind:

1. Add a -mon debug-chardev property and a QMP command to set it at
    runtime. The debug-chardev receives both monitor input (commands) and
    output (responses and events). This does not allow MITM, rather it
    mirrors traffic.

So you have a socket that relays I/O. I wonder if it needs to modify the stream format to some extent to annotate directionality?

For now, directionality can be inferred, but maybe that's brittle.
(greeting messages, events and return statements are from the server; negotiation and execute statements are from the client.)

Maybe if we used a hypothetical qmp-shell log format, we could add timestamps here instead of relying on the client to produce them. This might be interesting for analyzing race conditions and measuring response delays as experienced by the server.

{"message": original_json_message_here, "direction": "in", "timestamp": 1610627721}

(Downside: JSON is still not a streaming message format, but I guess it's one we already use all over the place anyway.)

2. Add a chardev-get-fd command that fetches the fd from a chardev and
    then use the existing chardev-change command to replace the monitor
    chardev with a chardev connected to qmp-shell. This inserts qmp-shell
    as a proxy between the QMP client and server. qmp-shell can remove
    itself again with another chardev-change command. This approach
    allows MITM. The downside is it assumes the QMP chardev is a file
    descriptor, so it won't work with all types of chardev.

It seems a little more prone to failure if the insertion/removal fails, and has some downsides about which configurations it can inject into.

3. Add a new chardev-proxy type that aggregates 3 chardevs: 1. an origin
    source chardev, 2. a monitoring sink chardev, and 3. a monitoring
    source chardev. The data flow is origin <-> monitoring sink <->
    monitoring source <-> QMP monitor. qmp-shell creates the monitoring
    sink (for receiving incoming QMP commands) and monitoring source
    chardev (for forwarding QMP commands or MITM commands), and then it
    uses change-chardev to instantiate a chardev-proxy that directs the
    original libvirt chardev through the monitoring sink and source.

I'm not sure I understand the topology here, exactly. I could stand to be a little more familiar with how chardevs are modeled in QEMU ...

    This is the most complex but also completely contained within the
    QEMU chardev layer.

In all these approaches qmp-shell uses virsh qemu-monitor-command or an
equivalent API to start/stop monitoring a running VM without manual
setup steps.

Gotcha. I think I am leaning towards the first suggestion, but maybe the third one that I don't quite grasp yet is good too.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]