Re: [PATCH 0/9] vhost-user: Migration support

[Stefano Brivio <sbrivio@redhat.com>]

Just some assorted notes from testing for the moment:

On Thu, 19 Dec 2024 12:13:51 +0100
Laurent Vivier <lvivier@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