Peter Xu <pet...@redhat.com> writes: > (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. >
This is simple to do, just reset all of s->parameters to (the new) s->defaults. We never decided if any migration parameters do make sense to use with savevm. If some of them does or is added later, then snapshot_save would gain a "config" argument. > 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. savevm is a weird case. It supports a wider range of setups than regular migration. I don't know what to make of this. I would also like to make it "just migration" but it will need a bunch of special-casing. Anyway, we can discuss, but that's definitely for another day. > > Thanks,
