[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-unstable test] 61521: regressions - FAIL
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |