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. > > 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.
Btw, one more thing to mention: IIUC libvirt shouldn't need to specify all parameters either. We have default parameters provided, now with Fabiano's work we can even have default caps being enabled now, used to controversial when being a cap. Hence, I would expect Libvirt doesn't need to specify all parameters (with/without "config") but whatever parameters it doesn't want to use the default (e.g. being specified by the user). When we can have more sane default parameters (I do plan to turn on preempt and blocktime caps on by default for postcopy at some point, for example), I think it's better libvirt uses the default, or e.g. blocktime may have been disabled there. Thanks, -- Peter Xu
