Xen devel - Jul 2011 - Re: [PATCH v3] xen-netfront: delay gARP until backend switches to Connected

>>> Laszlo Ersek  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?

Jan



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

On Thu, 2011-07-14 at 08:19 +0100, Jan Beulich wrote:
> >>> Laszlo Ersek <lersek@redhat.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel