[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] arp during live migration


  • To: "Graham, Simon" <Simon.Graham@xxxxxxxxxxx>
  • From: Jacob Gorm Hansen <jacobg@xxxxxxx>
  • Date: Sat, 03 Mar 2007 17:21:35 +0100
  • Cc: Cristian Zamfir <zamf@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sat, 03 Mar 2007 08:21:06 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding:sender; b=VJuYaWe4PlfFYIlUM9gGXnKiSwiCiR1QelSWpzEtxI2yScLflFYBjUq94Bjy73Sd/Hcd1UifsGq8S35PuoySFH5z3OsUMKxEszOFzuTXaJiMNJEf/UkUyoT+nHTCNVitFTDgsR4JJFLL+G+S28ulX08WwF5q48W40P+ARHG3RCM=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Fri, 2007-03-02 at 17:22 -0500, Graham, Simon wrote:
> > I am having some trouble with the send_fake_arp in the netfront
> driver.
> > 
> 
> Interesting - I was just composing an almost identical note; we've been
> seeing some horrible network blackouts in migration that are caused by a
> failure to send the gratuitous ARP (blackouts vary from 0-50+ seconds
> when the domain is idle and just being pinged from outside).

When I was last doing this with self-migration, I would resend the ARP
reply several times after arrival, as in any case the packet may get
lost due to a collision etc. This is pretty trivial with self-migration
because is controlled by a guest userspace program -- I suppose that
doing it in netfront would require a short-lived kernel thread. Or
perhaps this should just all be handled by dom0, since we are talking
hosted migration anyway. Actually, having netfront send out protocol
dependent packets is quite ugly, and makes netfront depend on IP being
enabled, which is all wrong (see link error below when disabling IP in
xenlinux).

If the ARP is only being used to advertise the move of the MAC to a new
port, it would be better to construct some kind of reliable protocol,
e.g. pinging a remote host (like the default GW) until an answer comes
back. This should be enough to make sure the switch got the message. If
the ARP is used for updating peer ARP caches, pinging everyone in the
guest's /proc/net/arp table until a majority have replied would be a
solution.

Here is the link error from 3.0.3 linux guest with IP disabled:

....
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
drivers/built-in.o: In function `send_fake_arp':
netfront.c:(.text+0x21ae2): undefined reference to `inet_select_addr'
netfront.c:(.text+0x21b08): undefined reference to `arp_create'
drivers/built-in.o: In function `netif_init':
netfront.c:(.init.text+0x19cd): undefined reference to
`register_inetaddr_notifier'
drivers/built-in.o: In function `netif_exit':
netfront.c:(.exit.text+0xb2): undefined reference to
`unregister_inetaddr_notifier'
make: *** [.tmp_vmlinux1] Error 1


Jacob


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.