Re: [PATCH V3 11/16] migration: cpr-transfer mode

[Peter Xu <peterx@redhat.com>]

On Thu, Nov 14, 2024 at 01:36:00PM -0500, Steven Sistare wrote:
> On 11/13/2024 4:58 PM, Peter Xu wrote:
> > On Fri, Nov 01, 2024 at 06:47:50AM -0700, Steve Sistare wrote:
> > > Add the cpr-transfer migration mode.  Usage:
> > >    qemu-system-$arch -machine anon-alloc=memfd ...
> > > 
> > >    start new QEMU with "-incoming <uri-1> -cpr-uri <uri-2>"
> > > 
> > >    Issue commands to old QEMU:
> > >    migrate_set_parameter mode cpr-transfer
> > >    migrate_set_parameter cpr-uri <uri-2>
> > >    migrate -d <uri-1>
> > 
> > QMP command "migrate" already allows taking MigrationChannel lists, cpr can
> > be the 2nd supported channel besides "main".
> > 
> > I apologize on only noticing this until now.. I wished the incoming side
> > can do the same already (which also takes 'MigrationChannel') if monitors
> > init can be moved earlier, and if precreate worked out.  If not, we should
> > still consider doing that on source, because cpr-uri isn't usable on dest
> > anyway.. so they need to be treated separately even now.
> > 
> > Then after we make the monitor code run earlier in the future we could
> > introduce that to incoming side too, obsoleting -cpr-uri there.
> 
> I have already been shot down on precreate and monitors init, so we are
> left with specifying a "cpr" channel on the outgoing side, and -cpr-uri
> on the incoming side.  That will confuse users, will require more implementation
> and specification work than you perhaps realize to explain this to users,

What is the specification work?  Can you elaborate?

> and only gets us halfway to your desired end point of specifying everything
> using channels.  I don't like that plan!
> 
> If we ever get the ability to open the monitor early, then we can implement
> a complete and clean solution using channels and declare the other options
> obsolete.

The sender side doesn't need to wait for destination side to be ready?
Dest side isn't a reason to me on how we should make sender side work if
they're totally separate anyway.  Dest requires -cpr-uri because we don't
yet have a choice.

Is the only concern about code changes?  I'm expecting this change is far
less controversial comparing to many others in this series, even if I
confess that may still contain some diff. They should hopefully be
straightforward, unlike many of the changes elsewhere in the series.

If you prefer not writting that patch, I am OK, and I can write one patch
on top of your series after it lands if that is OK for you. I still want to
have this there when release 10.0 if I didn't misunderstood anything, so
I'll be able to remove cpr-uri directly in that patch too.

-- 
Peter Xu