This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [xen-4.0-testing test] 2045: regressions - FAIL

Ian Campbell writes ("Re: [Xen-devel] [xen-4.0-testing test] 2045: regressions 
- FAIL"):
> This is with a PVops domU kernel? If so then I'm surprised this is a
> regression rather than a never passed. Until very recently a pvops
> kernel would not even attempt to send a gratuitous ARP after a
> migration, which could lead to 20-30s timeouts like this. (I suppose it
> might spuriously pass if a test run got very lucky?)

That's quite likely.  arp timeouts are typically a few minutes so you
have maybe a 10% chance of getting lucky.  One pass in the past and
the tests will consider it a pass.

> Even with the fix in place the gratuitous ARP behaviour is disabled by
> default so you need to enable the net.ipv4.conf.<dev>.arp_notify sysctl
> for any device you want to send the notifications. When I was testing I
> did this by adding
>         net.ipv4.conf.default.arp_notify = 1
> to /etc/sysctl.conf and that seemed to do the trick.

I think this is a bug.  I think the default should be for something to
send this gratuitous arp and the most logical answer in the PV or
PV-on-HVM case is the domU.

However: all of this doesn't apply to the test network used for these
tests.  There is a daemon on that network which sends broadcast ARP
who-has packets for every IP address at very short intervals (5s or
so) and the reply will cause the switches to update their ideas of
MAC<->port mapping.


Xen-devel mailing list