Skip to content
Snippets Groups Projects
  • Peter Xu's avatar
    5655aab0
    migration: Postpone postcopy preempt channel to be after main · 5655aab0
    Peter Xu authored
    
    Postcopy with preempt-mode enabled needs two channels to communicate.  The
    order of channel establishment is not guaranteed.  It can happen that the
    dest QEMU got the preempt channel connection request before the main
    channel is established, then the migration may make no progress even during
    precopy due to the wrong order.
    
    To fix it, create the preempt channel only if we know the main channel is
    established.
    
    For a general postcopy migration, we delay it until postcopy_start(),
    that's where we already went through some part of precopy on the main
    channel.  To make sure dest QEMU has already established the channel, we
    wait until we got the first PONG received.  That's something we do at the
    start of precopy when postcopy enabled so it's guaranteed to happen sooner
    or later.
    
    For a postcopy recovery, we delay it to qemu_savevm_state_resume_prepare()
    where we'll have round trips of data on bitmap synchronizations, which
    means the main channel must have been established.
    
    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>
    5655aab0
    History
    migration: Postpone postcopy preempt channel to be after main
    Peter Xu authored
    
    Postcopy with preempt-mode enabled needs two channels to communicate.  The
    order of channel establishment is not guaranteed.  It can happen that the
    dest QEMU got the preempt channel connection request before the main
    channel is established, then the migration may make no progress even during
    precopy due to the wrong order.
    
    To fix it, create the preempt channel only if we know the main channel is
    established.
    
    For a general postcopy migration, we delay it until postcopy_start(),
    that's where we already went through some part of precopy on the main
    channel.  To make sure dest QEMU has already established the channel, we
    wait until we got the first PONG received.  That's something we do at the
    start of precopy when postcopy enabled so it's guaranteed to happen sooner
    or later.
    
    For a postcopy recovery, we delay it to qemu_savevm_state_resume_prepare()
    where we'll have round trips of data on bitmap synchronizations, which
    means the main channel must have been established.
    
    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>