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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 104005

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check    fail  like 104005
 test-armhf-armhf-libvirt     13 saverestore-support-check    fail  like 104005
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104005
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check    fail  like 104005

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-xsm  12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 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-armhf-armhf-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-check        fail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check        fail   never pass

version targeted for testing:
 libvirt              1d0fde7ee137d2a80c937db1037cbc5fd2e2cde5
baseline version:
 libvirt              0735ddf744f95cd9f88c5f8465b1a64883710d37

Last test of basis   104005  2017-01-03 04:20:30 Z    2 days
Failing since        104021  2017-01-04 04:20:15 Z    1 days    2 attempts
Testing same since   104036  2017-01-05 04:20:32 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrea Bolognani <abologna@xxxxxxxxxx>
  John Ferlan <jferlan@xxxxxxxxxx>
  Martin Kletzander <mkletzan@xxxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>
  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                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 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 1d0fde7ee137d2a80c937db1037cbc5fd2e2cde5
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Fri Nov 18 08:55:35 2016 -0500

    util: Remove need for extra VIR_FREE's in virGetFCHostNameByWWN
    
    Rather than extraneous VIR_FREE's depending on where we are in the code,
    move them to the top of the loop and in the cleanup path.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 9fdc8c4269d710328c4d57292d6404ff13b6f632
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Tue Jan 3 17:00:36 2017 -0500

    scsi: Converge more createVport checks
    
    Remove duplicated code - make one simple path through
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 476ecf2a2a7f9d7498fbe61b0431006f4088125d
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Fri Nov 18 07:44:52 2016 -0500

    scsi: Change order of checks in createVport
    
    Move the check for an already existing vHBA to the top of the function.
    No sense in first decoding a provided parent if the next thing we're going
    to do is fail if a provided wwnn/wwpn already exists.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 79ab093518ffd07724eb0f8950a07b81d878e9b3
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Fri Nov 18 07:19:28 2016 -0500

    scsi: Clean up createVport exit paths
    
    Use the ret = -1, goto cleanup, etc. rather than current hodgepodge.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 8b629a3c01b8c5e148f8bbe3776f19150784cf80
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Wed Nov 16 17:50:09 2016 -0500

    nodedev: Add ability to find a vport capable vHBA
    
    If a <parent> is not supplied in the XML used to create a non-persistent
    vHBA, then instead of failing, let's try to find a "vports" capable node
    device and use that.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 8f3054a0f8339f52aed0c537361507820b8441bd
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Thu Nov 17 15:03:00 2016 -0500

    nodedev: Create helpers to search for vport capable nodedevs
    
    Extract out code from virNodeDeviceGetParentHost into helpers - it's
    going to be reused in upcoming patches to search on more fields
    
    Create virNodeDeviceFindVPORTCapDef in order to return a 
virNodeDevCapsDefPtr
    of the VPORT_OPS and virNodeDeviceFindFCParentHost to use the function and
    generate an error message if the device doesn't have the capability.
    
    Also clean up the processing in virNodeDeviceGetParentHost to remove
    need for goto's.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 79bf25cd9c7c75fdd9eb1c4fa678d2f1c8e8d24a
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Wed Jan 4 18:05:16 2017 +0100

    NEWS: Remove spurious period
    
    All other entries in the release notes omit the leading period,
    and so should this one in order to maintain consistency.

commit 2e86c0816fc8ab573745f1a9a650be09bd66e300
Author: Peter Krempa <pkrempa@xxxxxxxxxx>
Date:   Wed Jan 4 13:23:31 2017 +0100

    qemu: snapshot: Resume VM after live snapshot
    
    Commit 4b951d1e38259ff5d03e9eedb65095eead8099e1 missed the fact that the
    VM needs to be resumed after a live external checkpoint (memory
    snapshot) where the cpus would be paused by the migration rather than
    libvirt.

commit 6488a6c6e25950980d35fee9adcf63cec6921990
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Wed Jan 4 14:46:21 2017 +0100

    HACKING: Reduce vertical whitespace
    
    When generating the plain text version of the contributor
    guidelines we add a ludicrous amount of vertical whitespace
    in some spots. Tweak the XSLT stylesheet and regenerate the
    now much better looking file.

commit dd78da09b03a4fb3db69e7405fa177dc39a4936d
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Jan 4 14:24:16 2017 +0100

    qemuDomainCreateDevice: Be more careful about device path
    
    Again, not something that I'd hit, but there is a chance in
    theory that this might bite us. Currently the way we decide
    whether or not to create /dev entry for a device is by marching
    first four characters of path with "/dev". This might be not
    enough. Just imagine somebody has a disk image stored under
    "/devil/path/to/disk". We ought to be matching against "/dev/".
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit ce01a2b11ce88da772923ebcbbfe66f228a7bfee
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Jan 4 14:06:09 2017 +0100

    qemuDomainAttachDeviceMknodHelper: Don't unlink() so often
    
    Not that I'd encounter any bug here, but the code doesn't look
    100% correct. Imagine, somebody is trying to attach a device to a
    domain, and the device's /dev entry already exists in the qemu
    namespace. This is handled gracefully and the control continues
    with setting up ACLs and calling security manager to set up
    labels. Now, if any of these steps fail, control jump on the
    'cleanup' label and unlink() the file straight away. Even when it
    was not us who created the file in the first place. This can be
    possibly dangerous.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 3aae99fe71ccee523bafeb54ebd0338eeed66868
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Jan 4 13:57:06 2017 +0100

    qemu: Handle EEXIST gracefully in qemuDomainCreateDevice
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1406837
    
    Imagine you have a domain configured in such way that you are
    assigning two PCI devices that fall into the same IOMMU group.
    With mount namespace enabled what happens is that for the first
    PCI device corresponding /dev/vfio/X entry is created and when
    the code tries to do the same for the second mknod() fails as
    /dev/vfio/X already exists:
    
    2016-12-21 14:40:45.648+0000: 24681: error :
    qemuProcessReportLogError:1792 : internal error: Process exited
    prior to exec: libvirt: QEMU Driver error : Failed to make device
    /var/run/libvirt/qemu/windoze.dev//vfio/22: File exists
    
    Worse, by default there are some devices that are created in the
    namespace regardless of domain configuration (e.g. /dev/null,
    /dev/urandom, etc.). If one of them is set as backend for some
    guest device (e.g. rng, chardev, etc.) it's the same story as
    described above.
    
    Weirdly, in attach code this is already handled.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 8388b1c8268d1d8141f85c7b42649f87056d7fa7
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Wed Dec 28 21:21:03 2016 +0100

    networkxml2conftest: Rename outxml to outconf
    
    Just a name, I know, but it bothered me a lot since it does not refer
    to XML.
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit 6e0a1663bd0c4252c0e7ab1660461e17b2f702ce
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Wed Dec 14 11:24:40 2016 +0100

    docs: Use href_base in absolute links
    
    That way all links work even if you click them in a subdirectory.
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit d39e3b71ea6436cb5995ff285cc27f0bd1632a6f
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Wed Jan 4 13:53:59 2017 +0100

    HACKING: Regenerate
    
    When updating the source file in commit bd4f4d168660, I forgot
    that we also store the generated plain text version in git and
    didn't regenerate it.
    
    I also missed one spot that required an additional <p> tag, so
    fix both mistakes in one go.

commit f0af48f0ddf6bcc9be4f011592b9d3387ccd3af0
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Wed Jan 4 12:47:01 2017 +0100

    util: Fix syntax-check
    
    Commit b9cc24839b75 introduced a new #define but neglected
    to format it properly, thus breaking syntax-check.

commit bd4f4d168660f563435968207fc36dad7c8c9e46
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Wed Jan 4 12:14:13 2017 +0100

    docs: Add missing <p> elements
    
    Some of the <li> elements in the "General tips for contributing
    patches" section were missing the corresponding inner <p> element,
    so they ended up all lumped together.

commit b9cc24839b755c47e1a85b267321d1119d2735f2
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date:   Mon Jan 2 19:15:30 2017 +0100

    util: Turn virFirewallAddRule() into a macro
    
    Clang 3.9 refuses to compile the existing code with the
    following error:
    
      util/virfirewall.c:425:20: error: passing an object that undergoes
                                 default argument promotion to 'va_start'
                                 has undefined behavior [-Werror,-Wvarargs]
          va_start(args, layer);
                         ^
      util/virfirewall.c:420:37: note: parameter of type 'virFirewallLayer'
                                 is declared here
                         virFirewallLayer layer,
                                          ^
    
    This happens because 'layer' is of type virFirewallLayer, which
    is an enum type and not a standard type such as eg. void* or int.
    
    To solve the issue, turn virFirewallAddRule() from a very thin
    wrapper around virFirewallAddRuleFullV() to a macro that expands
    to a call to virFirewallAddRuleFull() - itself a very thin wrapper
    around the aforementioned virFirewallAddRuleFullV() - with no loss
    of functionality or type safety.

commit 7f7d99048350935a394d07b98a13d7da9c4b0502
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Thu Dec 22 07:12:49 2016 -0500

    qemu: Don't assume secret provided for LUKS encryption
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1405269
    
    If a secret was not provided for what was determined to be a LUKS
    encrypted disk (during virStorageFileGetMetadata processing when
    called from qemuDomainDetermineDiskChain as a result of hotplug
    attach qemuDomainAttachDeviceDiskLive), then do not attempt to
    look it up (avoiding a libvirtd crash) and do not alter the format
    to "luks" when adding the disk; otherwise, the device_add would
    fail with a message such as:
    
       "unable to execute QEMU command 'device_add': Property 'scsi-hd.drive'
        can't find value 'drive-scsi0-0-0-0'"
    
    because of assumptions that when the format=luks that libvirt would have
    provided the secret to decrypt the volume.
    
    Access to unlock the volume will thus be left to the application.

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