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(a)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(a)redhat.com>
Michal