[Top][All Lists]

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

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

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

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:
I have one that is probably way too ambitious, but requires a particular
skillset that might be of good interest to a student that has some
experience in the area already.

The idea is for a TUI qmp-shell (maybe using urwid?) to create an
irssi-like REPL interface for QMP. The idea would be to mimic the
mitmproxy TUI interface (Check it out if you haven't!)

Great, I think this project idea lends itself to an incremental
milestones. How far it gets will depend on the intern and we'll be
able to merge useful patches regardless of how far they take it.

Yeah. I wrote a lot, but I think a lot of the desires and goals can actually be split out.

You can start with just the REPL mode; no bells or whistles. Just type commands, issue them, and have the log pane populate with the raw JSON as a starting point.

That'd be useful enough already. From there, the bells and whistles that make it truly shine can be added.

Two more ideas:
1. Ability to load libvirt log files for offline viewing. This could
be a major use case for this tool because the raw libvirt logs can be
hard to read today.

Yeah, that would be excellent. (Especially because I have such a hard time understanding libvirt-ese; seeing the QMP log in the same tool I use to communicate directly with QEMU would be an excellent debugging boon.)

mitmproxy has a similar feature where packet captures can be saved to file and loaded again later for analysis. A similar thing here would be nice.

I mentioned wanting to be able to save sessions for later viewing in my proposal; which likely means developing a QMP log format.

It's unlikely we'll want to use the libvirt log format here, so we'd need to develop a reader that can parse libvirt logs; but a writer is not likely important.

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 works.

(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 ...?


reply via email to

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