[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [libvirt test] 106594: regressions - FAIL



flight 106594 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106594/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm   5 xen-install              fail REGR. vs. 106562

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt     13 saverestore-support-check    fail  like 106562
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check    fail  like 106562
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check    fail  like 106562

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 build-arm64-libvirt           1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 build-arm64-pvops             5 kernel-build                 fail   never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check        fail   never pass
 build-arm64-xsm               5 xen-build                    fail   never pass
 build-arm64                   5 xen-build                    fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check        fail   never pass

version targeted for testing:
 libvirt              0623945c401c04e53d2e26557774ff279a7f65e1
baseline version:
 libvirt              b2e5de96c7f3347c2463ca96932e9f4719be2a45

Last test of basis   106562  2017-03-09 04:21:54 Z    2 days
Failing since        106583  2017-03-10 04:20:35 Z    1 days    2 attempts
Testing same since   106594  2017-03-11 04:21:05 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Berrange <berrange@xxxxxxxxxx>
  John Ferlan <jferlan@xxxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>
  Pavel Hrdina <phrdina@xxxxxxxxxx>
  Peter Krempa <pkrempa@xxxxxxxxxx>
  Roman Bogorodskiy <bogorodskiy@xxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              fail    
 build-armhf-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  fail    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          blocked 
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-armhf-armhf-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  fail    
 test-amd64-amd64-libvirt                                     pass    
 test-arm64-arm64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-arm64-arm64-libvirt-qcow2                               blocked 
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-amd64-libvirt-vhd                                 pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 0623945c401c04e53d2e26557774ff279a7f65e1
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Sun Jan 29 11:12:48 2017 -0500

    tests: Add createVHBAByStoragePool-by-parent to fchosttest
    
    Add a new test to fchosttest in order to test creation of our vHBA
    via the Storage Pool logic.  Unlike the real code, we cannot yet use
    the virVHBA* API's because they (currently) traverse the file system
    in order to get the parent vport capable scsi_host. Besides there's
    no "real" NPIV device here - so we have to take some liberties, at
    least for now.
    
    Instead, we'll follow the node device tests partially in order to
    create and destroy the vHBA with the test node devices.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit e915942b05d3c97b9b2b412b0cce43045a5628d1
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Fri Mar 10 13:34:15 2017 +0100

    qemuProcessHandleMonitorEOF: Disable namespace for domain
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1430634
    
    If a qemu process has died, we get EOF on its monitor. At this
    point, since qemu process was the only one running in the
    namespace kernel has already cleaned the namespace up. Any
    attempt of ours to enter it has to fail.
    
    This really happened in the bug linked above. We've tried to
    attach a disk to qemu and while we were in the monitor talking to
    qemu it just died. Therefore our code tried to do some roll back
    (e.g. deny the device in cgroups again, restore labels, etc.).
    However, during the roll back (esp. when restoring labels) we
    still thought that domain has a namespace. So we used secdriver's
    transactions. This failed as there is no namespace to enter.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 33feb666087db3757023d916db4365fc99bc554f
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Fri Mar 3 09:46:16 2017 +0000

    Document preferred naming conventions
    
    This documents the preferred conventions for naming files,
    structs, enums, typedefs and functions.
    
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit 887ffbce43144314d730a6a3cdd7396318a148ce
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Fri Mar 10 09:55:43 2017 +0100

    qemuxml2argvtest: Don't overwrite driver stateDir
    
    This is a very historic artefact. Back in the old days of
    830ba76c3e when we had macros to add arguments onto qemu command
    line (!) we thought it was a good idea to let qemu write out the
    PID file. So we passed -pidfile $stateDir/$domName onto the
    command line. Thus, in order for tests to work we needed stable
    stateDir in the qemu driver. Unfortunately, after 16efa11aa696
    where stateDir is mkdtemp()-d, this approach lead to a leak of
    temp dir.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 8af68ea47830b8d32907dc50c6ca4869d14bb862
Author: Peter Krempa <pkrempa@xxxxxxxxxx>
Date:   Fri Mar 3 16:04:57 2017 +0100

    qemu: hotplug: Reset device removal waiting code after vCPU unplug
    
    If the delivery of the DEVICE_DELETED event for the vCPU being deleted
    would time out, the code would not call 'qemuDomainResetDeviceRemoval'.
    
    Since the waiting thread did not unregister itself prior to stopping the
    waiting the monitor code would try to wake it up instead of dispatching
    it to the event worker. As a result the unplug process would not be
    completed and the definition would not be updated.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1428893
              https://bugzilla.redhat.com/show_bug.cgi?id=1427801

commit d59ca1204893f5826feebbc99ab249150aef74b2
Author: Peter Krempa <pkrempa@xxxxxxxxxx>
Date:   Fri Mar 3 16:02:01 2017 +0100

    qemu: hotplug: Add debug log when dispatching device removal to existing 
thread
    
    Note that the waiting thread is signaled in the debug logs to simplify
    debugging.

commit c27020dd4f6ddb9ef5354e75dc7005a5efafe536
Author: Pavel Hrdina <phrdina@xxxxxxxxxx>
Date:   Thu Mar 9 14:55:44 2017 +0100

    Revert "conf: move iothread XML validation from qemu_command"
    
    This reverts commit c96bd78e4e71c799dc391566fa9f0652dec55dca.
    
    So our code is one big mess and we modify domain definition while
    building qemu_command line and our hotplug code share only part
    of the parsing and command line building code.  Let's revert
    that change because to fix it properly would require refactor and
    move a lot of things.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430275

commit 33ae335198cf3f60638bca2e4ffb99b74deb9c05
Author: Roman Bogorodskiy <bogorodskiy@xxxxxxxxx>
Date:   Sun Mar 5 18:17:22 2017 +0400

    configure: disable scsi stroage driver on non-Linux
    
    Even though scsi storage driver builds fine on non-Linux, it
    will not work properly because it relies on Linux procfs, so
    disable that in configure if we're not building for Linux.

commit cba1672de8b0220869ede5f9f26a0767e8a390eb
Author: Pavel Hrdina <phrdina@xxxxxxxxxx>
Date:   Mon Feb 27 17:16:17 2017 +0100

    conf: properly skip graphics listen element in migratable XML
    
    We should skip <listen type='socket'/> only if the 'socket' path
    is specified because if there is no 'socket' path we need to
    keep that element in migratable XML.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1366088
    
    Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx>

commit cd4a8b9304bfcbfbf6ff70f814a6f18e8d84077a
Author: Pavel Hrdina <phrdina@xxxxxxxxxx>
Date:   Mon Feb 27 17:00:15 2017 +0100

    conf: store "autoGenerated" for graphics listen in status XML
    
    When libvirtd is started we call qemuDomainRecheckInternalPaths
    to detect whether a domain has VNC socket path generated by libvirt
    based on option from qemu.conf.  However if we are parsing status XML
    for running domain the existing socket path can be generated also if
    the config XML uses the new <listen type='socket'/> element without
    specifying any socket.
    
    The current code doesn't make difference how the socket was generated
    and always marks it as "fromConfig".  We need to store the
    "autoGenerated" value in the status XML in order to preserve that
    information.
    
    The difference between "fromConfig" and "autoGenerated" is important
    for migration, because if the socket is based on "fromConfig" we don't
    print it into the migratable XML and we assume that user has properly
    configured qemu.conf on both hosts.  However if the socket is based
    on "autoGenerated" it means that a new feature was used and therefore
    we need to leave the socket in migratable XML to make sure that if
    this feature is not supported on destination the migration will fail.
    
    Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx>

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.