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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 88483
 build-armhf-pvops             4 host-build-prep           fail REGR. vs. 88483

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-xsm  1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 libvirt              2cc91ddd2d3043593172927e49762d3bab28f399
baseline version:
 libvirt              dfbc9a8382adc0495bf0e034ae6add92bed4822b

Last test of basis    88483  2016-04-03 04:27:22 Z    2 days
Testing same since    88753  2016-04-05 04:32:11 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  John Ferlan <jferlan@xxxxxxxxxx>
  Laine Stump <laine@xxxxxxxxx>
  Martin Kletzander <mkletzan@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                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            broken  
 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

broken-step test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm host-install(3)

Not pushing.

------------------------------------------------------------
commit 2cc91ddd2d3043593172927e49762d3bab28f399
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Mon Apr 4 15:27:58 2016 -0400

    qemu: Fix mis-merge of qemuBuildRedirdevCommandLine
    
    Commit id '59e7ef3c' misapplied a merge of commit id '019244751'
    to place the "-chardev" command after formatting the character
    backend value.

commit 28e960b691ad239fd41b0138f3d41e295bab51d5
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Mon Apr 4 15:26:43 2016 -0400

    qemu: Fix mis-merge of qemuBuildConsoleCommandLine
    
    Commit id 'e6944a52' misapplied a merge of commit id '019244751'
    to place the "-chardev" command after formatting the character
    backend value.

commit 48d5b3d81d06ed9b3441ddd5ad5d3f97b67a7126
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Mon Apr 4 15:24:28 2016 -0400

    qemu: Fix mis-merge of qemuBuildChannelsCommandLine
    
    Commit id '3cdcc910' misapplied a merge of commit id '019244751'
    to place the "-chardev" command after formatting the character
    backend value.

commit 6a97e35f827031daecd3258d72fa1d26a9c945e5
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Mon Apr 4 15:23:07 2016 -0400

    qemu: Fix mis-merge of qemuBuildParallelsCommandLine
    
    Commit id '0e1e7ade' misapplied a merge of commit id '019244751'
    to place the "-chardev" command after formatting the character
    backend value.

commit 3281b47e47706d3d31256d92c113fe10ec8e9de9
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Mon Apr 4 15:21:57 2016 -0400

    qemu: Fix mis-merge of qemuBuildSerialCommandLine
    
    Commit id '5ab8640' misapplied a merge of commit id '019244751'
    to place the "-chardev" command after formatting the character
    backend value.

commit 344bcd89ebbe0c703716820f781ed9c089851fef
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Mon Apr 4 15:19:57 2016 -0400

    qemu: Fix mis-merge of qemuBuildSmartcardCommandLine
    
    Commit id '858bafeb' misapplied a merge of commit id '019244751'
    to place the "-chardev" command after formatting the character
    backend value.

commit 17a94ba70fc11c21f8ea70ff92131d0868f4cde1
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Sun Apr 3 19:55:54 2016 +0200

    nodedev: Fix parsing of generated XMLs
    
    Commit d77ffb6876 added not only reporting of the PCI header type, but
    also parsing of that information.  However, because there was no parsing
    done for the other sub-PCI capabilities, if there was any other
    capability then a valid header type name (like phys_function or
    virt_functions) the parsing would fail.  This prevented passing node
    device XMLs that we generated into our own functions when dealing with,
    e.g. with SRIOV cards.
    
    Instead of reworking the whole parsing, just fix this one occurence and
    remove a test for it for the time being.  Future patches will deal with
    the rest.
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit 8f74f5277d33ab791ee5b94f77efbbbebe37c6b1
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Fri Apr 1 13:18:57 2016 -0400

    qemu: fix alias name for <interface type='hostdev'>
    
    Starting with commit f8e712fe, if you start a domain that has an
    <interface type='hostdev' (or that has <interface type='network'>
    where the network is a pool of devices for hostdev assignment), when
    you later try to add *another* interface (of any kind) with hotplug,
    the function qemuAssignDeviceNetAlias() fails as soon as it sees a
    "hostdevN" alias in the list of interfaces), causing the attach to
    fail.
    
    This is because (starting with f8e712fe) the device alias names are
    assigned during the new function qemuProcessPrepareDomain(), which is
    called *before* networkAllocateActualDevice() (which is called from
    qemuProcessPrepareHost(), which is called from
    qemuProcessLaunch()). Prior to that commit,
    networkAllocateActualDevice() was called first.
    
    The problem with this is that the alias for interfaces that are really
    a hostdev (<interface type='hostdev'>) is of the form "hostdevN" (just
    like other hostdevs), while other interfaces are "netN". But if you
    don't know that the interface is going to be a hostdev at the time you
    assign the alias name, you can't name it differently. (As far as I've
    seen so far, the change in name by itself wouldn't have been a problem
    (other than just an outwardly noticeable change in behavior) except
    for the abovementioned failure to attach/detach new interfaces.
    
    Rather than take the chance that there may be other not-yet-revealed
    problems associated with changing the alias name, this patch changes
    the way that aliases are assigned to restore the old behavior.
    
    Old: In the past, assigning an alias to an interface was skipped if it
    was seen that the interface was type='hostdev' - we knew that the
    hostdev part of the interface was also in the list of hostdevs (that's
    part of what happens in networkAllocateActualDevice()) and it would be
    assigned when all the other hostdev aliases were assigned.
    
    New: When assigning an alias to an interface, we haven't yet called
    networkAllocateActualDevice() to construct the hostdev part of the
    interface, so we can't just wait for the loop that creates aliases for
    all the hostdevs (there's nothing on that list for this device
    yet!). Instead we handle it immediately in the loop creating interface
    aliases, by calling the new function networkGetActualType() to
    determine if it is going to be hostdev, and if so calling
    qemuAssignDeviceHostdevAlias() instead.
    
    Some adjustments have to be made to both
    qemuAssignDeviceHostdevAlias() and to qemuAssignDeviceNetAlias() to
    accommodate this. In both of them, an error return from
    qemuDomainDeviceAliasIndex() is no longer considered an error; instead
    it's just ignored (because it almost certainly means that the alias
    string for the device was "net" when we expected "hostdev" or vice
    versa). in qemuAssignDeviceHostdevAlias() we have to look at all
    interface aliases for hostdevN in addition to looking at all hostdev
    aliases (this wasn't necessary in the past, because both the interface
    entry and the hostdev entry for the device already pointed at the
    device info; no longer the case since the hostdev entry hasn't yet
    been setup).
    
    Fortunately the buggy behavior hasn't yet been in any official release
    of libvirt.

commit f09c7139b0f66fe687ba9fcc823a4837979b05c1
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Fri Apr 1 10:40:23 2016 -0400

    qemu: change args to qemuAssignDeviceHostdevAlias()
    
    In certain cases, we need to assign a hostdevN-style alias in a case
    when we don't have a virDomainHostdevDefPtr (instead we have a
    virDomainNetDefPtr). Since qemuAssignDeviceHostdevAlias() doesn't use
    anything in the virDomainHostdevDef except the alias string itself
    anyway, this patch just changes the arguments to pass a pointer to the
    alias pointer instead.

commit 3992ff14e5a5ce041cb6ba68f317101cee9e47d6
Author: Laine Stump <laine@xxxxxxxxx>
Date:   Fri Apr 1 09:45:51 2016 -0400

    network: new function networkGetActualType
    
    There are times when it's necessary to learn the actual type of a
    network connection before any resources have been allocated
    (e.g. during qemuProcessPrepareDomain()), but in the past it was
    necessary to call networkAllocateActualDevice() in order to have the
    actual type filled in.
    
    This new function returns the type of network that *will be* setup
    once it actually happens, but without making any changes on the host.

commit d558fb34fd0e410fdaeb993ea43ba733bfb5c528
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Sun Apr 3 21:51:29 2016 +0200

    qemu: Clear generated private paths
    
    The paths have the domain ID in them.  Without cleaning them, they would
    contain the same ID even after multiple restarts.  That could cause
    various problems, e.g. with access.
    
    Add function qemuDomainClearPrivatePaths() for this as a counterpart of
    qemuDomainSetPrivatePaths().
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

commit 1893b6df117baf785cc568c9b044a849de0ca046
Author: Martin Kletzander <mkletzan@xxxxxxxxxx>
Date:   Sun Apr 3 21:59:46 2016 +0200

    qemu: Simplify calls to qemuDomainSetPrivatePaths
    
    Since commit 9dca74ee6f54, the function can take driver and a vm, no
    need to overcomplicate.
    
    Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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