Re: [PATCH RFC 0/2] migration/vl: new -incoming config:* for early migration parameters

[Peter Xu <peterx@redhat.com>]

On Wed, Jun 03, 2026 at 07:00:07PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 03, 2026 at 02:51:30PM -0300, Fabiano Rosas wrote:
> > Daniel P. Berrangé <berrange@redhat.com> writes:
> > 
> > > In that case they should definitely be independent command line
> > > options. The old "-incoming" design is already broken / limited
> > > in the non-'defer' case because it is hardcoded to use URI syntax
> > > which can't express all the address formats we accept in QAPI
> > > syntax. Adding more special cases onto -incoming just makes the
> > > bad situation even worse and is not a forward looking design.
> > >
> > > If we need the ability to specify migration parameters on the
> > > CLI, then as a starting point for the design, we should assume that
> > > -incoming does not exist, and design a complete solution from scratch
> > > that uses QAPI exclusively, both for addresses and configuration.
> > >
> > > As discussed before, IMHO the "migrate" and "migrate-incoming"
> > > commands need to accept both the address(s) and parameters/capabilities
> > > as inline data items rather than relying on pre-configured global state
> > > from the 'migrate-parameter' / 'migrate-capability' commands.
> > >
> > > If we did that modelling for 'migrate-incoming' then that modelling of
> > > command parmaeters could map directly to a new '-migrate-incoming'
> > > command line argument that accepted exactly the same data model.
> > >
> > 
> > Maybe a user creatable object would better fit this use case instead of
> > a new command. We could expose what is today MigrationParameters plus
> > the few compat options from migration_properties. It could work more or
> > less the same for the QMP migration commands, QMP set/get commands,
> > source and destination command lines, the compatibility use-case and the
> > debugging use-case.
> 
> If we can do something using "-object" that is useful both at command
> line time and in QMP runtime, then that would be interesting too.
> 
> My general feeling wrt changes to the current command line is that
> any suggestion should be desgined with a nod towards a future scenario
> where QEMU is 100% configured with QMP. ie the full command line is
> 
>    qemu-system-x86_64 -qmp <address>
> 
> In this world, the current -incoming argument is already largely
> unsatisfactory for anything other than "defer".  A model that uses
> -object would fit in well, as would a hypothetical -migrate-incoming
> that directly mapped to 'migrate-incoming' QMP including capabilities
> and parameters.

I don't think even the current -incoming config:* is a blocker or add too
much complexity to the full-QMP-based solution.

When it comes, we can simply map all -incoming config:* (JSON or not) to
QMP command migrate-set-parameters, what we need is teaching that QMP
handler to apply parameters to the temporary MigrationParameters rather
than migration object when the latter hasn't been initialized.

I was talking to Fabiano and he suggested me to mention one more thing I
said on the list.  It's a matter of whether we should still invest time on
supporting migration caps/parameters in QMP migrate/migrate-incoming
commands.

Requirements like this (allow migration parameters to be accessible during
early stage of QEMU) is going towards the other direction of the that idea.
That means even if we put all configs (caps/params) into QMP command
migrate[-incoming], libvirt will still need to manage these global setup
and making sure when invoking migrate[-incoming] QMP commands they match
with the globals.  Say, if one start QEMU with -incoming config:local=on
but then invoke "migrate-incoming,local=off" it's illegal.

Considering that it looks like there're solid use cases that we want to
support (after CPR's "mode" parameter, now "local"), I want to discuss
again whether we want to still spend effort supporting "allow migrate QMP
command to specify capabilities/parameters".  Ultimately, we still seem to
need these global parameters.

Thanks,

-- 
Peter Xu