All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Eric Blake" <eblake@redhat.com>,
	"Fabiano Rosas" <farosas@suse.de>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Thomas Huth" <th.huth+qemu@posteo.eu>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: Re: [PATCH v3 0/5] monitor: add dynamic QMP monitor hotplug support
Date: Tue, 7 Apr 2026 12:00:38 +0100	[thread overview]
Message-ID: <adTj1iWPZYTD0CF1@redhat.com> (raw)
In-Reply-To: <20260407-work-qmp-monitor-hotplug-v3-0-cb259800fffb@kernel.org>

On Tue, Apr 07, 2026 at 09:32:44AM +0200, Christian Brauner wrote:
> QEMU supports runtime hotplug for chardevs, devices, block backends,
> and netdevs. Monitors are the only major subsystem that lacks this --
> all QMP monitors must be configured at launch via -mon or -qmp CLI
> options.
> 
> This series adds monitor-add, monitor-remove, and query-monitors QMP
> commands so that management tools can create independent QMP sessions
> on demand at runtime.
> 
> I've implemented a QMP-to-Varlink bridge in systemd. This allows
> systemd-vmspawn to control virtual machines and containers through a
> unified Varlink interface. Varlink allows protocol upgrades. For
> example, it is possible to switch from Varlink to say http. I'm
> allowing Varlink clients to upgrade from the Varlink interface to the
> native QMP interface. Such clients get a new monitor assigned that
> allows them to manage the virtual machine directly via QMP. The main
> monitor remains unaffected and tied to the generic Varlink interface. We
> can't pre-allocate monitors as we have no control over how many protocol
> upgrades we actually get but it won't just be one. And having unused
> monitors around really isn't ideal either.
> 
> Having the ability to hotplug monitors would really be helpful. I'm not
> yet super well-versed in qemu internals so this might be done wrong but
> testing works so far.

Can you say if AI agents/LLMs were used in creating these patches ? 

> 
> My systemd patch that triggered this is at
> https://github.com/systemd/systemd/pull/41449.
> 
> The usage pattern mirrors chardev hotplug:
> 
>   -> chardev-add id=qmp-extra backend=socket,...
>   -> monitor-add id=extra-qmp chardev=qmp-extra
>   [client connects to socket, gets QMP greeting, negotiates, sends commands]
>   -> monitor-remove id=extra-qmp
>   -> chardev-remove id=qmp-extra

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



  parent reply	other threads:[~2026-04-07 19:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07  7:32 [PATCH v3 0/5] monitor: add dynamic QMP monitor hotplug support Christian Brauner
2026-04-07  7:32 ` [PATCH v3 1/5] monitor: store monitor id and dynamic flag in Monitor struct Christian Brauner
2026-04-07 10:39   ` Daniel P. Berrangé
2026-04-07 20:59     ` Christian Brauner
2026-04-07  7:32 ` [PATCH v3 2/5] monitor/qmp: add infrastructure for safe dynamic monitor removal Christian Brauner
2026-04-07  7:32 ` [PATCH v3 3/5] qapi: add monitor-add, monitor-remove, query-monitors commands Christian Brauner
2026-04-07 10:45   ` Daniel P. Berrangé
2026-04-07 20:59     ` Christian Brauner
2026-04-07  7:32 ` [PATCH v3 4/5] tests/qtest: add tests for dynamic monitor add/remove Christian Brauner
2026-04-07  7:32 ` [PATCH v3 5/5] tests/functional: add e2e test for dynamic QMP monitor hotplug Christian Brauner
2026-04-07 11:00 ` Daniel P. Berrangé [this message]
2026-04-07 20:57   ` [PATCH v3 0/5] monitor: add dynamic QMP monitor hotplug support Christian Brauner
2026-04-08  9:52     ` Daniel P. Berrangé
2026-04-08 20:27       ` Christian Brauner

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=adTj1iWPZYTD0CF1@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=brauner@kernel.org \
    --cc=eblake@redhat.com \
    --cc=farosas@suse.de \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=th.huth+qemu@posteo.eu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.