When TCP client VM is migrated, while a connection between 2 VMs primary UDN interfaces exists, the client must be re-generated after migration is completed.
Same scenario with using the VM's secondary multus interface doesn't require re-launching the connection.

OCP 4.18.0-ec.3
CNV 4.18.0 (brew.registry.redhat.io/rh-osbs/iib:857112)

100%

1.
In a 4.18 cluster - make sure UDN is enabled (go over the "Configuring priamry-UDN on a CNV cluster" section in https://gist.github.com/RamLavi/91a25858a56f87e47039ceef99df662b#file-demo-scenario-1-L35 if necessary).

2.
Create a namespace named `yoss-ns`.

3.
Apply a UserDefinedNetwork like the one attached.

4.
Create 2 VMs with primary UDN interfaces (apply the attached VM specs and run them).

5.
In the console of vm-a run a listening TCP server:
[fedora@vm-a ~]$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

6.
In the console of vm-b run a TCP client which connect to the IP address of the primary interface of vm-a:
[fedora@vm-b ~]$ iperf3 -c 192.168.88.3 -t 0
Connecting to host 192.168.88.3, port 5201
[  5] local 192.168.88.4 port 44676 connected to 192.168.88.3 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  28.4 MBytes   238 Mbits/sec    0    684 KBytes       
[  5]   1.00-2.00   sec  30.6 MBytes   257 Mbits/sec    0    684 KBytes       

7.
Migrate vm-b and wait for the migration to complete:
$ virtctl migrate vm-b
VM vm-b was scheduled to migrate
$
$ oc get vmim -w
NAME                        PHASE        VMI
kubevirt-migrate-vm-f5mxq   Scheduling   vm-b
kubevirt-migrate-vm-f5mxq   Scheduled    vm-b
kubevirt-migrate-vm-f5mxq   PreparingTarget   vm-b
kubevirt-migrate-vm-f5mxq   TargetReady       vm-b
kubevirt-migrate-vm-f5mxq   Running           vm-b
kubevirt-migrate-vm-f5mxq   Succeeded         vm-b

8.
Check vm-a (the server VM) - it says that the client closed the connection, and it returns to an idle listen mode:
iperf3: the client has unexpectedly closed the connection
-----------------------------------------------------------
Server listening on 5201 (test #3)
-----------------------------------------------------------

9.
Open vm-b (the client VM) console again - it shows like the client is still active, but with actually zero traffic:
$ virtctl console vm-b
Successfully connected to vm-b console. The escape sequence is ^]
                                                                 [  5] 181.00-182.00 sec  0.00 Bytes  0.00 bits/sec    0   4.00 KBytes       
[  5] 182.00-183.00 sec  0.00 Bytes  0.00 bits/sec    0   4.00 KBytes       
[  5] 183.00-184.00 sec  0.00 Bytes  0.00 bits/sec    0   4.00 KBytes       
[  5] 184.00-185.00 sec  0.00 Bytes  0.00 bits/sec    0   4.00 KBytes       
[  5] 185.00-186.00 sec  0.00 Bytes  0.00 bits/sec    0   4.00 KBytes       

The connection is not fully alive after migration.
Only by stopping the client iperf3 again, and re-running it in the client VM - the TCP connection is fully re-established.

Connection remains during migration.

The same scenario, but with adding secondary bridge interface to both VMs, and establishing the TCP connection between the secondary interfaces, is successful, meaning that after the migration of the client is completed, there's no need to re-trigger anything.