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

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

flight 26343 libvirt real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt           4 libvirt-build             fail REGR. vs. 26314
 build-armhf-libvirt           4 libvirt-build             fail REGR. vs. 26314
 build-i386-libvirt            4 libvirt-build             fail REGR. vs. 26314

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt      1 xen-build-check(1)           blocked  n/a
 test-armhf-armhf-libvirt      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-libvirt       1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 libvirt              a0f82fd2bdac5d7177a03193e9de110e103228e2
baseline version:
 libvirt              5099084eb30c9c5454e79e8eab8bcff038c0f8cd

People who touched revisions under test:
  Chen Hanxiao <chenhanxiao@xxxxxxxxxxxxxx>
  Eric Blake <eblake@xxxxxxxxxx>
  Jim Fehlig <jfehlig@xxxxxxxx>
  Jiri Denemark <jdenemar@xxxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>

 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      blocked 

sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at

Test harness code can be found at

Not pushing.

commit a0f82fd2bdac5d7177a03193e9de110e103228e2
Author: Jim Fehlig <jfehlig@xxxxxxxx>
Date:   Thu May 15 16:24:43 2014 -0600

    security_dac: honor relabel='no' in chardev config
    The DAC driver ignores the relabel='no' attribute in chardev config
      <serial type='file'>
        <source path='/tmp/jim/test.file'>
          <seclabel model='dac' relabel='no'/>
        <target port='0'/>
    This patch avoids labeling chardevs when relabel='no' is specified.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>

commit bb917a90b1c86c5b36deb0ff90d2c0823a090687
Author: Jim Fehlig <jfehlig@xxxxxxxx>
Date:   Thu May 15 15:58:04 2014 -0600

    security_dac: avoid relabeling hostdevs when relabel='no'
    When relabel='no' at the domain level, there is no need to call
    the hostdev relabeling functions.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>

commit 3c2487ab0aaf400ca85866f31a7f5b413afd2ce7
Author: Jim Fehlig <jfehlig@xxxxxxxx>
Date:   Thu May 15 15:30:26 2014 -0600

    security_dac: honor relabel='no' in disk config
    The DAC driver ignores the relabel='no' attribute in disk config
      <disk type='file' device='floppy'>
        <driver name='qemu' type='raw'/>
        <source file='/some/path/floppy.img'>
          <seclabel model='dac' relabel='no'/>
        <target dev='fda' bus='fdc'/>
    This patch avoid labeling disks when relabel='no' is specified.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>

commit 9369a562446b7bb5314e6e1f6e65379bc1da6721
Author: Jim Fehlig <jfehlig@xxxxxxxx>
Date:   Thu May 15 16:38:01 2014 -0600

    security_dac: avoid relabeling when relabel='no'
    If relabel='no' at the domain level, no need to attempt relabeling
    in virSecurityDAC{Set,Restore}SecurityAllLabel().
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>

commit 3de7e4ec5e98145137445b631f44a43a19267d0c
Author: Jim Fehlig <jfehlig@xxxxxxxx>
Date:   Thu May 15 12:15:01 2014 -0600

    security_dac: rework callback parameter passing
    Currently, the DAC security driver passes callback data as
        void params[2];
        params[0] = mgr;
        params[1] = def;
    Clean this up by defining a structure for passing the callback
    data.  Moreover, there's no need to pass the whole virDomainDef
    in the callback as the only thing needed in the callbacks is
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>

commit 1d98e713d52319a31166ba07f8710abf30073c65
Author: Jim Fehlig <jfehlig@xxxxxxxx>
Date:   Thu May 15 11:35:15 2014 -0600

    security_dac: cleanup use of enum types
    In switch statements, use enum types since it is safer when
    adding new items to the enum.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>

commit e1ce6d836e10e5ca1642735151237d1e35b3fed8
Author: Jim Fehlig <jfehlig@xxxxxxxx>
Date:   Tue May 13 15:38:00 2014 -0600

    security_dac: annotate some functions with ATTRIBUTE_NONNULL
    Annotate some static function parameters with ATTRIBUTE_NONNULL
    and remove checks for NULL inputs.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx>

commit 3931ba2d442afbb95437f927263839f1abbaba7d
Author: Eric Blake <eblake@xxxxxxxxxx>
Date:   Fri May 16 11:12:20 2014 -0600

    maint: fix typos related to disk name resolution
    In a number of APIs, the text implied that a user might have
    <target dev='xvda'/> - but common convention is to use "vda",
    not "xvda".  For example, virDomainGetDiskErrors was correct,
    while virDomainBlockStats was confusing.
    * src/libvirt.c: Make examples consistent.
    Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

commit d18aa7041699343d4df01cd9352e24f215b08c21
Author: Chen Hanxiao <chenhanxiao@xxxxxxxxxxxxxx>
Date:   Tue May 13 16:01:16 2014 +0800

    util: fix memory leak in failure path of virCgroupKillRecursiveInternal
    Don't leak keypath when we fail to kill a process
    Signed-off-by: Chen Hanxiao <chenhanxiao@xxxxxxxxxxxxxx>

commit b279e52f7bd07dfe6e7f5ef0b34f2b424c50eee2
Author: Eric Blake <eblake@xxxxxxxxxx>
Date:   Wed May 14 16:40:33 2014 -0600

    maint: prefer enum over int for virstoragefile structs
    For internal structs, we might as well be type-safe and let the
    compiler help us with less typing required on our part (getting
    rid of casts is always nice).  In trying to use enums directly,
    I noticed two problems in virstoragefile.h that can't be fixed
    without more invasive refactoring: virStorageSource.format is
    used as more of a union of multiple enums in storage volume
    code (so it has to remain an int), and virStorageSourcePoolDef
    refers to pooltype whose enum is declared in src/conf, but where
    src/util can't pull in headers from src/conf.
    * src/util/virstoragefile.h (virStorageNetHostDef)
    (virStorageSourcePoolDef, virStorageSource): Use enums instead of
    int for fields of internal types.
    * src/qemu/qemu_command.c (qemuParseCommandLine): Cover all values.
    * src/conf/domain_conf.c (virDomainDiskSourceParse)
    (virDomainDiskSourceFormat): Simplify clients.
    * src/qemu/qemu_driver.c
    (qemuDomainSnapshotPrepareDiskInternal): Likewise.
    Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

commit ab5178188f250385132338e004d5c1f160fc5f34
Author: Eric Blake <eblake@xxxxxxxxxx>
Date:   Wed May 14 13:48:15 2014 -0600

    maint: shorten 'TypeType' function names
    The VIR_ENUM_DECL/VIR_ENUM_IMPL helper macros already append 'Type'
    to the enum name being converted; it looks silly to have functions
    with 'TypeType' in their name.  Even though some of our enums have
    to have a 'Type' suffix, the corresponding string conversion
    functions do not.
    * src/conf/secret_conf.h (VIR_ENUM_DECL): Rename virSecretUsageType.
    * src/conf/storage_conf.h (VIR_ENUM_DECL): Rename
    virStoragePoolAuthType, virStoragePoolSourceAdapterType,
    * src/conf/domain_conf.c (virDomainDiskDefParseXML)
    (virDomainFSDefParseXML, virDomainFSDefFormat): Update callers.
    * src/conf/secret_conf.c (virSecretDefParseUsage)
    (virSecretDefFormatUsage): Likewise.
    * src/conf/storage_conf.c (virStoragePoolDefParseAuth)
    (virStoragePoolDefParseSource, virStoragePoolSourceFormat):
    * src/lxc/lxc_controller.c (virLXCControllerSetupLoopDevices):
    * src/storage/storage_backend_disk.c
    (virStorageBackendDiskPartFormat): Likewise.
    * src/util/virstorageencryption.c (virStorageEncryptionSecretParse)
    (virStorageEncryptionSecretFormat): Likewise.
    * tools/virsh-secret.c (cmdSecretList): Likewise.
    * src/libvirt_private.syms (secret_conf.h, storage_conf.h): Export
    corrected names.
    Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

commit ea18f8b2b0337acfa418080d73035fac2185850b
Author: Eric Blake <eblake@xxxxxxxxxx>
Date:   Wed May 14 13:36:56 2014 -0600

    maint: use enum typedef for virstorageencryption.h
    Continuing the work of consistent enum cleanups; this time in
    * src/util/virstorageencryption.h (virStorageEncryptionFormat):
    Convert to typedef, renaming to avoid collision with function.
    (virStorageEncryptionSecret, virStorageEncryption): Directly use
    Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

commit 3e44cf7fc60cdb45b899085b9c9c1eb1adafd097
Author: Eric Blake <eblake@xxxxxxxxxx>
Date:   Wed May 14 13:26:28 2014 -0600

    vbox: fix stale comment about vdi storage type
    The code had some todo's about adding 'vdi' to the list of
    virStorageType, but we've already done that.
    * src/vbox/vbox_tmpl.c (vboxStorageVolCreateXML)
    (vboxStorageVolGetXMLDesc): Use enum value for vdi type.
    Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

commit 6f9c75a6f7cbd18eea6c6d4df9ba74f9ddddcff6
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Apr 2 19:05:42 2014 +0200

    qemu: Implement virDomain{Get,Set}Time
    One caveat though, qemu-ga is expecting time and returning time
    in nanoseconds. With all the buffering and propagation delay, the
    time is already wrong once it gets to the qemu-ga, but there's
    nothing we can do about it.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 222fdbfd2b852bd47d976a6305cc5cf4849824e0
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Apr 2 18:50:12 2014 +0200

    virsh: Expose virDomain{Get,Set}Time
    These APIs are exposed under new virsh command 'domtime' which both gets
    and sets (not at the same time of course :)).
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit 0abb36938027f3991f3ce5151b31cca9737a1287
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Apr 2 18:25:07 2014 +0200

    Introduce virDomain{Get,Set}Time APIs
    These APIs allow users to get or set time in a domain, which may come
    handy if the domain has been resumed just recently and NTP is not
    configured or hasn't kicked in yet and the guest is running
    something time critical. In addition, NTP may refuse to re-set the clock
    if the skew is too big.
    In addition, new ACL attribute is introduced 'set_time'.
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>

commit a4693c76f5beb280869dac9d103ceb632c6c1403
Author: Jiri Denemark <jdenemar@xxxxxxxxxx>
Date:   Thu May 15 13:11:12 2014 +0200

    qemu: Avoid leak in qemuDomainCheckRemoveOptionalDisk
    Coverity complains about event being leaked in
    qemuDomainCheckRemoveOptionalDisk. The best fix for it is to remove the
    disk directly since we already know its index.
    Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx>

Xen-devel mailing list



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