Just some assorted notes from testing for the moment: On Thu, 19 Dec 2024 12:13:51 +0100 Laurent Vivier <lvivier(a)redhat.com> wrote:This series allows a QEMU guest to be migrated while it is connected to Passt using vhost-user interface.Unrelated thing I found while testing: by mistake I passed the same socket path to both QEMU instances, and on the second one: qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: vhost_backend_init failed: Protocol error qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: failed to init vhost_net for queue 0 qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: Failed to read msg header. Read -1 instead of 12. Original request 1. qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: vhost_backend_init failed: Protocol error qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: failed to init vhost_net for queue 0 qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: Failed to write msg. Wrote -1 instead of 12. qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: vhost_backend_init failed: Protocol error qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: failed to init vhost_net for queue 0 qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: Failed to read msg header. Read -1 instead of 12. Original request 1. qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: vhost_backend_init failed: Protocol error qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: failed to init vhost_net for queue 0 qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: Failed to read msg header. Read -1 instead of 12. Original request 1. qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: vhost_backend_init failed: Protocol error qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: failed to init vhost_net for queue 0 qemu-system-x86_64: -netdev vhost-user,id=netdev0,chardev=chr0: Failed to read msg header. Read -1 instead of 12. Original request 1. ... because passt accepts the connection and drops it right away, which is intended, because it allows us to accept one connection at a time while explicitly telling a new client that we're busy, instead of letting it time out. By the way, I wasn't sure it would work: I can actually keep a 'ping' running between source and destination: -- # ip link set dev eth0 up # dhclient eth0 # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=5.28 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=5.30 ms QEMU 9.2.50 monitor - type 'help' for more information (qemu) 64 bytes from 8.8.8.8: icmp_seq=4 ttl=255 time=5.25 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=255 time=5.30 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=255 time=5.26 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=255 time=5.25 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=255 time=5.23 ms migrate tcp:0:4444 -- -- Vhost user backend fails to broadcast fake RARP 64 bytes from 8.8.8.8: icmp_seq=9 ttl=255 time=5.60 ms [ 81.613893] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 81.615247] clocksource: 'kvm-clock' wd_nsec: 511997099 wd_now: 1359324c64 wd_last: 133aadd7b9 mask: ffffffffffffffff [ 81.616669] clocksource: 'tsc' cs_nsec: 501204363 cs_now: 451415a984 cs_last: 44a889af7c mask: ffffffffffffffff [ 81.618065] clocksource: Clocksource 'tsc' skewed -10792736 ns (18446744073698 ms) over watchdog 'kvm-clock' interval of 511997099 ns (511 ms) [ 81.619720] clocksource: 'kvm-clock' (not 'tsc') is current clocksource. [ 81.620700] tsc: Marking TSC unstable due to clocksource watchdog 64 bytes from 8.8.8.8: icmp_seq=10 ttl=255 time=5.26 ms -- I wonder: should the source QEMU instance close the connection to the source instance of passt? It doesn't happen for me. -- Stefano