|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 131484: regressions - FAIL
flight 131484 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/131484/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 15 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 dfbd7315c02a6e414d6eb6de5b052a424901e358 baseline version: libvirt 4d95d35637e3f59526288e0a8a77f7a200992652 Last test of basis 131433 2018-12-18 18:27:25 Z 3 days Failing since 131453 2018-12-20 01:38:19 Z 2 days 2 attempts Testing same since 131484 2018-12-21 07:12:43 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Luyao Huang <lhuang@xxxxxxxxxx> Marc Hartmayer <mhartmay@xxxxxxxxxxxxx> 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 pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass 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 dfbd7315c02a6e414d6eb6de5b052a424901e358 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Wed Dec 19 15:47:41 2018 +0100 news: Document original owner remembering Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Andrea Bolognani <abologna@xxxxxxxxxx> commit 91684829be8019f675b847d59d357241d6c0d159 Author: Marc Hartmayer <mhartmay@xxxxxxxxxxxxx> Date: Mon Oct 29 18:34:58 2018 +0100 qemu: Introduce caching whether /dev/kvm is accessible Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU group. This reduces the overhead of the QEMU capabilities cache lookup. Before this patch there were many fork() calls used for checking whether /dev/kvm is accessible. Now we store the result whether /dev/kvm is accessible or not and we only need to re-run the virFileAccessibleAs check if the ctime of /dev/kvm has changed. Suggested-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> Signed-off-by: Marc Hartmayer <mhartmay@xxxxxxxxxxxxx> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |