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

[Stefan Hajnoczi]

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

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.

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.

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.

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.

   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.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20210114/e2258444/attachment-0001.sig>