Skip to content
  • Peter Xu's avatar
    d6f74fd1
    migration: Rework multi-channel checks on URI · d6f74fd1
    Peter Xu authored
    
    
    The whole idea of multi-channel checks was not properly done, IMHO.
    
    Currently we check multi-channel in a lot of places, but actually that's
    not needed because we only need to check it right after we get the URI and
    that should be it.
    
    If the URI check succeeded, we should never need to check it again because
    we must have it.  If it check fails, we should fail immediately on either
    the qmp_migrate or qmp_migrate_incoming, instead of failingg it later after
    the connection established.
    
    Neither should we fail any set capabiliities like what we used to do here:
    
    5ad15e86 ("migration: allow enabling mutilfd for specific protocol only", 2021-10-19)
    
    Because logically the URI will only be set later after the capability is
    set, so it doesn't make a lot of sense to check the URI type when setting
    the capability, because we're checking the cap with an old URI passed in,
    and that may not even be the URI we're going to use later.
    
    This patch mostly reverted all such checks for before, dropping the
    variable migrate_allow_multi_channels and helpers.  Instead, add a common
    helper to check URI for multi-channels for either qmp_migrate and
    qmp_migrate_incoming and that should do all the proper checks.  The failure
    will only trigger with the "migrate" or "migrate_incoming" command, or when
    user specified "-incoming xxx" where "xxx" is not "defer".
    
    Signed-off-by: default avatarPeter Xu <peterx@redhat.com>
    Reviewed-by: default avatarJuan Quintela <quintela@redhat.com>
    Signed-off-by: default avatarJuan Quintela <quintela@redhat.com>
    d6f74fd1
    migration: Rework multi-channel checks on URI
    Peter Xu authored
    
    
    The whole idea of multi-channel checks was not properly done, IMHO.
    
    Currently we check multi-channel in a lot of places, but actually that's
    not needed because we only need to check it right after we get the URI and
    that should be it.
    
    If the URI check succeeded, we should never need to check it again because
    we must have it.  If it check fails, we should fail immediately on either
    the qmp_migrate or qmp_migrate_incoming, instead of failingg it later after
    the connection established.
    
    Neither should we fail any set capabiliities like what we used to do here:
    
    5ad15e86 ("migration: allow enabling mutilfd for specific protocol only", 2021-10-19)
    
    Because logically the URI will only be set later after the capability is
    set, so it doesn't make a lot of sense to check the URI type when setting
    the capability, because we're checking the cap with an old URI passed in,
    and that may not even be the URI we're going to use later.
    
    This patch mostly reverted all such checks for before, dropping the
    variable migrate_allow_multi_channels and helpers.  Instead, add a common
    helper to check URI for multi-channels for either qmp_migrate and
    qmp_migrate_incoming and that should do all the proper checks.  The failure
    will only trigger with the "migrate" or "migrate_incoming" command, or when
    user specified "-incoming xxx" where "xxx" is not "defer".
    
    Signed-off-by: default avatarPeter Xu <peterx@redhat.com>
    Reviewed-by: default avatarJuan Quintela <quintela@redhat.com>
    Signed-off-by: default avatarJuan Quintela <quintela@redhat.com>
Loading