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

On Fri, May 27, 2022, 7:32 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: > 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(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. > > 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. > I can look into it. It looks like render_block_graph works by actually executing a subprocess. Is there a chance of getting anything socket-like or stream-like out of libvirt to work with instead? As long as I can get some kind of stream going it should be easily possible to just replace the fd(s) the qmp lib uses and talk to libvirt instead.