From: Pavel Fedin <p.fedin@samsung.com>
To: 'Yuanhan Liu' <yuanhan.liu@linux.intel.com>
Cc: dev@dpdk.org, 'Victor Kaplansky' <victork@redhat.com>
Subject: Re: [dpdk-dev] [PATCH 0/4 for 2.3] vhost-user live migration support
Date: Wed, 16 Dec 2015 15:43:06 +0300 [thread overview]
Message-ID: <006d01d137ff$50650180$f12f0480$@samsung.com> (raw)
In-Reply-To: <20151216120817.GQ29571@yliu-dev.sh.intel.com>
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@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
next prev parent reply other threads:[~2015-12-16 12:43 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 8:26 Pavel Fedin
2015-12-11 9:49 ` Yuanhan Liu
2015-12-11 10:22 ` Pavel Fedin
2015-12-14 3:58 ` Peter Xu
2015-12-14 7:30 ` Pavel Fedin
2015-12-14 9:04 ` Peter Xu
2015-12-14 9:46 ` Pavel Fedin
2015-12-14 10:09 ` Peter Xu
2015-12-14 12:09 ` Yuanhan Liu
2015-12-14 13:00 ` Peter Xu
2015-12-14 13:21 ` Yuanhan Liu
2015-12-14 13:28 ` Peter Xu
2015-12-14 13:51 ` Yuanhan Liu
2015-12-14 14:54 ` Pavel Fedin
2015-12-15 8:23 ` Yuanhan Liu
2015-12-15 8:45 ` Pavel Fedin
2015-12-15 8:56 ` Yuanhan Liu
2015-12-15 9:04 ` Pavel Fedin
2015-12-15 10:05 ` Peter Xu
2015-12-15 11:43 ` Thibaut Collet
2015-12-15 11:47 ` Thibaut Collet
2015-12-15 12:24 ` Pavel Fedin
2015-12-15 13:36 ` Yuanhan Liu
2015-12-15 13:48 ` Pavel Fedin
2015-12-15 13:59 ` Yuanhan Liu
2015-12-15 14:58 ` Pavel Fedin
2015-12-16 7:28 ` Yuanhan Liu
2015-12-16 11:57 ` Pavel Fedin
2015-12-16 12:08 ` Yuanhan Liu
2015-12-16 12:43 ` Pavel Fedin [this message]
2015-12-16 13:00 ` Yuanhan Liu
2015-12-15 13:18 ` Yuanhan Liu
2015-12-15 15:07 ` Thibaut Collet
2015-12-15 15:36 ` Pavel Fedin
2015-12-16 2:38 ` Peter Xu
2015-12-16 2:50 ` Yuanhan Liu
2015-12-16 7:05 ` Pavel Fedin
2015-12-15 9:42 ` Peter Xu
-- strict thread matches above, loose matches on Subject: below --
2015-12-02 3:43 Yuanhan Liu
2015-12-02 14:10 ` Victor Kaplansky
2015-12-02 14:33 ` Yuanhan Liu
2015-12-09 3:41 ` Xie, Huawei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='006d01d137ff$50650180$f12f0480$@samsung.com' \
--to=p.fedin@samsung.com \
--cc=dev@dpdk.org \
--cc=victork@redhat.com \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).