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

[Xen-devel] [libvirt test] 106736: trouble: blocked/broken/fail/pass



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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm   3 host-install(3)        broken REGR. vs. 106707

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

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
 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
 build-arm64-pvops             5 kernel-build                 fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check        fail   never pass

version targeted for testing:
 libvirt              445708bc77d60afac1318f021dbb4d2a67618547
baseline version:
 libvirt              c5781e37a092e6222ff286c2835a92abe668bed3

Last test of basis   106707  2017-03-16 04:20:27 Z    1 days
Testing same since   106736  2017-03-17 04:20:11 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Berrange <berrange@xxxxxxxxxx>
  Guido Günther <agx@xxxxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>

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                                  broken  
 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

broken-step test-amd64-i386-libvirt-xsm host-install(3)

Not pushing.

------------------------------------------------------------
commit 445708bc77d60afac1318f021dbb4d2a67618547
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Thu Mar 16 11:16:50 2017 +0100

    docs: Document NVDIMM
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 83c1ab5838c74a200da6ece156da06cbeea0a9b2
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Wed Mar 15 18:04:36 2017 +0000

    Report what TLS priority string we use for a session
    
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit 7310739d1f1c766c0607ef4279b0e676a253ad84
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Wed Mar 15 18:03:37 2017 +0000

    Short circuit SASL auth when no mechanisms are available
    
    If the SASL config does not have any mechanisms we currently
    just report an empty list to the client which will then
    fail to identify a usable mechanism. This is a server config
    error, so we should fail immediately on the server side.
    
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit 887450cbdfc25e99d07c06245108064de2c41b1b
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Wed Mar 15 18:02:40 2017 +0000

    Sanity check explicit TLS file paths
    
    When providing explicit x509 cert/key paths in libvirtd.conf,
    the user must provide all three. If one or more is missed,
    this leads to obscure errors at runtime when negotiating
    the TLS session
    
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit 27cd76350021d36b9bd8b187ce5c8919659e3806
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Wed Mar 15 16:51:51 2017 +0000

    Increase default file handle limits for daemons
    
    Linux still defaults to a 1024 open file handle limit. This causes
    scalability problems for libvirtd / virtlockd / virtlogd on large
    hosts which might want > 1024 guest to be running. In fact if each
    guest needs > 1 FD, we can't even get to 500 guests. This is not
    good enough when we see machines with 100's of physical cores and
    TBs of RAM.
    
    In comparison to other memory requirements of libvirtd & related
    daemons, the resource usage associated with open file handles
    is essentially line noise. It is thus reasonable to increase the
    limits unconditionally for all installs.
    
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit b2aca2db7e4793705815b4169a2e527ea2534dc3
Author: Guido Günther <agx@xxxxxxxxxxx>
Date:   Thu Mar 16 08:39:32 2017 +0100

    libxl: fix typo in debug message

commit f014247fde802a0c8fc20f667f4f9a3d19863fd2
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Mar 15 13:03:15 2017 +0100

    docs: Document adaptive timeout for qemu monitor
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 85af0b803cd19a03f71bd01ab4e045552410368f
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Sat Mar 11 07:23:42 2017 +0100

    qemu: Adaptive timeout for connecting to monitor
    
    There were couple of reports on the list (e.g. [1]) that guests
    with huge amounts of RAM are unable to start because libvirt
    kills qemu in the initialization phase. The problem is that if
    guest is configured to use hugepages kernel has to zero them all
    out before handing over to qemu process. For instance, 402GiB
    worth of 1GiB pages took around 105 seconds (~3.8GiB/s). Since we
    do not want to make the timeout for connecting to monitor
    configurable, we have to teach libvirt to count with this
    fact. This commit implements "1s per each 1GiB of RAM" approach
    as suggested here [2].
    
    1: https://www.redhat.com/archives/libvir-list/2017-March/msg00373.html
    2: https://www.redhat.com/archives/libvir-list/2017-March/msg00405.html
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 67dcb797ed7f1fbb048aa47006576f424923933b
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Mon Mar 13 11:05:08 2017 +0100

    virTimeBackOffWait: Avoid long periods of sleep
    
    While connecting to qemu monitor, the first thing we do is wait
    for it to show up. However, we are doing it with some timeout to
    avoid indefinite waits (e.g. when qemu doesn't create the monitor
    socket at all). After beaa447a29 we are using exponential back
    off timeout meaning, after the first connection attempt we wait
    1ms, then 2ms, then 4 and so on.  This allows us to bring down
    wait time for small domains where qemu initializes quickly.
    However, on the other end of this scale are some domains with
    huge amounts of guest memory. Now imagine that we've gotten up to
    wait time of 15 seconds. The next one is going to be 30 seconds,
    and the one after that whole minute. Well, okay - with current
    code we are not going to wait longer than 30 seconds in total,
    but this is going to change in the next commit.
    
    The exponential back off is usable only for first few iterations.
    Then it needs to be caped (one second was chosen as the limit)
    and switch to constant wait time.
    
    Signed-off-by: Michal Privoznik <mprivozn@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®.