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

["Hu, Robert" <robert.hu@xxxxxxxxx>]

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: Friday, November 20, 2015 10:46 PM
> To: Hu, Robert <robert.hu@xxxxxxxxx>
> Cc: osstest service owner <osstest-admin@xxxxxxxxxxxxxx>; Jin, Gordon
> <gordon.jin@xxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Nested HVM in xen-unstable tests
> 
> 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
[Hu, Robert] 

Thanks Ian letting us know about this.
Where can I find the related xen/qemu/dom0 kernel information?

> 
> 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.
> 
[Hu, Robert] 

I thought the test failure would block related patches getting accepted.

> 
> 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.i
> n'
>   2015-11-19 16:27:33 Z xenuse sending request for input to Xen
> 
> So the L1 hasn't completely crashed.
[Hu, Robert] 

Yes. Let me try to reproduce this after you tell me the Xen/qemu/dom0 
version/commit id.

> 
> 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.
[Hu, Robert] 

OK. Thanks.

> 
> You can see a similar failure with better logs here:
> 
> 
> http://osstest.xs.citrite.net/~osstest/testlogs/logs/38313/test-amd64-amd6
> 4-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