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

On 5/27/22 12:20 PM, 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(a)redhat.com&gt; >> --- >> >> 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. > > This is an option too albeit a bit more complex to set up, but on the > other hand a bit more universal. > > I'll have a look at the code a bit later. > Would have found it useful, at the time I wrote the multifd save series I ended up just scripting around virsh qemu-monitor-command from either bash or C.