On Tue, 1 Jul 2025 15:00:42 +0200 Laurent Vivier <lviv...@redhat.com> wrote:
> On 01/07/2025 03:46, Jason Wang wrote: > > > I would like to know the plan to support migration and its > > compatibility for passt. > > As I said, the goal of this series is to be able to use '-nic passt' as we > can use '-nic > user'. '-nic user' supports migration but TCP connections are lost. > > With this series '-nic passt' supports migration but TCP connections are lost. > > But we can improve '-nic passt' because we can migrate TCP connections too, > for that we > need to launch passt-repair and to use vhost-user, if we really want to do > this it can be > added (with a 'migration=on' parameter?)... but it's also already managed by > '-netdev > vhost-user' and passt started manually or by libvirt. For context, as I suppose it's not obvious: passt needs a helper on both source and target to migrate TCP connections, because it needs the TCP_REPAIR socket option (same as CRIU) to dump and load connection parameters, to connect() TCP sockets without a new handshake, and to close() them without a RST. That helper is passt-repair(1), and its only purpose is to set and clear TCP_REPAIR on sockets passed via SCM_RIGHTS. By the way, at the moment, the only user of passt with a full integration of the TCP migration capabilities is KubeVirt: https://github.com/kubevirt/enhancements/blob/main/veps/sig-network/passt-migration-proposal.md https://github.com/kubevirt/kubevirt/pull/14875 With libvirt, right now, one would need to run passt-repair manually. Ideally, at some point, libvirt should gain the ability of doing all that for the user, but I haven't even thought of a reasonable proposal for how exactly libvirt could do this, yet. Migration of everything else doesn't need any helper, but "everything else" is just observed addresses at the moment, that is, passt needs to know what link-local and global unicast addresses the guest used to properly NAT traffic in some cases, and these are bits of back-end state we also transfer. -- Stefano
