[libvirt test] 63528: regressions - FAIL

[osstest service owner <osstest-admin@xenproject.org>]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 63340

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 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-i386-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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass

version targeted for testing:
 libvirt              ac339206bfe98e78925b183cba058d0e2e7f03e3
baseline version:
 libvirt              3c7590e0a435d833895fc7b5be489e53e223ad95

Last test of basis    63340  2015-10-28 04:19:47 Z    7 days
Failing since         63352  2015-10-29 04:20:29 Z    6 days    5 attempts
Testing same since    63373  2015-10-30 04:21:45 Z    5 days    4 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laine Stump <laine@laine.org>
  Luyao Huang <lhuang@redhat.com>
  Maxim Perevedentsev <mperevedentsev@virtuozzo.com>
  Michal Privoznik <mprivozn@redhat.com>
  Roman Bogorodskiy <bogorodskiy@gmail.com>

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                                          fail    
 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                                 blocked 
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-armhf-armhf-libvirt-qcow2                               blocked 
 test-armhf-armhf-libvirt-raw                                 blocked 
 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 ac339206bfe98e78925b183cba058d0e2e7f03e3
Author: Laine Stump <laine@laine.org>
Date:   Thu Oct 29 14:09:59 2015 -0400

    util: set max wait for IPv6 DAD to 20 seconds
    
    This was originally set to 5 seconds, but times of 5.5 to 7 seconds
    were experienced. Since it's an arbitrary number intended to prevent
    an infinite hang, having it a bit too high won't hurt anything, and 20
    seconds looks to be adequate (i.e. I think/hope we don't need to make
    it tunable in libvirtd.conf)

commit d41a64a1948c88ccec5b4cff34fd04d3aae7a71e
Author: Luyao Huang <lhuang@redhat.com>
Date:   Thu Oct 29 17:47:33 2015 +0800

    util: set error if DAD is not finished
    
    If DAD not finished in 5 seconds, user will get an
    unknown error like this:
    
     # virsh net-start ipv6
     error: Failed to start network ipv6
     error: An error occurred, but the cause is unknown
    
    Call virReportError to set an error.
    
    Signed-off-by: Luyao Huang <lhuang@redhat.com>

commit 7c8250d76561e83adf96b8e167f6932132252744
Author: Michal Privoznik <mprivozn@redhat.com>
Date:   Tue Oct 27 14:02:19 2015 +0100

    wireshark: Install to generic plugin directory
    
    There has been a report on the list [1] that we are not
    installing the wireshark dissector into the correct plugin
    directory. And in fact we are not. The problem is, the plugin
    directory path is constructed at compile time. However, it's
    dependent on the wireshark version, e.g.
    
      /usr/lib/wireshark/plugins/1.12.6
    
    This is rather unfortunate, because if libvirt RPMs were built
    with one version, but installed on a system with newer one, the
    plugins are not really loaded. This problem lead fedora packagers
    to unify plugin path to:
    
      /usr/lib/wireshark/plugins/
    
    Cool! But this was enabled just in wireshark-1.12.6-4. Therefore,
    we must require at least that version.
    
    And while at it, on some distributions, the wireshark.pc file
    already has a variable that defines where plugin dir is. Use that
    if possible.
    
    1: https://www.redhat.com/archives/libvirt-users/2015-October/msg00063.html
    
    Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

commit 2589ca30196b305956f4211bc08132b63f77b6f2
Author: Roman Bogorodskiy <bogorodskiy@gmail.com>
Date:   Thu Oct 29 07:20:16 2015 +0300

    Fix virNetDevWaitDadFinish stub
    
    Build on non-Linux fails because the virNetDevWaitDadFinish() stub
    has unused parameters. Fix by adding appropriate ATTRIBUTE_UNUSED
    for these parameters.
    
    Pushing under build-breaker rule.

commit 0f7436ca54c9db2d5460bd54e7613f64f4727102
Author: Maxim Perevedentsev <mperevedentsev@virtuozzo.com>
Date:   Tue Oct 20 18:44:18 2015 +0300

    network: wait for DAD to finish for bridge IPv6 addresses
    
    commit db488c79 assumed that dnsmasq would complete IPv6 DAD before
    daemonizing, but in reality it doesn't wait, which creates problems
    when libvirt's bridge driver sets the matching "dummy tap device" to
    IFF_DOWN prior to DAD completing.
    
    This patch waits for DAD completion by periodically polling the kernel
    using netlink to check whether there are any IPv6 addresses assigned
    to bridge which have a 'tentative' state (if there are any in this
    state, then DAD hasn't yet finished). After DAD is finished, execution
    continues. To avoid an endless hang in case something was wrong with
    the kernel's DAD, we wait a maximum of 5 seconds.

commit 131e7245a8336541ee61047eac8ecb447129b963
Author: Maxim Perevedentsev <mperevedentsev@virtuozzo.com>
Date:   Tue Oct 20 18:44:19 2015 +0300

    netlink: add support for multi-part netlink messages.
    
    Such messages do not have NLMSG_ERROR or NLMSG_DONE type
    but they are valid responses. We test 'multi-partness'
    by looking for NLM_F_MULTI flag.

commit 4eac55238f856d29d07a60448adb2e0b2f8e28b5
Author: Luyao Huang <lhuang@redhat.com>
Date:   Mon Oct 12 17:28:15 2015 +0800

    qemu: Use live autoNodeset when numatune placement is auto
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1270715
    
    Commit id '9deb96f' removed the code to fetch the nodeset from the
    CpusetMems cgroup for a running vm in favor of using the return from
    virDomainNumatuneFormatNodeset introduced by commit id '43b67f2e7'.
    However, that API will return the value of the passed 'auto_nodeset'
    when placement is VIR_DOMAIN_NUMATUNE_PLACEMENT_AUTO, which happens
    to be NULL.
    
    Since commit id 'c74d58ad' started using priv->autoNodeset in order
    to manage the auto placement value during qemuProcessStart, it should
    be passed along in order to return the correct value if the domain
    requests the auto placement.
    
    Signed-off-by: Luyao Huang <lhuang@redhat.com>