Re: [Xen-devel] [xen-unstable test] 61521: regressions - FAIL

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 61521: regressions - 
FAIL"):
> This or some random (but reoccurring) failure.

I agree with Ian C that this isn't likely to be an infrastructure
problem.  It's probably an actual bug.

> Not so long ago I already mentioned that for the purpose of just
> determining whether a guest is up
> 
> ssh: connect to host 172.16.145.6 port 22: Connection refused
> 
> is sufficient, as that means there was a response (albeit a
> negative one).

That depends on what you mean by `up'.  The guest is not `up' in the
sense that it is not providing the services it is supposed to provide
(which include, in this case, an ssh server).

So I think that osstest is correct to regard this as a test failure.

>  But whether the refusal is due to something getting corrupted in
> the networking stack or due to an infrastructure problem is rather
> hard to tell.

Both of these seem unlikely as explanations.

A more likely explanation is that the host sometimes fails to complete
its bootup within a reasonable time.

Possible root causes include but are not limited to:

 * Something wrong with the network frontend/backend causes
   a delay to startup

 * Something else wrong means that the guest sometimes has
   very poor performance

 * The guest has actually locked up or partially locked up during
   boot and currently only kernel interrupt processing is being done

Infrastructure problems are possible of course but I don't think they
are likely.  When we had that BSD lost-gratuitous-arp bug I
investigated the networking in the colo in some depth and there was no
evidence of any packet loss, for example.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel