This was first mentioned by yalzhang@redhat.com in RHEL-69455. We initially thought it wouldn't affect layered products (KubeVirt / OpenShift Virtualisation), but it actually does, because also in KubeVirt there's no accessible hook on the migration target between:

1. libvirt preparing the domain (and starting helpers, such as virtiofsd and passt)
2. libvirt starting the guest (QEMU) and the migration

The helper passt uses to switch connections to repair mode for migration (passt-repair) would need to be executed once passt is ready (after 1.) but before passt needs to actually restore connections (before 2.).

That's because passt-repair connects to passt, and passt expects passt-repair to be already connected while restoring connections on the target.

There's no way, however, not even in KubeVirt, to block 2. and run the helper as intermediate step before that.

As a minimal fix for this issue, we implemented, upstream:

• an inotify watch in passt-repair, so that passt-repair can be (optionally) given a directory instead of a socket file, and connect to the socket only once the file appears: https://passt.top/passt/commit/?id=04701702471ececee362669cc6b49ed9e20a1b6d
• a short (10 ms timeout) wait in passt for passt-repair to connect, so that if the migration flow starts while passt-repair is still connecting (never observed in tests, but possible in theory), passt will wait for the helper before proceeding: https://passt.top/passt/commit/?id=c8b520c0625b440d0dcd588af085d35cf46aae2c

With these changes, passt-repair can be started on the target before libvirt starts migrating, e.g. passt-repair /run/user/1000/libvirt/qemu/run/passt/, or, in KubeVirt case, /run/user/107/libvirt/qemu/run/passt/.