[libvirt PATCH] tools: add virt-qmp-proxy for proxying QMP clients to libvirt QEMU guests

[Daniel P. Berrangé]

On Fri, May 27, 2022 at 12:20:39PM +0200, Peter Krempa wrote:
> On Fri, May 27, 2022 at 10:47:58 +0100, Daniel P. Berrangé wrote:
> > Libvirt provides QMP passthrough APIs for the QEMU driver and these are
> > exposed in virsh. It is not especially pleasant, however, using the raw
> > QMP JSON syntax. QEMU has a tool 'qmp-shell' which can speak QMP and
> > exposes a human friendly interactive shell. It is not possible to use
> > this with libvirt managed guest, however, since only one client can
> > attach to he QMP socket at any point in time.
> > 
> > The virt-qmp-proxy tool aims to solve this problem. It opens a UNIX
> > socket and listens for incoming client connections, speaking QMP on
> > the connected socket. It will forward any QMP commands received onto
> > the running libvirt QEMU guest, and forward any replies back to the
> > QMP client.
> > 
> >   $ virsh start demo
> >   $ virt-qmp-proxy demo demo.qmp &
> >   $ qmp-shell demo.qmp
> >   Welcome to the QMP low-level shell!
> >   Connected to QEMU 6.2.0
> > 
> >   (QEMU) query-kvm
> >   {
> >       "return": {
> >           "enabled": true,
> >           "present": true
> >       }
> >   }
> > 
> > Note this tool of course has the same risks as the raw libvirt
> > QMP passthrough. It is safe to run query commands to fetch information
> > but commands which change the QEMU state risk disrupting libvirt's
> > management of QEMU, potentially resulting in data loss/corruption in
> > the worst case.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> > ---
> > 
> > CC'ing QEMU since this is likely of interest to maintainers and users
> > who work with QEMU and libvirt
> > 
> > Note this impl is fairly crude in that it assumes it is receiving
> > the QMP commands linewise one at a time. None the less it is good
> > enough to work with qmp-shell already, so I figured it was worth
> > exposing to the world. It also lacks support for forwarding events
> > back to the QMP client.
> 
> I originally wanted to teach the qemu tools to work with libvirt
> directly similarly how 'scripts/render_block_graph.py' from the qemu
> tree already does but I guess this is also an option.

Yes, I do wonder about whether with John's new QMP python APIs,
it would be possible to plug in a livirt transport instead of
the socket transport. I've not spent enough time looking at the
Python QMP code to know if that's viable or not though.

> This is an option too albeit a bit more complex to set up, but on the
> other hand a bit more universal.

The two approaches aren't mutually exclusive either. There's no
reason we can't have both options.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|