Hello! > However, I'm more curious about the ping loss? Did you still see > that? And to be more specific, have the wireshark captured the > GRAP from the guest?
Yes, everything is fine. root at nfv_test_x86_64 /var/log/libvirt/qemu # tshark -i ovs-br0 Running as user "root" and group "root". This could be dangerous. Capturing on 'ovs-br0' 1 0.000000 RealtekU_3b:83:1a -> Broadcast ARP 42 Gratuitous ARP for 192.168.6.2 (Request) 2 0.000024 fe80::5054:ff:fe3b:831a -> ff02::1 ICMPv6 86 Neighbor Advertisement fe80::5054:ff:fe3b:831a (ovr) is at 52:54:00:3b:83:1a 3 0.049490 RealtekU_3b:83:1a -> Broadcast ARP 42 Gratuitous ARP for 192.168.6.2 (Request) 4 0.049497 fe80::5054:ff:fe3b:831a -> ff02::1 ICMPv6 86 Neighbor Advertisement fe80::5054:ff:fe3b:831a (ovr) is at 52:54:00:3b:83:1a 5 0.199485 RealtekU_3b:83:1a -> Broadcast ARP 42 Gratuitous ARP for 192.168.6.2 (Request) 6 0.199492 fe80::5054:ff:fe3b:831a -> ff02::1 ICMPv6 86 Neighbor Advertisement fe80::5054:ff:fe3b:831a (ovr) is at 52:54:00:3b:83:1a 7 0.449500 RealtekU_3b:83:1a -> Broadcast ARP 42 Gratuitous ARP for 192.168.6.2 (Request) 8 0.449508 fe80::5054:ff:fe3b:831a -> ff02::1 ICMPv6 86 Neighbor Advertisement fe80::5054:ff:fe3b:831a (ovr) is at 52:54:00:3b:83:1a 9 0.517229 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x04af, seq=70/17920, ttl=64 10 0.517277 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x04af, seq=70/17920, ttl=64 (request in 9) 11 0.799521 RealtekU_3b:83:1a -> Broadcast ARP 42 Gratuitous ARP for 192.168.6.2 (Request) 12 0.799553 fe80::5054:ff:fe3b:831a -> ff02::1 ICMPv6 86 Neighbor Advertisement fe80::5054:ff:fe3b:831a (ovr) is at 52:54:00:3b:83:1a 13 1.517210 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x04af, seq=71/18176, ttl=64 14 1.517238 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x04af, seq=71/18176, ttl=64 (request in 13) 15 2.517219 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x04af, seq=72/18432, ttl=64 16 2.517256 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x04af, seq=72/18432, ttl=64 (request in 15) 17 3.517497 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x04af, seq=73/18688, ttl=64 18 3.517518 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x04af, seq=73/18688, ttl=64 (request in 17) 19 4.517219 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x04af, seq=74/18944, ttl=64 20 4.517237 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x04af, seq=74/18944, ttl=64 (request in 19) 21 5.517222 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x04af, seq=75/19200, ttl=64 22 5.517242 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x04af, seq=75/19200, ttl=64 (request in 21) 23 6.517235 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x04af, seq=76/19456, ttl=64 24 6.517256 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x04af, seq=76/19456, ttl=64 (request in 23) 25 6.531466 be:e1:71:c1:47:4d -> RealtekU_3b:83:1a ARP 42 Who has 192.168.6.2? Tell 192.168.6.1 26 6.531619 RealtekU_3b:83:1a -> be:e1:71:c1:47:4d ARP 42 192.168.6.2 is at 52:54:00:3b:83:1a 27 7.517212 192.168.6.2 -> 192.168.6.1 ICMP 98 Echo (ping) request id=0x04af, seq=77/19712, ttl=64 28 7.517229 192.168.6.1 -> 192.168.6.2 ICMP 98 Echo (ping) reply id=0x04af, seq=77/19712, ttl=64 (request in 27) But there's one important detail here. Any replicated network interfaces (LOCAL port in my example) should be fully cloned on both hosts, including MAC addresses. Otherwise after the migration the guest continues to send packets to old MAC, and, obvious, there's still ping loss until it redoes the ARP for its ping target. > And what's the output of 'grep virtio /proc/interrupts' inside guest? 11: 0 0 0 0 IO-APIC 11-fasteoi uhci_hcd:usb1, virtio3 24: 0 0 0 0 PCI-MSI 114688-edge virtio2-config 25: 3544 0 0 0 PCI-MSI 114689-edge virtio2-req.0 26: 10 0 0 0 PCI-MSI 49152-edge virtio0-config 27: 852 0 0 0 PCI-MSI 49153-edge virtio0-input.0 28: 3 0 0 0 PCI-MSI 49154-edge virtio0-output.0 29: 10 0 0 0 PCI-MSI 65536-edge virtio1-config 30: 172 0 0 0 PCI-MSI 65537-edge virtio1-input.0 31: 1 0 0 0 PCI-MSI 65538-edge virtio1-output.0 Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
