[Xen-devel] Nested HVM in xen-unstable tests

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

osstest service owner writes ("[xen-unstable test] 64750: regressions - FAIL"):
> flight 64750 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/64750/
...
>  test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail baseline 
> untested

It appears that this new test case is failing in xen-unstable.  The
logs are here:

  
http://logs.test-lab.xenproject.org/osstest/logs/64750/test-amd64-amd64-qemuu-nested/info.html

If you would like to avoid this feature regressing, you probably want
to figure out what is wrong and send patches to fix it.  In the
meantime, the test will continue to fail in osstest but this will
not block pushes and will not impede anyone else's work.


The primary failure symptom detected by osstest is visible here:

http://logs.test-lab.xenproject.org/osstest/logs/64750/test-amd64-amd64-qemuu-nested/16.ts-debian-hvm-install.log

Near the end:

  ssh: connect to host 172.16.146.31 port 22: No route to host

Searching for 172.16.146.31 from the top of that log shows this:

  2015-11-19 16:24:15 Z guest l1.guest.osstest: 5a:36:0e:ee:00:15 172.16.146.31

So, at some point during the L2 install, the L1 has fallen off the
network.  "No route to host" almost certainly means it has stopped
responding to ARP requests.

The L1's `serial console' log (actually, the log captured by the L0 on
the L1' emulated serial port) is here:

  
http://logs.test-lab.xenproject.org/osstest/logs/64750/test-amd64-amd64-qemuu-nested/rimava0---var-log-xen-osstest-serial-l1.guest.osstest.log

That shows

  (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to 
DOM0)

which is a result of ts-logs-capture sending it the debug keys (which
you can see here

  
http://logs.test-lab.xenproject.org/osstest/logs/64750/test-amd64-amd64-qemuu-nested/17.ts-logs-capture.log

  2015-11-19 16:27:33 Z spawning ssh -o StrictHostKeyChecking=no -o 
BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 -o 
PasswordAuthentication=no -o ChallengeResponseAuthentication=no -o 
UserKnownHostsFile=tmp/t.known_hosts_64750.test-amd64-amd64-qemuu-nested 
root@xxxxxxxxxxxxx 'cat 
>/root/64750.test-amd64-amd64-qemuu-nested.l1.guest.osstest.serial.in'
  2015-11-19 16:27:33 Z xenuse sending request for input to Xen

So the L1 hasn't completely crashed.

During the log capture, ossstest correctly diagnoses that the L1 is
unreachable.  osstest would then normally `power cycle' the `host',
but in the version of osstest used for this test, that functionality
is broken.  This was fixed in my recent set of patches which have
passed the osstest push gate, and we will soon start to see test
reports which are using the fixed version.

You can see a similar failure with better logs here:

  
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38313/test-amd64-amd64-qemuu-nested/info.html


Let me know if I can do more to help point you to the right bits of
the logs, etc.  Good luck.

Regards,
Ian.

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