Re: [PATCH v2 01/10] migration: Increase default number of multifd channels to 16

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

On Wed, Dec 18, 2019 at 03:01:10AM +0100, Juan Quintela wrote:
> We can scale much better with 16, so we can scale to higher numbers.
> 
> Signed-off-by: Juan Quintela <quintela@redhat.com>
> ---
>  migration/migration.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index 354ad072fa..e7f707e033 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -86,7 +86,7 @@
>  
>  /* The delay time (in ms) between two COLO checkpoints */
>  #define DEFAULT_MIGRATE_X_CHECKPOINT_DELAY (200 * 100)
> -#define DEFAULT_MIGRATE_MULTIFD_CHANNELS 2
> +#define DEFAULT_MIGRATE_MULTIFD_CHANNELS 16

I think this can break compatibility for migration between new and
old QEMU. Consider a deployment has enabled multifd, but not given
an explicit number of channels, and now try to start the migration.

In the method multifd_recv_initial_packet() there is a check

    if (msg.id > migrate_multifd_channels()) {
        error_setg(errp, "multifd: received channel version %d "
                   "expected %d", msg.version, MULTIFD_VERSION);
        return -1;
    }

which will fail if migrating from new QEMU to old QEMU because
migrate_multifd_channels() will be 2 for old QEMU and new
QEMU will be trying to open 16 channels.

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