Re: [libvirt test] 92667: regressions - FAIL

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 27/04/2016 22:58, Jim Fehlig wrote:
> On 04/25/2016 05:26 AM, osstest service owner wrote:
>> flight 92667 libvirt real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/92667/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-i386-libvirt      14 guest-saverestore         fail REGR. vs. 91479
>>  test-amd64-amd64-libvirt-xsm 14 guest-saverestore         fail REGR. vs. 91479
>>  test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 91479
>>  test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 91479
>>  test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail REGR. vs. 91479
>>  test-amd64-i386-libvirt-xsm  14 guest-saverestore         fail REGR. vs. 91479
>>  test-amd64-amd64-libvirt-vhd 13 guest-saverestore         fail REGR. vs. 91479
>>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail REGR. vs. 91479
>>  test-amd64-amd64-libvirt     14 guest-saverestore         fail REGR. vs. 91479
> All of these save/restore and migration failures show the following error on the
> restore side
>
> 2016-04-25 10:16:18 UTC libxl: error:
> libxl_exec.c:118:libxl_report_child_exitstatus: conversion helper [26771] exited
> with error status 1
> 2016-04-25 10:16:18 UTC libxl: error: libxl_utils.c:507:libxl_read_exactly:
> file/stream truncated reading ipc msg header from domain 1 save/restore helper
> stdout pipe
> 2016-04-25 10:16:18 UTC libxl: error:
> libxl_exec.c:129:libxl_report_child_exitstatus: domain 1 save/restore helper
> [26772] died due to fatal signal Terminated
>
> I'm not sure if this problem has already been addressed by recent
> migration-related fixes.

This is testing two different versions of libvirt against the same
version of libxl.

Looking at
http://logs.test-lab.xenproject.org/osstest/logs/92667/test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm/italia0---var-log-libvirt-libxl-libxl-driver.log

2016-04-25 08:36:03 UTC xc: progress: End of stream: 0/0    0%

indicates that the save side is in v2 format (which is expected).  (I
should add at least an info print in libxl_stream_write() indicating the
pertinent  details).

On the restore side,

2016-04-25 08:36:20 UTC libxl: debug:
libxl_stream_read.c:358:stream_header_done: Stream v2 (from legacy)
2016-04-25 08:36:20 UTC libxl: debug:
libxl_stream_read.c:574:process_record: Record: 1, length 0
2016-04-25 08:36:20 UTC libxl: error:
libxl_exec.c:118:libxl_report_child_exitstatus: conversion helper [3909]
exited with error status 1

which means that the restore code was told that the stream was in legacy
format.  The legacy conversion script was forked and found that the
stream wasn't legacy.  (I have no idea where the real error message went
from that - it should be plumbed through into a info message, and
definitely does work when running `xl` on the command line).

I suspect this is breakage from the LIBXL_ABI_VERSION changes.

Because of the short-sightest mess that legacy migration was, it is not
possible for libxl to distinguish a legacy stream from a v2 stream in
libxl_domain_create_restore().  The caller (i.e. libvirt) must provide
the correct stream version in libxl_domain_restore_params.

~Andrew

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