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