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
