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 :|