[libvirt] [RFC] VM which uses macvtap will not respond ping request when being migrated

[Viktor Mihajlovski]

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