On Mon, Jun 09, 2025 at 11:53:47AM -0400, Peter Xu wrote: > On Mon, Jun 09, 2025 at 04:43:40PM +0100, Daniel P. Berrangé wrote: > > 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 > > So libvirt does not probe the qapi schema for all possible parameters? Why > not do that once on QEMU boot up, then when migration is needed use a > sequence of commands to make sure everything will be setup before > "migrate"? It'll definitely take a few rounds of QMP commands, but the > core issue is whether there can be any real atomic issues of that.
Probing the QAPI schema tells you what parameters exist. It does not tell you what values you should set for parameters, if you don't already know what the semantics of that parameter are. Such a requirement to probe all parameters & set them all manually is again making migration into a special case that is not following the normal QMP design, and there's no justification for that other than the historical design mistakes in migration QMP which were copied from HMP. 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 :|
