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

[Michal Prívozník]

On 6/20/22 19:19, 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>
> ---
> 
> Changed in v2:
> 
>  - Rewrote to not be such a gross hack, specifically
>       - Wired up usage of libvirt event loop for sock I/O
>       - Register with libvirt for QMP events
>       - Incrementally read from socket & try json parsing
>         until we get a full command, instead of assuming
>         a full command in one read
>       - Forwarding of passed FDs in both directions
>         (libvirt -> client untested, since AFAIK, no
>         QMP cmd returns FDs currently)
> 
> 
> Other thought....
> 
> This patch is against libvirt.git but has a dependancy on the
> libvirt-python.git APIs. If we put this in libvirt-client RPM
> then we get a new dep on python.
> 
> Perhaps better to have this live in libvirt-python.git/examples,
> though I would like it present as a standard tool ? Another
> option is to bundle with virt-install which is a python app
> commonly present on virt hosts ?

Or, we could have it in a separate RPM which would require
libvirt-client and libvirt-python.

> 
>  docs/manpages/meson.build        |   1 +
>  docs/manpages/virt-qmp-proxy.rst | 120 +++++++++++
>  tools/meson.build                |   5 +
>  tools/virt-qmp-proxy             | 360 +++++++++++++++++++++++++++++++
>  4 files changed, 486 insertions(+)
>  create mode 100644 docs/manpages/virt-qmp-proxy.rst
>  create mode 100755 tools/virt-qmp-proxy

Reviewed-by: Michal Privoznik <mprivozn at redhat.com>

Michal