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

[Fabiano Rosas <farosas@suse.de>]

Peter Xu <peterx@redhat.com> writes:

> On Wed, Jun 03, 2026 at 06:15:57PM +0100, Daniel P. Berrangé wrote:
>> On Wed, Jun 03, 2026 at 11:50:53AM -0400, Peter Xu wrote:
>> > On Wed, Jun 03, 2026 at 10:48:54AM +0100, Daniel P. Berrangé wrote:
>> > > On Fri, May 29, 2026 at 10:15:35AM -0400, Peter Xu wrote:
>> > > > On Thu, May 28, 2026 at 07:01:50PM -0300, Fabiano Rosas wrote:
>> > > > > Peter Xu <peterx@redhat.com> writes:
>> > > > > 
>> > > > > > CI: https://gitlab.com/peterx/qemu/-/pipelines/2560168907
>> > > > > >
>> > > > > > This series introduces a generic way to specify migration parameters that
>> > > > > > can be used even during the early boot phase of QEMU.
>> > > > > >
>> > > > > > One example use case that already existed is CPR-transfer / CPR-exec.
>> > > > > > currently QEMU has a temporary global variable (incoming_mode) to achieve
>> > > > > > this, but it's hard to understand and this hack bleeded into quite a few
>> > > > > > places that we could have avoided.  The lines in patch 2 touched may
>> > > > > > provide some idea.
>> > > > > >
>> > > > > > With a generic approach of setting migration parameters with cmdlines, we
>> > > > > > can remove this hack meanwhile QEMU should be able to keep the CPR behavior
>> > > > > > as before.  To CPR maintainers and reviewers: please have a closer look,
>> > > > > > even better if it can be smoke tested, to see if this works for Oracle's
>> > > > > > environment, TIA.
>> > > > > >
>> > > > > > The 1st patch implemented that new semantics.  It is straightforward: now
>> > > > > > we can setup any migration parameter using an extra line of:
>> > > > > >
>> > > > > >   -incoming config:key1=value1,key2=value2,...
>> 
>> snip
>> 
>> > > > > - using "config:"
>> > > > > 
>> > > > > This makes it non-uniform with uri and channels which don't have a
>> > > > > keyword in front of them. I guess I could live with it, but it seems
>> > > > > odd. I see that it makes parsing way easier.
>> > > > 
>> > > > Yeah, having some identifier would be nice.  I wished channels also have
>> > > > identifiers if we don't need to keep compatibility.
>> > > 
>> > > IMHO having a magic "config:" prefix is an anti-pattern because it
>> > > involves custom command line parsing logic.
>> > 
>> > Yes, it's not elegant.  I wished we had something like this though when
>> > introducing the cpr channels; right now anything wasn't "defer" or URI
>> > implies it's a "channel"..
>> > 
>> > I also wanted to avoid introducing new cmdline parameters, so migration
>> > incoming cmdlines can stick with the same option.  If there's better
>> > suggestion please shoot.
>> > 
>> > > 
>> > > Does "-incoming config" imply '-incoming defer' semantics or is it
>> > > independent ?  
>> > 
>> > They're independent.  Examples:
>> > 
>> >  a) "-incoming config:* -incoming tcp:*", setup parameters for TCP incoming
>> >     migration without further deferral
>> > 
>> >  b) "-incoming config:*" only, setup global parameters for a possible
>> >     upcoming outgoing migration
>> 
>> 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.
>
> Do we want to obsolete -incoming?
>
>> 
>> 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.
>
> This is one example that "relying only on migrate/migrate-incoming to
> specify parameters" won't work.
>
> Essentially parameters like CPR's and the new "local" parameter wants to be
> global so that it will be visible and will have an impact on how other QEMU
> modules behave.  Here for TAP when "local" is globally on we may want to
> initialize the device differently from the default operations.  That will
> need to happen before any QMP 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.
>
> This is true.  Then we will make this series to depend on Fabiano's
> previous work (to be posted; per we talked yesterday).
>

I don't see the dependency. Take the 'config' out from this series and
pass a JSON into -incoming. It can be parsed into MigrationParameters
all the same.

> I wanted to see if we can reduce the impact to minimum, -incoming is indeed
> not well designed, but in real life we have control over what can happen
> with URIs and the current "config:" won't conflict with any of them.
>
> But if we strongly wish to obsolete -incoming completely, I'm OK too.
>
> Thanks,