Re: MultiFD and default channel out of order mapping on receive side.

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Oct 20, 2022 at 12:32:06PM -0400, Peter Xu wrote:
> On Thu, Oct 20, 2022 at 08:14:19PM +0530, manish.mishra wrote:
> > I had one concern, during recover we do not send any magic. As of now we
>   do not support multifd with postcopy so it should be fine, we can do
>   explict checking for non-recovery case. But i remember from some
>   discussion in future there may be support for multiFD with postcopy or
>   have multiple postcopy preempt channels too, then proper handshake will
>   be required? So at some point we want to take that path? For now i agree
>   approach 1 will be good as suggested by Daniel it can be backported
>   easily to older qemu's too.
> 
> Yes for the long run I think we should provide a generic solution for all
> the channels to be established for migration purpose.
> 
> Not to mention that as I replied previously to my original email, the trick
> won't easily work with dest QEMU where we need further change to allow qemu
> to accept new channels during loading of the VM.
> 
> Considering the complexity that it'll take just to resolve the prempt
> channel ordering, I think maybe it's cleaner we just look for the long term
> goal.

I think we should just ignore the preempt channel. Lets just do the
easy bit and fix the main vs multifd channel mixup, as that's the one
that is definitely actively hitting people today. We can solve that as
a quick win in a way that is easy to backport to existing releases of
QEMU for those affected.

Separately from that, lets define a clean slate migration protocol to
solve many of our historic problems and mistakes that can't be dealt
with through retrofitting, not limited to just this ordering mistake.

We had a significant discussion about it at the start of the year
in this thread, which I think we should take forward and write into
a formal protocol spec.

  https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg03655.html


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