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

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



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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      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-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)               blocked  n/a
 build-arm64-xsm               2 hosts-allocate              broken like 113032
 build-arm64-pvops             2 hosts-allocate              broken like 113032
 build-arm64-xsm               3 capture-logs                broken like 113032
 build-arm64                   2 hosts-allocate              broken like 113032
 build-arm64-pvops             3 capture-logs                broken like 113032
 build-arm64                   3 capture-logs                broken like 113032
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass

version targeted for testing:
 libvirt              a2b240e60e60ffa8b5dbcc336af1274b57c40108
baseline version:
 libvirt              4ee36c33ed371a1d9dfb9cd97b2af0ee08abd3f3

Last test of basis   113032  2017-09-04 04:20:11 Z    1 days
Testing same since   113046  2017-09-05 04:23:42 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@xxxxxxxxxx>
  Daniel P. Berrange <berrange@xxxxxxxxxx>
  Daniel Veillard <veillard@xxxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>
  Richard W.M. Jones <rjones@xxxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              broken  
 build-armhf-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  broken  
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          blocked 
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            broken  
 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                                 blocked 
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-libvirt                                     pass    
 test-arm64-arm64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     blocked 
 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                                 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

broken-step build-arm64-xsm hosts-allocate
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-xsm capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Not pushing.

------------------------------------------------------------
commit a2b240e60e60ffa8b5dbcc336af1274b57c40108
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Mon Sep 4 15:06:16 2017 +0200

    Makefile.nonreentrant: Rebuild against Fedora 26
    
    According to the comments in the file and the git history, the
    list of forbidden symbols was originally built against Fedora 9
    in 2009 (!) and pretty much never refreshed afterwards.
    
    Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit bc0108845c73d165f0abbd940f8755ccfccc1722
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Mon Sep 4 14:04:10 2017 +0200

    docs: Fix typo deamon -> daemon
    
    Suggested-by: Martin Kletzander <mkletzan@xxxxxxxxxx>
    Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx>
    Reviewed-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit 5f5c515bbdcb7ce8db12544033fad393eb2a1c41
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Fri Sep 1 13:47:04 2017 +0100

    event: ignore attempts to replace the event loop impl
    
    Although not previously explicitly documented, the expectation for
    the libvirt event loop is that an implementation is registered early
    in application startup, before calling any libvirt APIs and then
    run forever after. Replacing a previously registered event loop is
    not safe & subject to races even if virConnectClose has been called
    on open handles, due to delayed deregistration of callbacks during
    conenction close.
    
    Reviewed-by: Andrea Bolognani <abologna@xxxxxxxxxx>
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit 5a1a649dcf7f5a51ed117146facc8c45402ea4a3
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Mon Sep 4 12:42:46 2017 +0100

    Add libxslt as build requires for mingw RPMs
    
    The libxslt package is needed since:
    
      commit 94d2d6429d686c5af95115d09c01f3c6bd5ea7c6
      Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
      Date:   Wed Jul 26 17:40:44 2017 +0100
    
        docs: make xmllint & xsltproc compulsory
    
    The native RPM had it already, but mingw build was missing it.
    
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit e703039c203e9dd2dac97291f9c30098efe542a0
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Aug 29 18:11:08 2017 +0200

    lxcStateInitialize: Don't leak driver's caps
    
    Funny thing. So when initializing LXC driver's capabilities,
    firstly the virLXCDriverGetCapabilities() is called. This creates
    new capabilities, stores them under driver->caps, ref() them and
    return them. However, the return value is ignored. Secondly, the
    function is called yet again and since we have driver->caps set,
    they are ref()-ed again an returned. So in the end, driver's
    capabilities have refcount of three when in fact they should have
    refcount of one.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit e8a9929229c3993b47fb22d2afd4994b79b921f2
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Mon Sep 4 12:29:55 2017 +0200

    Post-release version bump to 3.8.0
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit d83dac00d9d3375b08759ad7422f8b1760a08ba2
Author: Daniel Veillard <veillard@xxxxxxxxxx>
Date:   Mon Sep 4 12:14:11 2017 +0200

    Release of libvirt-3.7.0
    
    * docs/news.xml: update for release
    * po/*.po*: regenerated

commit 4c10c38275349805fac325b5c701c399cec0c9a3
Author: Richard W.M. Jones <rjones@xxxxxxxxxx>
Date:   Fri Aug 25 14:36:58 2017 +0100

    vmx: Expose VMware Managed Object Reference (moref) in XML.
    
    If you use the VDDK library to access virtual machines remotely, you
    really need to know the Managed Object Reference ("moref") of the VM.
    This must be passed each time you connect to the API.
    
    For example nbdkit's VDDK plugin requires a moref to be passed to
    mount up a VM's disk remotely:
    
     nbdkit vddk user=root password=+/tmp/rootpw \
                 server=esxi.example.com thumbprint=xx:xx:xx:... \
                 vm=moref=2 \
                 file="[datastore1] Fedora/Fedora.vmdk"
    
    Getting the moref is a huge pain.  To get some idea of what it is, why
    it is needed, and how much trouble it is to get it, see:
    
https://blogs.vmware.com/vsphere/2012/02/uniquely-identifying-virtual-machines-in-vsphere-and-vcloud-part-1-overview.html
    
https://blogs.vmware.com/vsphere/2012/02/uniquely-identifying-virtual-machines-in-vsphere-and-vcloud-part-2-technical.html
    
    However the moref is available conveniently in the internals of the
    libvirt VMX driver.  This patch exposes it as a custom XML element
    using the same "vmware:" namespace which was previously used for the
    datacenterpath (see libvirt commit 636a99058758a044).
    
    It appears in the XML like this:
    
    <domain type='vmware' 
xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'>
      <name>Fedora</name>
    ...
      <vmware:datacenterpath>ha-datacenter</vmware:datacenterpath>
      <vmware:moref>2</vmware:moref>
    </domain>
    
    Note that the moref can appear as either a simple ID (for esx://
    connections) or as a "vm-<ID>" (for vpx:// connections).  It should be
    treated by users as an opaque string.
    
    Signed-off-by: Richard W.M. Jones <rjones@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®.