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

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



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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt     14 saverestore-support-check    fail  like 131433
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check    fail  like 131433
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check        fail   never pass

version targeted for testing:
 libvirt              e05d8e570b24bc48c083b2c36428f7fca8ff864b
baseline version:
 libvirt              4d95d35637e3f59526288e0a8a77f7a200992652

Last test of basis   131433  2018-12-18 18:27:25 Z    2 days
Testing same since   131453  2018-12-20 01:38:19 Z    1 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Luyao Huang <lhuang@xxxxxxxxxx>
  Michal Privoznik <mprivozn@xxxxxxxxxx>

jobs:
 build-amd64-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-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-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 e05d8e570b24bc48c083b2c36428f7fca8ff864b
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Nov 20 14:23:35 2018 +0100

    qemu.conf: Allow users to enable/disable label remembering
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit 1845991d9b0b33e0a0cbb964ac185759a4c65b86
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Sep 25 14:15:24 2018 +0200

    tools: Provide a script to recover fubar'ed XATTRs setup
    
    Our code is not bug free. The refcounting I introduced will
    almost certainly not work in some use cases. Provide a script
    that will remove all the XATTRs set by libvirt so that it can
    start cleanly.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit 1e63dea999f1916a2d5fc55d3a4c7eac6d95fd49
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Fri Dec 7 13:21:43 2018 +0100

    tests: Introduce qemusecuritytest
    
    This test checks if security label remembering works correctly.
    It uses qemuSecurity* APIs to do that. And some mocking (even
    though it's not real mocking as we are used to from other tests
    like virpcitest). So far, only DAC driver is tested.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit d9043c06e62e2941454b7a5470bbd19b14a9f8ef
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Oct 3 11:08:21 2018 +0200

    virSecuritySELinuxRestoreAllLabel: Restore more labels
    
    We are setting label on kernel, initrd, dtb and slic_table files.
    But we never restored it.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit d81f3e02d7a2e3bf708ddd9fa34d368c2ec75b14
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Oct 3 11:03:04 2018 +0200

    virSecuritySELinuxRestoreAllLabel: Reorder device relabeling
    
    It helps whe trying to match calls with virSecuritySELinuxSetAllLabel
    if the order in which devices are set/restored is the same in
    both functions.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit edacf25da7c4eb4e769e8df0b22eb191b6649270
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Sep 25 15:46:56 2018 +0200

    virSecuritySELinuxTransactionRun: Implement rollback
    
    When iterating over list of paths/disk sources to relabel it may
    happen that the process fails at some point. In that case, for
    the sake of keeping seclabel refcount (stored in XATTRs) in sync
    with reality we have to perform rollback. However, if that fails
    too the only thing we can do is warn user.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit b44fd4201692c4c31383851f9d1887fa575c7482
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Sep 25 17:07:23 2018 +0200

    security_selinux: Restore label on failed setfilecon() attempt
    
    It's important to keep XATTRs untouched (well, in the same state
    they were in when entering the function). Otherwise our
    refcounting would be messed up.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit 4dc37a39cff95702c191cbfb4e52a3b5d3297e9a
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Wed Sep 19 10:06:44 2018 +0200

    security_selinux: Remember old labels
    
    Similarly to what I did in DAC driver, this also requires the
    same SELinux label to be used for shared paths. If a path is
    already in use by a domain (or domains) then and the domain we
    are starting now wants to access the path it has to have the same
    SELinux label. This might look too restrictive as the new label
    can still guarantee access to already running domains but in
    reality it is very unlikely and usually an admin mistake.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit 1e9c4724524d9758933b889b5adf62c14087cc99
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Sep 25 16:32:47 2018 +0200

    security_selinux: Track if transaction is restore
    
    It is going to be important to know if the current transaction we
    are running is a restore operation or set label operation so that
    we know whether to call virSecurityGetRememberedLabel() or
    virSecuritySetRememberedLabel(). That is, whether we are in a
    restore and therefore have to fetch the remembered label, or we
    are in set operation and therefore have to store the original
    label.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit d7420430ce6d887ad8b669eeb5d6c2222de5b80f
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Sep 25 13:33:28 2018 +0200

    virSecurityDACRestoreImageLabelInt: Restore even shared/RO disks
    
    Now that we have seclabel remembering we can safely restore
    labels for shared and RO disks. In fact we need to do that to
    keep seclabel refcount stored in XATTRs in sync with reality.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit 1845d3ad5d0053044323a37941a5ac61759ff656
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Mon Aug 6 12:14:52 2018 +0200

    security_dac: Remember old labels
    
    This also requires the same DAC label to be used for shared
    paths. If a path is already in use by a domain (or domains) then
    and the domain we are starting now wants to access the path it
    has to have the same DAC label. This might look too restrictive
    as the new label can still guarantee access to already running
    domains but in reality it is very unlikely and usually an admin
    mistake.
    
    This requirement also simplifies seclabel remembering, because we
    can store only one seclabel and have a refcounter for how many
    times the path is in use. If we were to allow different labels
    and store them in some sort of array the algorithm to match
    labels to domains would be needlessly complicated.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit fa808763b29f4038960fd0a6b745ba2516f4cb3c
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Nov 20 13:05:08 2018 +0100

    security_dac: Allow callers to enable/disable label remembering/recall
    
    Because the implementation that will be used for label
    remembering/recall is not atomic we have to give callers a chance
    to enable or disable it. That is, enable it if and only if
    metadata locking is enabled. Otherwise the feature MUST be turned
    off.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit a30e6d17c9abf4f1becfa531e41fd48f9e06649a
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Sep 25 13:34:43 2018 +0200

    virSecurityDACRestoreAllLabel: Restore more labels
    
    We are setting label on kernel, initrd, dtb and slic_table files.
    But we never restored it.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit 08e3b1c0dc1261e1e0380f8c5d42b2adfdf8bc43
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Sep 25 13:32:07 2018 +0200

    virSecurityDACRestoreAllLabel: Reorder device relabeling
    
    It helps whe trying to match calls with virSecurityDACSetAllLabel
    if the order in which devices are set/restored is the same in
    both functions.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit 06af6609e9dab515b82a65825217dfa872ec309d
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Tue Sep 25 10:36:13 2018 +0200

    virSecurityDACTransactionRun: Implement rollback
    
    When iterating over list of paths/disk sources to relabel it may
    happen that the process fails at some point. In that case, for
    the sake of keeping seclabel refcount (stored in XATTRs) in sync
    with reality we have to perform rollback. However, if that fails
    too the only thing we can do is warn user.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit 86def3c88ce357a23ed989da89ee9f10fa4bd9c8
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Mon Sep 24 17:10:06 2018 +0200

    security_dac: Restore label on failed chown() attempt
    
    It's important to keep XATTRs untouched (well, in the same state
    they were in when entering the function). Otherwise our
    refcounting would be messed up.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit f9a0019fea52dd847a90aaa95baad2e79939286c
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Mon Aug 6 12:14:41 2018 +0200

    security: Include security_util
    
    This file implements wrappers over XATTR getter/setter. It
    ensures the proper XATTR namespace is used.
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit f497b1ad59b35f74f01e9a2347604caf71e91e5a
Author: Michal Privoznik <mprivozn@xxxxxxxxxx>
Date:   Mon Aug 6 10:50:03 2018 +0200

    util: Introduce xattr getter/setter/remover
    
    Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
    Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx>

commit ae8484586c5ad79c57515ee004ec251765cc612e
Author: Luyao Huang <lhuang@xxxxxxxxxx>
Date:   Wed Dec 19 11:17:01 2018 +0800

    virsh: Fix vcpupin command output wrong vcpu pinning info
    
    Commit 3072ded3 changed the waya to format the vcpu pinning info
    and forget to get cpumap for each vcpu during the loop, that cause
    vcpupin command will display vcpu 0 info for other vcpus.
    
    Signed-off-by: Luyao Huang <lhuang@xxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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