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

[libvirt test] 100426: regressions - FAIL

flight 100426 libvirt real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 100381

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

version targeted for testing:
 libvirt              9aea8cd4ae76b5f62ea365dd56d4d9beb96bb024
baseline version:
 libvirt              5b8643099a99dc4ee0dac4bf543a874ffc4c314f

Last test of basis   100381  2016-08-10 04:20:25 Z    2 days
Testing same since   100404  2016-08-11 04:20:33 Z    1 days    2 attempts

People who touched revisions under test:
  Chen Hanxiao <chenhanxiao@xxxxxxxxx>
  Cole Robinson <crobinso@xxxxxxxxxx>
  Erik Skultety <eskultet@xxxxxxxxxx>
  Jiri Denemark <jdenemar@xxxxxxxxxx>
  Laine Stump <laine@xxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>

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

Explanation of these reports, and of osstest in general, is at

Test harness code can be found at

Not pushing.

commit 9aea8cd4ae76b5f62ea365dd56d4d9beb96bb024
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Aug 9 19:25:44 2016 +0200

    virNetDevMacVLanCreateWithVPortProfile: Drop @ret
    Usually, this variable is used to hold the return value for a
    function of ours. Well, this is not the case. Its use does not
    match our pattern and therefore it is very misleading. Drop it
    and define an alternative @rc variable, but only in that single
    block where it is needed.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 42712002fd49e7407e3279ebb947f5b7f8faa7f0
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Aug 9 19:23:15 2016 +0200

    virNetDevMacVLanCreateWithVPortProfile: Drop @rc
    This variable is very misleading. We use VIR_FORCE_CLOSE to set
    it to -1 and returning it even though it does not refer to a FD
    at all. It merely holds 0 or -1. Drop it completely. Also, at the
    same time some corner cases are fixed too.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 96e24861564dfdc21b843f00d094d71e696366bd
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Aug 9 18:47:49 2016 +0200

    virNetDevMacVLanCreateWithVPortProfile: Don't mask virNetDevMacVLanTapOpen 
    In this function we create a macvtap device and open its tap
    device. Possibly multiple times. Now the thing is, if opening the
    tap device fails, that is virNetDevMacVLanTapOpen() returns a
    negative value, we unroll all the changes BUT return 0 fooling
    caller into thinking everything went okay.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 856965b36246b26002af409262846317477ea631
Author: Cole Robinson <crobinso@xxxxxxxxxx>
Date:   Wed Aug 10 10:32:03 2016 -0400

    qemu: fix qemu.conf security_driver
    Since a9331394 (first release v2.1.0), specifying a manual
    security_driver setting in qemu.conf causes the daemon to fail to
    start, erroring with 'Duplicate security driver X'.
    The duplicate checking was incorrectly comparing every entry
    against itself, guaranteeing a false positive.

commit a220f43a65cca6c6f2ca268cdbbf8f997b2e2b13
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Sat Aug 6 19:03:31 2016 -0400

    conf: restrict expander buses to connect only to a root bus
    More misunderstanding/mistaken assumptions on my part - I had thought
    that a pci-expander-bus could be plugged into any legacy PCI slot, and
    that pcie-expander-bus could be plugged into any PCIe slot. This isn't
    correct - they can both be plugged ontly into their respective root
    buses. This patch adds that restriction.
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358712

commit b70e3d0123fcb6e22e99d1b272239e03a84262cb
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Fri Aug 5 15:01:08 2016 -0400

    conf: restrict where dmi-to-pci-bridge can be connected
    libvirt had allowed a dmi-to-pci-bridge to be plugged in anywhere a
    normal PCIe endpoint can be connected, but this is wrong - it will
    only work if it's plugged into pcie-root (the PCIe root complex) or a
    pcie-expander-bus (the qemu device pxb-pcie). This patch adjusts the
    connection flags accordingly.
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363648

commit b70e54342bbd1756234e07ed6b22bdd3cd12b689
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Thu Aug 4 13:04:12 2016 -0400

    conf: don't allow connecting upstream-port directly to pce-expander-bus
    I apparently misunderstood Marcel's description of what could and
    couldn't be plugged into qemu's pxb-pcie controller (known as
    pcie-expander-bus in libvirt) - I specifically allowed directly
    connecting a pcie-switch-upstream-port, and it turns out that causes
    the guest kernel to crash.
    This patch forbids such a connection, and updates the xml docs
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1361172

commit 10031fe5f218fe0acbf873a3063ce42a02fa83d9
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Fri Aug 5 21:19:27 2016 -0400

    conf: improve error log when PCI devices don't match requested controller
    The virDomainPCIAddressFlagsCompatible() error logs report that a
    device required a controller that accepted standard PCI endpoint
    devices, or PCI Express endpoint devices, and if hotplug was required
    by the configuration but not provided by the selected controller. But
    the wording of the error messages was apparently confusing (according
    to the bugzilla report referenced below). On top of that, if the
    device was something other than an endpoint device (e.g. a
    pcie-switch-downstream-port) the error message was a complete punt -
    it would just say that the flags were incorrect.
    This patch makes the messages for PCI/PCIe endpoint and hotplug
    requirements more clear, and also specifically indicates what was the
    device type when it is other than an endpoint device.
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363627

commit 4914494eb8e25ff7938a12fd089c746ec6042bbb
Author: Erik Skultety <eskultet@xxxxxxxxxx>
Date:   Tue Aug 9 16:11:26 2016 +0200

    virt-admin: Fix the error when an invalid URI has been provided
    After commit 9d479dd1 fiddled with the cmdConnect's output which used to be 
    bit more verbose prior to the mentioned commit, the program flow would 
    in a quite confusing error if an invalid URI has been provided:
        error: Failed to connect to the admin server
        Connected to the admin server
        error: <some error>
    The problem is that the commit mentioned above relied on the fact that
    connect routine always succeeds which is not true.
    Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx>

commit 300f668c665f1ec0f834917fe8a58b5991322441
Author: Jiri Denemark <jdenemar@xxxxxxxxxx>
Date:   Tue Aug 9 15:15:20 2016 +0200

    cpu_x86: Fix host-model CPUs on hosts with CMT
    Since the introduction of CMT features (commit v1.3.5-461-gf294b83)
    starting a domain with host-model CPU on a host which supports CMT fails
    because QEMU complains about unknown 'cmt' feature:
        qemu-system-x86_64: CPU feature cmt not found
    Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx>

commit 58ba240df89a7dd7bff16ebb65d9aadd49fb8bbb
Author: Jiri Denemark <jdenemar@xxxxxxxxxx>
Date:   Tue Aug 9 15:03:20 2016 +0200

    tests: Add a test for host-model CPU with CMT feature
    The generated command line wouldn't work since QEMU doesn't know what
    'cmt' is. The following patch will fix this issue.
    Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx>

commit 1ac897a15da11d1bfca2642bce3b0beaad32bcf1
Author: Jiri Denemark <jdenemar@xxxxxxxxxx>
Date:   Tue Jun 28 11:12:41 2016 +0200

    cpu_x86: Properly drop non-migratable features
    By removing a non-migratable feature in a for loop we would fail to drop
    every second non-migratable feature if the features array contained
    several of them in a row.
    Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx>

commit dbb14bb0f1316d92c89541fca816c91dce0dc8fb
Author: Jiri Denemark <jdenemar@xxxxxxxxxx>
Date:   Tue Jun 28 10:51:41 2016 +0200

    cpu_x86: Introduce x86FeatureIsMigratable
    Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx>

commit 73b647d4189ced1f0189b53290cf22c1531219bc
Author: Chen Hanxiao <chenhanxiao@xxxxxxxxx>
Date:   Fri Aug 5 15:23:52 2016 +0800

    virsh: clarify snapshot --live
    In libvirt, snapshot means disk snapshot.
    snapshot --live is more like VM checkpoint.
    Make it clear in virsh.pod.
    Signed-off-by: Chen Hanxiao <chenhanxiao@xxxxxxxxx>
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

osstest-output mailing list



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