Re: [RFC 4/6] migration: Deprecate -incoming <uri>
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 :|