<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 27, 2022, 7:32 AM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, May 27, 2022 at 12:20:39PM +0200, Peter Krempa wrote:<br>
> On Fri, May 27, 2022 at 10:47:58 +0100, Daniel P. Berrangé wrote:<br>
> > Libvirt provides QMP passthrough APIs for the QEMU driver and these are<br>
> > exposed in virsh. It is not especially pleasant, however, using the raw<br>
> > QMP JSON syntax. QEMU has a tool 'qmp-shell' which can speak QMP and<br>
> > exposes a human friendly interactive shell. It is not possible to use<br>
> > this with libvirt managed guest, however, since only one client can<br>
> > attach to he QMP socket at any point in time.<br>
> > <br>
> > The virt-qmp-proxy tool aims to solve this problem. It opens a UNIX<br>
> > socket and listens for incoming client connections, speaking QMP on<br>
> > the connected socket. It will forward any QMP commands received onto<br>
> > the running libvirt QEMU guest, and forward any replies back to the<br>
> > QMP client.<br>
> > <br>
> >   $ virsh start demo<br>
> >   $ virt-qmp-proxy demo demo.qmp &<br>
> >   $ qmp-shell demo.qmp<br>
> >   Welcome to the QMP low-level shell!<br>
> >   Connected to QEMU 6.2.0<br>
> > <br>
> >   (QEMU) query-kvm<br>
> >   {<br>
> >       "return": {<br>
> >           "enabled": true,<br>
> >           "present": true<br>
> >       }<br>
> >   }<br>
> > <br>
> > Note this tool of course has the same risks as the raw libvirt<br>
> > QMP passthrough. It is safe to run query commands to fetch information<br>
> > but commands which change the QEMU state risk disrupting libvirt's<br>
> > management of QEMU, potentially resulting in data loss/corruption in<br>
> > the worst case.<br>
> > <br>
> > Signed-off-by: Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank" rel="noreferrer">berrange@redhat.com</a>><br>
> > ---<br>
> > <br>
> > CC'ing QEMU since this is likely of interest to maintainers and users<br>
> > who work with QEMU and libvirt<br>
> > <br>
> > Note this impl is fairly crude in that it assumes it is receiving<br>
> > the QMP commands linewise one at a time. None the less it is good<br>
> > enough to work with qmp-shell already, so I figured it was worth<br>
> > exposing to the world. It also lacks support for forwarding events<br>
> > back to the QMP client.<br>
> <br>
> I originally wanted to teach the qemu tools to work with libvirt<br>
> directly similarly how 'scripts/render_block_graph.py' from the qemu<br>
> tree already does but I guess this is also an option.<br>
<br>
Yes, I do wonder about whether with John's new QMP python APIs,<br>
it would be possible to plug in a livirt transport instead of<br>
the socket transport. I've not spent enough time looking at the<br>
Python QMP code to know if that's viable or not though.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">(possibly with changing some details about the handshake, yadda yadda.)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> This is an option too albeit a bit more complex to set up, but on the<br>
> other hand a bit more universal.<br>
<br>
The two approaches aren't mutually exclusive either. There's no<br>
reason we can't have both options.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">I've in the past thought about implementing MITM directly in the qmp library. I wrote a QMPServer() class that I did not check in upstream because it is only prototype quality, but I used it for testing. I still have plans to upstream it because it is useful for the test suite.</div><div dir="auto"><br></div><div dir="auto">It has the same limitation as a lot of our Python tools have, though; it requires newlines because it doesn't have a streaming parser ...</div><div dir="auto"><br></div><div dir="auto">It's been something that I want to improve upon, but since libvirt is well-behaved and sends newlines, I haven't been properly motivated to.</div><div dir="auto"><br></div></div>