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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install      fail REGR. vs. 101200

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestore            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
 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-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestore            fail   never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     14 guest-saverestore            fail   never pass

version targeted for testing:
 libvirt              a46aa8852fe7d7c906d2845f152f645467c9fc6c
baseline version:
 libvirt              f4332dd2d8535b10eef8bce14bf7dc61200495f1

Last test of basis   101200  2016-09-29 04:30:48 Z    1 days
Testing same since   101218  2016-09-30 04:20:33 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  John Ferlan <jferlan@xxxxxxxxxx>
  Laine Stump <laine@xxxxxxxxx>
  Martin Kletzander <mkletzan@xxxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>
  Roman Bogorodskiy <bogorodskiy@xxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-armhf-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 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-armhf-armhf-libvirt-xsm                                 fail    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     fail    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-armhf-armhf-libvirt-qcow2                               fail    
 test-armhf-armhf-libvirt-raw                                 fail    
 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 a46aa8852fe7d7c906d2845f152f645467c9fc6c
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Thu Sep 29 13:38:07 2016 -0400

    docs: correct version requirements for <kvm><hidden='on'/></kvm>
    
    When support was added for the kvm hidden='on' attribute in commit
    d07116, the version requirement was listed as "2.1.0 (QEMU
    only)". However, this was added when libvirt was at version 1.2.8 - it
    is *QEMU* that must be at version 2.1.0 or later.
    
    This went unnoticed for a very long time (over 2 years). Then a week
    or two ago a new Windows convert in the #virt channel on OFTC was told
    he needed to use this feature (to prevent nvidia drivers in a guest
    from refusing to work due to being run in a virtual machine). There
    was some problem with it being recognized and "someone" (it may have
    been me, or may have been someone else, I don't remember) pointed out
    that the documentation at
    
      http://www.libvirt.org/formatdomain.html
    
    says that it requires libvirt 2.1.0. The next several days were filled
    with agony as a new convert to Linux first tried to upgrade a Linux
    Mint host running their "LTS" version to something newer, then tried
    to install a libvirt build built for Ubuntu onto this, and later back
    to the old LTS Linux Mint. After this he tried building his own
    libvirt from source (with all the expected problems), and finally
    switched to Fedora. In the end it was hours and hours of everybody's
    lives that they will never get back. To now learn that he didn't need
    to do this (his original libvirt version was 1.3.3, so whatever his
    problem was, it was elsewhere) makes the pain all that much worse.
    
    To prevent this from happening again, this simple patch changes the
    version requirement for the kvm hidden attribute from "2.1.0 (QEMU
    only)" to "1.2.8 (QEMU 2.1.0)".

commit 5fe66ea3bfdae386064f782b9128f45f2ac37f64
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Thu Sep 15 13:05:34 2016 +0200

    sanlock: Properly init io_timeout
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1292984
    
    Hold on to your hats, because this is gonna be wild.
    
    In bd3e16a3 I've tried to expose sanlock io_timeout. What I had
    not realized (because there is like no documentation for sanlock
    at all) was very unusual way their APIs work. Basically, what we
    do currently is:
    
        sanlock_add_lockspace_timeout(&ls, io_timeout);
    
    which adds a lockspace to sanlock daemon. One would expect that
    io_timeout sets the io_timeout for it. Nah! That's where you are
    completely off the tracks. It sets timeout for next lockspace you
    will probably add later. Therefore:
    
       sanlock_add_lockspace_timeout(&ls, io_timeout = 10);
       /* adds new lockspace with default io_timeout */
    
       sanlock_add_lockspace_timeout(&ls, io_timeout = 20);
       /* adds new lockspace with io_timeout = 10 */
    
       sanlock_add_lockspace_timeout(&ls, io_timeout = 40);
       /* adds new lockspace with io_timeout = 20 */
    
    And so on. You get the picture.
    Fortunately, we don't allow setting io_timeout per domain or per
    domain disk. So we just need to set the default used in the very
    first step and hope for the best (as all the io_timeout-s used
    later will have the same value).
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 2bca7cec0ba9e861edb245f20d99d5b6fd22f760
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Thu Sep 15 10:45:26 2016 +0200

    m4: Check for sanlock_write_lockspace
    
    Currently, we are checking for sanlock_add_lockspace_timeout
    which is good for now. But in a subsequent patch we are going to
    use sanlock_write_lockspace (which sets an initial value for io
    timeout for sanlock). Now, there is no reason to check for both
    functions in sanlock library as the sanlock_write_lockspace was
    introduced in 2.7 release and the one we are currently checking
    for in the 2.5 release. Therefore it is safe to assume presence
    of sanlock_add_lockspace_timeout when sanlock_write_lockspace
    is detected.
    
    Moreover, the macro for conditional compilation is renamed to
    HAVE_SANLOCK_IO_TIMEOUT (as it now encapsulates two functions).
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 78da4296a614c5d8a777ea2de8380ea11208e59b
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Thu Sep 15 13:18:13 2016 +0200

    lock_driver_sanlock: Avoid global driver variable whenever possible
    
    Global variables are bad, we should avoid using them.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit ff3112f3dc2c276a7e387ff7bb86f4fbbdf7bf2c
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Fri Sep 23 11:31:30 2016 +0200

    qemu: Only use memory-backend-file with NUMA if needed
    
    If this reminds you of a commit message from around a year ago, it's
    41c2aa729f0af084ede95ee9a06219a2dd5fb5df and yes, we're dealing with
    "the same thing" again.  Or f309db1f4d51009bad0d32e12efc75530b66836b and
    it's similar.
    
    There is a logic in place that if there is no real need for
    memory-backend-file, qemuBuildMemoryBackendStr() returns 0.  However
    that wasn't the case with hugepage backing.  The reason for that was
    that we abused the 'pagesize' variable for storing that information, but
    we should rather have a separate one that specifies whether we really
    need the new object for hugepage backing.  And that variable should be
    set only if this particular NUMA cell needs special treatment WRT
    hugepages.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372153
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit bcfa2f427d53264830ff5fa5d029b6897773702d
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Wed Sep 28 15:01:55 2016 -0400

    vsh: Write out history on "quit" or "exit" in interactive mode
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1379895
    
    Introduced by commit id '834c5720'.
    
    During the code motion and creation of vsh.c, the function 'vshDeinit()'
    in the (new) vsh.c was altered from whence it came in virsh.c such that
    calling 'vshReadlineDeinit(ctl)' was conditional on "ctl->imode".
    
    This causes a problem for the interactive running if the "quit" and "exit"
    commands are used because 'cmdQuit' will clear ctl->imode, thus when the
    interactive loop in main() of virsh.c exits because ctl->mode is clear and
    virshDeinit is called which calls vshDeinit, the history file is now not
    written. Conversely, if one had exited the interactive loop via pressing
    <ctrl>D the file would be created because loop control is broken on EOF
    and ctl->imode is not set to false.
    
    This patch will remove the conditional call to vshReadlineDeinit and
    restore the former behaviour.

commit 13aa79842cfa6c20c3b768c2ccd283bb5ef9e071
Author: Roman Bogorodskiy <bogorodskiy@xxxxxxxxx>
Date:   Thu Sep 29 08:10:33 2016 +0300

    bhyve: chase cpuCompareXML rename
    
    In commit 7f127de cpuCompareXML was renamed to virCPUCompareXML,
    so change the bhyve driver to use the new function and thus
    fix the build.

_______________________________________________
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®.