3:12 a.m.
A vm which uses macvtap will not respond ping request, when the vm is being migrated.
I found that on the destination side the macvtap will send a IPv6 packet at the begin of
migration to update the route table in switch, however VM is still on the src.
In this case , what can I do to avoid VM's network disconnection
Regards,
Wangrui
1:39 p.m.
On 03/18/2014 02:12 AM, Wangrui (K) wrote:
A vm which uses macvtap will not respond ping request, when the vm is
being migrated.
I found that on the destination side the macvtap will send a IPv6 packet at the begin of
migration to update the route table in switch, however VM is still on the src.
In this case , what can I do to avoid VM's network disconnection
Can you provide more details on this? What are the versions of libvirt,
qemu, and kernel on your host system? Can you provide the <interface>
section of the guest's config?
Does this only occur when the guest has IPv6 enabled, and only for an
IPv6 ping? What is the packet that is sent? At the beginning of the
migration the guest is not running on the destination, and the host has
no idea what the guest's IPv6 (or v4) address might be, so it can't send
a IPv6 packet on behalf of the guest. The only thing I can think of
could be something to do with the link-local address (the fe80:...
address that is used for IPv6's discovery and autoconf protocols).
1:15 a.m.
Thanks.
libvirt 1.1.0 qemu 1.5.1 host kernel 3.0.58
guest hasn't ipv6 enabled.
macvtap0 Link encap:Ethernet HWaddr 52:54:00:37:CD:68
inet6 addr: fe80::5054:ff:fe37:cd68/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:468 (468.0 b)
macvtap0 is belong to vm at the dest side. When migrate begins macvtap0 will send the
packet like this:
07:57:59.233270 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group
record(s), lengt 28
07:58:00.096088 IP6 :: > ff02::1:ff6d:4665: ICMP6, neighbor solicitation, who has
fe80::5054:ff:fe6d4665, length 24
07:58:00.123900 IP6 fe80::2a6e:d4ff:fe50:8d7 > ipv6-allrouters: ICMP6, router
solicitation, length 1
07:58:00.175891 IP6 fe80::2a6e:d4ff:fe50:8d7 > ff02::16: HBH ICMP6, multicast listener
report v2, 1 roup record(s), length 28
07:58:01.096089 IP6 fe80::5054:ff:fe6d:4665 > ipv6-allrouters: ICMP6, router
solicitation, length 16
the virNetDevSetOnline in the libvirt makes macvtap0 up on the dest side, so macvtap0
sends the packets.
I do nothing when VM is migrating. The IPv6 packets are sent automatically from the dest
host when it is up.
I guess this makes route table updated in switch.
the configure of macvtap in xml like this
<interface type='direct'>
<source dev='eth4' mode='bridge'/>
<model type='virtio'/>
</interface>
-----Original Message-----
From: sendmail [mailto:justsendmailnothingelse@gmail.com] On Behalf Of Laine Stump
Sent: Saturday, March 22, 2014 2:39 AM
To: libvir-list(a)redhat.com
Cc: Wangrui (K); chenliang (T); Zhaoyanbin (A); Michael S. Tsirkin
Subject: Re: [libvirt] [RFC] VM which uses macvtap will not respond ping request when
being migrated
On 03/18/2014 02:12 AM, Wangrui (K) wrote:
A vm which uses macvtap will not respond ping request, when the vm is
being migrated.
I found that on the destination side the macvtap will send a IPv6 packet at the begin of
migration to update the route table in switch, however VM is still on the src.
In this case , what can I do to avoid VM's network disconnection
Can you provide more details on this? What are the versions of libvirt,
qemu, and kernel on your host system? Can you provide the <interface>
section of the guest's config?
Does this only occur when the guest has IPv6 enabled, and only for an
IPv6 ping? What is the packet that is sent? At the beginning of the
migration the guest is not running on the destination, and the host has
no idea what the guest's IPv6 (or v4) address might be, so it can't send
a IPv6 packet on behalf of the guest. The only thing I can think of
could be something to do with the link-local address (the fe80:...
address that is used for IPv6's discovery and autoconf protocols).
8:41 a.m.
On 03/25/2014 07:15 AM, Wangrui (K) wrote:
macvtap0 is belong to vm at the dest side. When migrate begins
macvtap0 will send the packet like this:
07:57:59.233270 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group
record(s), lengt 28
07:58:00.096088 IP6 :: > ff02::1:ff6d:4665: ICMP6, neighbor solicitation, who has
fe80::5054:ff:fe6d4665, length 24
07:58:00.123900 IP6 fe80::2a6e:d4ff:fe50:8d7 > ipv6-allrouters: ICMP6, router
solicitation, length 1
07:58:00.175891 IP6 fe80::2a6e:d4ff:fe50:8d7 > ff02::16: HBH ICMP6, multicast listener
report v2, 1 roup record(s), length 28
07:58:01.096089 IP6 fe80::5054:ff:fe6d:4665 > ipv6-allrouters: ICMP6, router
solicitation, length 16
the virNetDevSetOnline in the libvirt makes macvtap0 up on the dest side, so macvtap0
sends the packets.
well, what happens here is that the newly created interface is subject
to IPv6 autoconfiguration (you can see that it has obtained an IPv6
link local address). The resulting ICMP6 traffic will update your
switch's MAC address tables as you have correctly observed.
A workaround (but no more) *could be* to disable the IPv6
autoconfiguration for the interface in question (awkward/racy).
A better approach would probably be to not online the macvtap interface
until the domain is really running (here: after the migration was
completed). Would need a rewrite of the network interface code in
the qemu driver.
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
4062
days inactive
4070
days old
3 comments
3 participants
participants (3)
-
Laine Stump -
Viktor Mihajlovski -
Wangrui (K)