On Thu, Jul 24, 2025 at 07:28:58PM +0200, Stefano Brivio wrote:
> We are hitting an issue in the KubeVirt integration where some data is
> still sent to the source instance even after migration is complete. As
> we exit, the kernel closes our sockets and resets connections. The
> resulting RST segments are sent to peers, effectively terminating
> connections that were meanwhile migrated.
> 
> At the moment, this is not done intentionally, but in the future
> KubeVirt might enable OVN-Kubernetes features where source and
> destination nodes are explicitly getting mirrored traffic for a while,
> in order to decrease migration downtime.
> 
> By default, don't quit after migration is completed on the source: the
> previous behaviour can be enabled with the new, but deprecated,
> --migrate-exit option. After migration (as source), the -1 / --one-off
> option has no effect.
> 
> Also, by default, keep migrated TCP sockets open (in repair mode) as
> long as we're running, and ignore events on any epoll descriptor
> representing data channels. The previous behaviour can be enabled with
> the new, equally deprecated, --migrate-no-linger option.
> 
> By keeping sockets open, and not exiting, we prevent the kernel
> running on the source node to send out RST segments if further data
> reaches us.
> 
> Reported-by: Nir Dothan <ndothan@redhat.com>
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> ---
> v2:
>   - assorted changes in commit message
>   - context variable ignore_linger becomes ignore_no_linger
>   - new options are deprecated
>   - don't ignore events on some descriptors, drop them from epoll
> 
> v3:
>   - Nir reported occasional failures (connections being reset)
>     with both v1 and v2, because, in KubeVirt's usage, we quit as
>     QEMU exits. Disable --one-off after migration as source, and
>     document this exception

This seems like an awful, awful hack.  We're abandoning consistent
semantics on a wild guess as to what the layers above us need.
Specifically, --once-off used to mean that the layer above us didn't
need to manage passt's lifetime; it was tied to qemu's.  Now it still
needs to manually manage passt's lifetime, so what's the point.  So,
if it needs passt to outlive qemu it should actually manage that and
not use --once-off.

Requring passt to outlive qemu already seems pretty dubious to me:
having the source still connected when passt was quitting is one thing
- indeed it's arguably hard to avoid.  Having it still connected when
*qemu* quits is much less defensible.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson