Re: [PATCH 19/21] migration: Allow migrate commands to provide the migration config

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Jun 09, 2025 at 11:33:14AM -0400, Peter Xu wrote:
> 
> Now I think I know part of what I've missed: I used to think the "config"
> of per-QMP-migrate-command can be totally temporary for a specific
> migration request, but then we need another MigrationState.parameters_2 to
> cache the old or vice versa; that's probably not necessary.  Now I think it
> makes sense to overwrite any settings directly, hence I think I changed my
> mind on question (1), YES is fine here.
> 
> For (2), why it would introduce any uncertainty for mgmt?
> 
> If the mgmt app can both: (1) query from qapi schema knowing all the
> parameters supported, then (2) specify all the parameters in QMP migrate's
> "option" parameter.  Then it's literally overwritting all the parameters,
> so it's predictable with or without completely removing global settings as
> an idea?

That is relying on the mgmt app specifiying absolutely every config
parameter that exists. If they miss anything, then the behaviour is
not well defined, as external global state still affects things.

This is the same situation we already have with migrate-set-parameter,
where mgmt apps have to know to call migrate-set-parameter over & over
with every possible parameter to get back to a well known starting point.

The command needs to run with the parameters provided in 'config' and
no external global state, whether from -global or any prior call of
migrate-set-parameter

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 :|