On Mon, Jun 09, 2025 at 05:15:43PM +0100, Daniel P. Berrangé wrote: > 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
If Libvirt is looking for some suggested value to set a parameter, it should just leave it empty, using the default provided by QEMU? I was expecting Libvirt to only specify anything it explicitly knows the answer. > 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. I agree migration is special cased.. I also agree if we design the interface today it may not be like that. I suppose it means it's only the "API cleaness" issue. That matches my understanding, even if I wished I missed something else.. That'll be a hassle for all mgmt for sure whenever an old libvirt might still have a chance to run on a newer QEMU. That'll also be a hassle for any downstream if some Y+1 branch starts to drop the global-set way completely then downstream might need to take care of keeping that instead for the major release until the last Y, otherwise if someone installs some X.Y+1 package on X.Y it might break similarly. All that for "let's make the interface look better". I sincerely could be wrong, but I keep my skeptical view of this whole effort; it's only about after this series (while this series still makes sense to me to have caps being able to set as params, and the "config" in general). I would say we could at least prioritize and invest other more important things, for example on handshakes, which could provide functional differences (removing src/dst param dependency, removing hackish channel establishments all over the places, early failure of device state mismatch rather than late failure on converge, etc.). Thanks, -- Peter Xu
