qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Prívozník" <mprivozn@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>, libvir-list@redhat.com
Cc: John Snow <jsnow@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [libvirt PATCH v2] tools: add virt-qmp-proxy for proxying QMP clients to libvirt QEMU guests
Date: Fri, 1 Jul 2022 15:01:19 +0200	[thread overview]
Message-ID: <9cd7eb31-cb62-c06d-edcf-04ed81d7c33b@redhat.com> (raw)
In-Reply-To: <20220620171950.1416742-1-berrange@redhat.com>

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@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@redhat.com>

Michal



      parent reply	other threads:[~2022-07-01 13:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20 17:19 [libvirt PATCH v2] tools: add virt-qmp-proxy for proxying QMP clients to libvirt QEMU guests Daniel P. Berrangé
2022-06-21  7:14 ` Markus Armbruster
2022-07-01 13:01 ` Michal Prívozník [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9cd7eb31-cb62-c06d-edcf-04ed81d7c33b@redhat.com \
    --to=mprivozn@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).