On Fri, May 27, 2022 at 12:07:55PM -0400, John Snow wrote:
> On Fri, May 27, 2022, 7:32 AM Daniel P. Berrangé <berrange@xxxxxxxxxx>
> 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@xxxxxxxxxx>
> > > > ---
> > > >
> > > > 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.
Afraid not, any interface that plugs into libvirt would need to be
much higher level - send command and receive events - to map into
the libvirt APIs.
To get something stream oriented requires the proxy that I've proposd
here instead.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
