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

[John Snow]

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

> Stefan