| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH v3] xen-netfront: delay gARP until backend switch
On Thu, 2011-07-14 at 08:19 +0100, Jan Beulich wrote:
> >>> Laszlo Ersek <lersek@xxxxxxxxxx> 07/13/11 6:11 PM >>>
> >After a guest is live migrated, the xen-netfront driver emits a
> gratuitous ARP
> >message, so that networking hardware on the target host's subnet can
> take
> >notice, and public routing to the guest is re-established. However,
> if the
> >packet appears on the backend interface before the backend is added
> to the
> >target host's bridge, the packet is lost, and the migrated guest's
> peers become
> >unable to talk to the guest.
> >
> >A sufficient two-parts condition to prevent the above is:
> >
> >(1) ensure that the backend only moves to Connected xenbus state
> after its
> >hotplug scripts completed, ie. the netback interface got added to the
> bridge;
> >and
> >
> >(2) ensure the frontend only queues the gARP when it sees the backend
> move to
> >Connected.
> >
> >These two together provide complete ordering. Sub-condition (1) is
> satisfied
> >by pvops commit 43223efd9bfd.
>
> Is it guaranteed that either side not having the respective change
> will still work correctly with the other side having its part of the
> change?
Having only 43223efd9bfd in the backend certainly appears to work
without the frontend piece (or is at least no worse than today).
Since the backend goes to XenbusStateConnected with or without
43223efd9bfd I think this proposed frontend change is also safe
regardless of whether the backend contains 43222... or not.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home