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é <berra...@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 <mpriv...@redhat.com>
Michal
