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

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



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

Regressions :-(

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

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

version targeted for testing:
 libvirt              b87703cf79559157404667628802d7fe8f9f19a6
baseline version:
 libvirt              2692304c94e631720e8e9444e34a3e445e8da61a

Last test of basis   100866  2016-09-10 04:25:40 Z    3 days
Testing same since   100912  2016-09-13 04:22:08 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Daniel P. Berrange <berrange@xxxxxxxxxx>
  Erik Skultety <eskultet@xxxxxxxxxx>
  Jiri Denemark <jdenemar@xxxxxxxxxx>
  Joao Martins <joao.m.martins@xxxxxxxxxx>
  John Ferlan <jferlan@xxxxxxxxxx>
  Laine Stump <laine@xxxxxxxxx>
  Martin Kletzander <mkletzan@xxxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>
  Nikolay Shirokovskiy <nshirokovskiy@xxxxxxxxxxxxx>
  Peter Krempa <pkrempa@xxxxxxxxxx>

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 b87703cf79559157404667628802d7fe8f9f19a6
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Fri Sep 9 15:26:34 2016 -0400

    conf: allow hotplugging "legacy PCI" device to manually addressed PCIe slot
    
    In a full domain config, libvirt allows overriding the normal PCI
    vs. PCI Express rules when a device address is explicitly provided
    (so, e.g., you can force a legacy PCI device to plug into a PCIe port,
    although libvirt would never do that on its own). However, due to a
    bug libvirt doesn't give this same leeway when hotplugging devices. On
    top of that, current libvirt assumes that *all* devices are legacy
    PCI. The result of all this is that it's impossible to hotplug a
    device into a PCIe port, even if you manually add the PCI address.
    
    This can all be traced to the function
    virDomainPCIAddressEnsureAddr(), and the fact that it calls
    virDomainPCIaddressReserveSlot() for manually set addresses, and that
    function hardcodes the argument "fromConfig" to false (meaning "this
    address was auto-assigned, so it should be subject to stricter
    validation").
    
    Since virDomainPCIAddressReserveSlot() is just a one line simple
    wrapper around virDomainPCIAddressReserveAddr() (adding in a hardcoded
    reserveEntireSlot = true and fromConfig = false), all that's needed to
    solve the problem with no unwanted side effects is to replace that
    call for virDomainPCIAddressReserveSlot() with a direct call to
    virDomainPCIAddressReserveAddr(), but with reserveEntireSlot = true,
    fromConfig = true. That's what this patch does.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1337490

commit 0276015325a746f2cd26ef0fddfc682cf641423f
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Mon Sep 12 13:21:10 2016 -0400

    qemu: fix improper initialization of cgroupControllers bitmap
    
    virQEMUDriverConfigNew() always initializes the bitmap in its
    cgroupControllers member to -1 (i.e. all 1's).
    
    Prior to commit a9331394, if qemu.conf had a line with
    "cgroup_controllers", cgroupControllers would get reset to 0 before
    going through a loop setting a bit for each named cgroup controller.
    commit a9331394 left out the "reset to 0" part, so cgroupControllers
    would always be -1; if you didn't want a controller included, there
    was no longer a way to make that happen.
    
    This was discovered by users who were using qemu commandline
    passthrough to use the "input-linux" method of directing
    keyboard/mouse input to a virtual machine:
    
     https://www.redhat.com/archives/vfio-users/2016-April/msg00105.html
    
    Here's the first report I found of the problem encountered after
    upgrading libvirt beyond v2.0.0:
    
     https://www.redhat.com/archives/vfio-users/2016-August/msg00053.html
    
    Thanks to sL1pKn07 SpinFlo <sl1pkn07@xxxxxxxxx> for bringing the
    problem up in IRC, and then taking the time to do a git bisect and
    find the patch that started the problem.

commit 94e2be842411b9f8ec9165c8d25c93716c1b30ca
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Thu Aug 11 11:40:18 2016 +0200

    audit: Audit information about shmem devices
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1218603
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit 92513bc23a16a165bc5557e0a0916fd072880275
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Mon Sep 12 15:49:28 2016 +0100

    qemu: avoid parameter named 'listen'
    
    previous commit:
    
      commit 2c3223785c121eafbdd503f11549d7964461934f
      Author: John Ferlan <jferlan@xxxxxxxxxx>
      Date:   Mon Jun 13 12:30:34 2016 -0400
    
        qemu: Add the ability to hotplug the TLS X.509 environment
    
    added a parameter "bool listen" in some methods. This
    unfortunately clashes with the listen() method, causing
    compile failures on certain platforms (RHEL-6 for example)
    
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

commit 2f6b750ecaff0e1d87e17d3a7c5a01218a527220
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Tue Sep 6 17:00:30 2016 -0400

    storage: Need to properly read the crypt offset value
    
    Commit id 'a48c7141' altered how to determine if a volume was encrypted
    by adding a peek at an offset into the file at a specific buffer location.
    Unfortunately, all that was compared was the first "char" of the buffer
    against the expect "int" value.
    
    Restore the virReadBufInt32BE to get the complete field in order to
    compare against the expected value from the qcow2EncryptionInfo or
    qcow1EncryptionInfo "modeValue" field.
    
    This restores the capability to create a volume with encryption, then
    refresh the pool, and still find the encryption for the volume.

commit b68487c917a2cd576bbd80d423b80860c46d6d0f
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Tue Sep 6 16:52:36 2016 -0400

    storage: Need to refresh secret for luks volume after volume refresh
    
    A LUKS volume uses the volume secret type just like the QCOW2 secret, so
    adjust the loading of the default secrets to handle any volume that the
    virStorageFileGetMetadataFromBuf code has deemed to be an encrypted volume
    to search for the volume's secret. This lookup is done by volume usage
    where the usage is expected to be the path to volume.

commit b6daacf6ceb6fbb829522969af9f45a88e5ac3d7
Author: Nikolay Shirokovskiy <nshirokovskiy@xxxxxxxxxxxxx>
Date:   Mon Sep 12 13:56:29 2016 +0300

    log: Fix reporting OOM error incorrectly when defining a logging filter
    
    When a new filter is being defined, the return code is not handled properly,
    thus triggering OOM error reporting routine (bug introduced by 51b2606f).
    
    Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx>

commit 56258a388fbb1d44ef6d6e59c7a0795f1fae53d0
Author: Jiri Denemark <jdenemar@xxxxxxxxxx>
Date:   Mon Sep 12 10:24:21 2016 +0200

    qemu: Don't use query-migrate on destination
    
    When migration fails, we need to poke QEMU monitor to check for a reason
    of the failure. We did this using query-migrate QMP command, which is
    not supposed to return any meaningful result on the destination side.
    Thus if the monitor was still functional when we detected the migration
    failure, parsing the answer from query-migrate always failed with the
    following error message:
    
        "info migration reply was missing return status"
    
    This irrelevant message was then used as the reason for the migration
    failure replacing any message we might have had.
    
    Let's use harmless query-status for poking the monitor to make sure we
    only get an error if the monitor connection is broken.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1374613
    
    Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx>

commit c8b8bbc3663dacab1bda4c1fa821180674fdc509
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Tue Sep 6 17:20:30 2016 -0400

    util: Quiet the logging if perf file doesn't exist
    
    Commit id 'b00d7f29' shifted the opening of the /sys/devices/intel_cqm/type
    file from event enable to perf event initialization. If the file did not
    exist, then an error would be written to the domain log:
    
    2016-09-06 20:51:21.677+0000: 7310: error : virFileReadAll:1360 : Failed to 
open file '/sys/devices/intel_cqm/type': No such file or directory
    
    Since the error is now handled in virPerfEventEnable by checking if the
    event_attr->attrType == 0 for CMT, MBML, and MBMT events - we can just
    use the Quiet API in order to not log the error we're going to throw away.
    
    Additionally, rather than using virReportSystemError, use virReportError
    and VIR_ERR_ARGUMENT_UNSUPPORTED in order to signify that support isn't 
there
    for that type of perf event - adjust the error message as well.

commit 69f4030aadf0e4f8af07493213026b7226531e7f
Author: Joao Martins <joao.m.martins@xxxxxxxxxx>
Date:   Wed Jul 20 20:08:49 2016 +0100

    libxl: implement virConnectBaselineCPU
    
    Akin to previous commit but for "virsh cpu-baseline" which
    computes a baseline CPU for a set of host cpu elements.
    
    Signed-off-by: Joao Martins <joao.m.martins@xxxxxxxxxx>
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 5822b740add70de02d0c41ac48d9672be91b0710
Author: Joao Martins <joao.m.martins@xxxxxxxxxx>
Date:   Wed Jul 20 20:08:48 2016 +0100

    libxl: implement virConnectCompareCPU
    
    Implement support for "virsh cpu-compare" so that we can calculate
    common cpu element between a pool of hosts, which had a requirement
    of providing host cpu description.
    
    Signed-off-by: Joao Martins <joao.m.martins@xxxxxxxxxx>
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 17322e551861a5bc4dd464a7c5399204dc8c7caa
Author: Joao Martins <joao.m.martins@xxxxxxxxxx>
Date:   Wed Jul 20 20:08:47 2016 +0100

    libxl: describe host cpu features based on hwcaps
    
    Parse libxl_hwcap accounting for versions since Xen 4.4 - Xen 4.7.
    libxl_hwcaps is a set of cpuid leaves output that is described in [0] or
    [1] in Xen 4.7. This is a collection of CPUID leaves that we version
    in libvirt whenever feature words are reordered or added. Thus we keep the
    common ones in one struct and others for each version. Since
    libxl_hwcaps doesn't appear to have a stable format across all supported
    versions thus we need to keep track of changes as a compromise until it's
    exported in xen libxl API. We don't fail in initializing the driver in case
    parsing of hwcaps failed for that reason. In addition, change the notation
    on PAE feature such that is easier to read which bit it corresponds.
    
    [0] xen/include/asm-x86/cpufeature.h
    [1] xen/include/public/arch-x86/cpufeatureset.h
    
    Signed-off-by: Joao Martins <joao.m.martins@xxxxxxxxxx>

commit 3d54305e1cc7baf028e581b412886874f70af66c
Author: Joao Martins <joao.m.martins@xxxxxxxxxx>
Date:   Wed Jul 20 20:08:46 2016 +0100

    libxl: describe host topology in capabilities
    
    Add support for describing cpu topology in host cpu element.  In doing
    so, refactor hwcaps part to its own helper namely libxlCapsInitCPU to
    handle all host cpu related operations, including topology.
    
    Signed-off-by: Joao Martins <joao.m.martins@xxxxxxxxxx>

commit 85c826129b4b2098f9713b3fb8be3e93e1c61d1b
Author: Peter Krempa <pkrempa@xxxxxxxxxx>
Date:   Mon Sep 5 18:12:00 2016 +0200

    qemu: hotplug: Don't wait if cdrom tray is opened forcibly
    
    Qemu always opens the tray if forced to. Skip the waiting step in such
    case.
    
    This also helps if qemu does not report the tray change event when
    opening the cdrom forcibly (the documentation says that the event will
    not be sent although qemu in fact does trigger it even if @force is
    selceted).
    
    This is a workaround for a qemu issue where qemu does not send the tray
    change event in some cases (after migration with empty closed locked
    drive) and thus renders the cdrom useless from libvirt's point of view.
    
    Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1368368

commit 6e19cc59a6a7dd1a31e1b8d8e645163ff8fb6827
Author: Peter Krempa <pkrempa@xxxxxxxxxx>
Date:   Mon Sep 5 15:50:18 2016 +0200

    qemu: domain: Clear startup policy for dropped removable media
    
    When a source image is dropped when missing due to startup policy the
    policy needs to be cleared since it was relevant only for the given
    storage source. New sources need to update it if needed.

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