Re: [PATCH 19/21] migration: Allow migrate commands to provide the migration config

[Fabiano Rosas <farosas@suse.de>]

Peter Xu <peterx@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,