From Red Hat internal testing we've had some reports that if attempting to migrate without passt-repair, the failure mode is uglier than we'd like. The migration fails, which is somewhat expected, but we don't correctly roll things back on the source, so it breaks network there as well. Address this and several other fragilities in the migration. Everything tested with the basic test suite, plus some additional testing for the specific functionality of the patches: For patches 1..2: * I get a clean migration if there are now active flows * Migration completes, although connections are broken if passt-repair isn't connected For patches 3..5: * Migration completes ok if the source and destination hosts have different IPs * Target correctly sees the bind() failure and abandons the flow * Unfortunately, target-side client doesn't get a reset, it just sits there not working. This is because a) the RST we try to send is lost because the queue is still inactive over the migration and b) we don't send RSTs or ICMPs for packets from the guest which no longer match a flow (I hope to tackle this soon) * After manually quitting the stuck client on the target, other connectivity works There are more fragile cases that I'm looking to fix, particularly the die()s in flow_migrate_source_rollback() and elsewhere. David Gibson (5): migrate, flow: Trivially succeed if migrating with no flows migrate, flow: Don't attempt to migrate TCP flows without passt-repair tcp: Correct error code handling from tcp_flow_repair_socket() tcp: Unconditionally move to CLOSED state on tcp_rst() migrate, tcp: Don't flow_alloc_cancel() during incoming migration flow.c | 17 +++++++++++++++-- tcp.c | 28 +++++++++++++++++++++------- 2 files changed, 36 insertions(+), 9 deletions(-) -- 2.48.1