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. Just to say, I still think having "option" is a fine idea at least, but I'm really curious on whether there's any real issue even without it. Thanks, -- Peter Xu
