I've implemented code to send out bogus gratuitous ARP packet from vna in order to fix CR 6701114. The webrev is at: http://jurassic.eng/net/consulte.prc/export/build/xvm-6701114/webrev
Some backgroud information (see CR 6701114 for more detail): During live migration of an xVM domain from one dom0 to another, the VNIC will be moved from one switch port to another. But, the corresponding entry in <MAC,port> table on the switch will not be updated automatically. Thus, all packets to the domU will still be sent to the original port instead of the current one after the migration. This situation will last for some time till the domU sends out something, or the <MAC,port> entry becomes stale. A typical case is, after live migration of an Windows XP domU, you won't be able to talk to (e.g. ping) it for about a minute. Note: This problem only happens with HVM domUs without PV frontend nic driver running inside the domU. PV frontend nic driver will send out a gratuitous ARP packet after migration anyway. So, my approach is to send out a gratuitous ARP request packet from vna after the VNIC is created to teach the switch the new port for the MAC. A problem with this approach is the packet is sent from dom0 on behalf of the domU. So, there is no way to know the IP of the domU. Thus, I simply send an ARP request with IP and MAC field for both src and dst set to 0. Is there any flaw with this approach? Your comments are very much appreciated :). Thanks, Max _______________________________________________ networking-discuss mailing list [email protected]
