On Thu, Jun 22, 2023 at 11:54:43AM -0400, Peter Xu wrote: > On Thu, Jun 22, 2023 at 10:59:58AM +0100, Daniel P. Berrangé wrote: > > I've mentioned several times before that the user should never need to > > set this multifd-channels parameter (nor many other parameters) on the > > destination in the first place. > > > > The QEMU migration stream should be changed to add a full > > bi-directional handshake, with negotiation of most parameters. > > IOW, the src QEMU should be configured with 16 channels, and > > it should connect the primary control channel, and then directly > > tell the dest that it wants to use 16 multifd channels. > > > > If we're expecting the user to pass this info across to the dest > > manually we've already spectacularly failed wrt user friendliness. > > I can try to move the todo even higher. Trying to list the initial goals > here: > > - One extra phase of handshake between src/dst (maybe the time to boost > QEMU_VM_FILE_VERSION) before anything else happens. > > - Dest shouldn't need to apply any cap/param, it should get all from src. > Dest still need to be setup with an URI and that should be all it needs.
There are a few that the dest will still need set explicitly. Specifically the TLS parameters - tls-authz and tls-creds, because those are both related to --object parameters configured on the dst QEMU. Potentially there's an argument to be made for the TLS parameters to be part fo the initial 'migrate' and 'migrate-incoming' command data, as they're specifically related to the connection establishment, while (most) of the other params are related to the migration protocol running inside the connection. A few other parameters are also related to the connection establishment, most notably the enablement multifd, postcopy and postcopy-pre-empt. I think with those ones we don't need to set them on the src either. With the new migration handshake we should probably use multifd codepaths unconditionally, with a single channel. By matching with the introduction of new protocol, we have a nice point against which to deprecate the old non-multifd codepaths. We'll need to keep the non-multifd code around *alot* longer than the normal deprecation cycle though, as we need mig to/from very old QEMUs. The enablement of postcopy could be automatic too - src & dst can both detect if their host OS supports it. That would make all migrations post-copy capable. The mgmt app just needs to trigger the switch to post-copy mode *if* they want to use it. Likewise we can just always assume postcopy-pre-empt is available. I think 'return-path' becomes another one we can just assume too. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
