|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 106736: trouble: blocked/broken/fail/pass
flight 106736 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/106736/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 3 host-install(3) broken REGR. vs. 106707 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 106707 test-armhf-armhf-libvirt 13 saverestore-support-check fail like 106707 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 106707 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass build-arm64-xsm 5 xen-build fail never pass build-arm64 5 xen-build 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 build-arm64-pvops 5 kernel-build 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-raw 11 migrate-support-check fail never pass version targeted for testing: libvirt 445708bc77d60afac1318f021dbb4d2a67618547 baseline version: libvirt c5781e37a092e6222ff286c2835a92abe668bed3 Last test of basis 106707 2017-03-16 04:20:27 Z 1 days Testing same since 106736 2017-03-17 04:20:11 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Daniel P. Berrange <berrange@xxxxxxxxxx> Guido Günther <agx@xxxxxxxxxxx> Michal Privoznik <mprivozn@xxxxxxxxxx> jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops fail 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-arm64-arm64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm broken test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 blocked 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 broken-step test-amd64-i386-libvirt-xsm host-install(3) Not pushing. ------------------------------------------------------------ commit 445708bc77d60afac1318f021dbb4d2a67618547 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Thu Mar 16 11:16:50 2017 +0100 docs: Document NVDIMM Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 83c1ab5838c74a200da6ece156da06cbeea0a9b2 Author: Daniel P. Berrange <berrange@xxxxxxxxxx> Date: Wed Mar 15 18:04:36 2017 +0000 Report what TLS priority string we use for a session Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> commit 7310739d1f1c766c0607ef4279b0e676a253ad84 Author: Daniel P. Berrange <berrange@xxxxxxxxxx> Date: Wed Mar 15 18:03:37 2017 +0000 Short circuit SASL auth when no mechanisms are available If the SASL config does not have any mechanisms we currently just report an empty list to the client which will then fail to identify a usable mechanism. This is a server config error, so we should fail immediately on the server side. Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> commit 887450cbdfc25e99d07c06245108064de2c41b1b Author: Daniel P. Berrange <berrange@xxxxxxxxxx> Date: Wed Mar 15 18:02:40 2017 +0000 Sanity check explicit TLS file paths When providing explicit x509 cert/key paths in libvirtd.conf, the user must provide all three. If one or more is missed, this leads to obscure errors at runtime when negotiating the TLS session Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> commit 27cd76350021d36b9bd8b187ce5c8919659e3806 Author: Daniel P. Berrange <berrange@xxxxxxxxxx> Date: Wed Mar 15 16:51:51 2017 +0000 Increase default file handle limits for daemons Linux still defaults to a 1024 open file handle limit. This causes scalability problems for libvirtd / virtlockd / virtlogd on large hosts which might want > 1024 guest to be running. In fact if each guest needs > 1 FD, we can't even get to 500 guests. This is not good enough when we see machines with 100's of physical cores and TBs of RAM. In comparison to other memory requirements of libvirtd & related daemons, the resource usage associated with open file handles is essentially line noise. It is thus reasonable to increase the limits unconditionally for all installs. Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> commit b2aca2db7e4793705815b4169a2e527ea2534dc3 Author: Guido Günther <agx@xxxxxxxxxxx> Date: Thu Mar 16 08:39:32 2017 +0100 libxl: fix typo in debug message commit f014247fde802a0c8fc20f667f4f9a3d19863fd2 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Wed Mar 15 13:03:15 2017 +0100 docs: Document adaptive timeout for qemu monitor Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 85af0b803cd19a03f71bd01ab4e045552410368f Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Sat Mar 11 07:23:42 2017 +0100 qemu: Adaptive timeout for connecting to monitor There were couple of reports on the list (e.g. [1]) that guests with huge amounts of RAM are unable to start because libvirt kills qemu in the initialization phase. The problem is that if guest is configured to use hugepages kernel has to zero them all out before handing over to qemu process. For instance, 402GiB worth of 1GiB pages took around 105 seconds (~3.8GiB/s). Since we do not want to make the timeout for connecting to monitor configurable, we have to teach libvirt to count with this fact. This commit implements "1s per each 1GiB of RAM" approach as suggested here [2]. 1: https://www.redhat.com/archives/libvir-list/2017-March/msg00373.html 2: https://www.redhat.com/archives/libvir-list/2017-March/msg00405.html Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 67dcb797ed7f1fbb048aa47006576f424923933b Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Mon Mar 13 11:05:08 2017 +0100 virTimeBackOffWait: Avoid long periods of sleep While connecting to qemu monitor, the first thing we do is wait for it to show up. However, we are doing it with some timeout to avoid indefinite waits (e.g. when qemu doesn't create the monitor socket at all). After beaa447a29 we are using exponential back off timeout meaning, after the first connection attempt we wait 1ms, then 2ms, then 4 and so on. This allows us to bring down wait time for small domains where qemu initializes quickly. However, on the other end of this scale are some domains with huge amounts of guest memory. Now imagine that we've gotten up to wait time of 15 seconds. The next one is going to be 30 seconds, and the one after that whole minute. Well, okay - with current code we are not going to wait longer than 30 seconds in total, but this is going to change in the next commit. The exponential back off is usable only for first few iterations. Then it needs to be caped (one second was chosen as the limit) and switch to constant wait time. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |