(I had a reply in the other thread, that might have covered most of the points but maybe not this one..)
On Mon, Jun 09, 2025 at 05:13:00PM +0100, Daniel P. Berrangé wrote: > Even if only a single mgmt app is involved this is still beneficial > because the migration infrastructure is used for distinct use cases > inside QEMU - live migration, CPR, save/restore, and savevm/loadvm. I assume CPR is save/restore, so indeed we have 3 ways to use migration core. > Any time code any one of those uses cases starts using a new parameter, > apps have to make sure they don't inadvertantly have its effects apply > to the other use cases. AFAICT, that's not affected by "whether we allow global settings", that is still a concern internally as long as they use migration core. One thing to mention is CPR is really a fine citizen here, AFAICT it is exactly live migration using all the proper caps/params. We _could_ split it as many things do not apply like postcopy, but we could still just reuse everything and ignoring the rest. It'll be again a cleaness issue to me, and even if CPR reuses everything it looks still clean enough, especially comparing to savevm/loadvm. savevm/loadvm is another story.. however afaiu if we want to decouple it, it should be done not from the interface level, but internally first. E.g., we should allow taking parameters as a temp pointer passing to migration core, so that will be passed over by savevm setting all caps off, for example, ignoring the global config. The interface alone should, IMHO, be done only later. Meanwhile, even if that, IMO we can't avoid the need to think any new param affecting savevm, as long as it's still using migration core. I don't know whether we need to do that one step even further to decouple savevm: I would think the other way round to obsolete savevm completely if necessary when we have fine "file:" migrations now, especially with mapped-ram. Thanks, -- Peter Xu
