Re: [RFC 4/6] migration: Deprecate -incoming <uri>

[Daniel P . Berrangé]

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