From: John Snow <jsnow@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: qmp-shell TUI (was: Re: Call for Google Summer of Code 2021 project ideas)
Date: Wed, 13 Jan 2021 13:59:43 -0500 [thread overview]
Message-ID: <e8938b53-a933-426c-0719-981ab0df123f@redhat.com> (raw)
In-Reply-To: <CAJSP0QVRohWcfYY7AjispK8+VYat6APc3nNbmAxk+34nZmtFPw@mail.gmail.com>
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
>
next prev parent reply other threads:[~2021-01-13 19:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 11:47 Call for Google Summer of Code 2021 project ideas Stefan Hajnoczi
2021-01-12 21:10 ` John Snow
2021-01-13 8:53 ` Stefan Hajnoczi
2021-01-13 18:59 ` John Snow [this message]
2021-01-14 13:52 ` qmp-shell TUI (was: Re: Call for Google Summer of Code 2021 project ideas) Stefan Hajnoczi
2021-01-14 13:59 ` Daniel P. Berrangé
2021-01-14 15:02 ` Kevin Wolf
2021-01-14 15:22 ` Daniel P. Berrangé
2021-01-14 16:49 ` Stefan Hajnoczi
2021-01-14 16:55 ` Daniel P. Berrangé
2021-01-14 17:14 ` Stefan Hajnoczi
2021-01-14 17:24 ` Daniel P. Berrangé
2021-01-14 16:48 ` Stefan Hajnoczi
2021-01-14 17:48 ` John Snow
2021-01-13 9:19 ` Call for Google Summer of Code 2021 project ideas Markus Armbruster
2021-01-13 19:05 ` John Snow
2021-01-14 12:29 ` Markus Armbruster
2021-01-14 14:57 ` Kevin Wolf
2021-01-14 16:36 ` John Snow
2021-01-15 16:31 ` Kashyap Chamarthy
2021-02-15 11:05 ` Paolo Bonzini
2021-02-15 21:47 ` John Snow
2021-02-12 13:22 ` [Rust-VMM] " Florescu, Andreea
2021-02-12 13:51 ` Sergio Lopez
2021-02-17 11:20 ` Stefan Hajnoczi
2021-02-18 11:49 ` Andreea Florescu
2021-02-18 17:43 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e8938b53-a933-426c-0719-981ab0df123f@redhat.com \
--to=jsnow@redhat.com \
--cc=ehabkost@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).