[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 34801: regressions - FAIL
flight 34801 libvirt real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34801/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt 5 xen-boot fail REGR. vs. 34580 test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 34580 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 10 migrate-support-check fail never pass version targeted for testing: libvirt 0df2f0404fdc87691c940565e42fbde83ce71679 baseline version: libvirt 4438646c0d7ff5c4857e6b010032f0fdf0a6039c ------------------------------------------------------------ People who touched revisions under test: Daniel P. Berrange <berrange@xxxxxxxxxx> Ján Tomko <jtomko@xxxxxxxxxx> Luyao Huang <lhuang@xxxxxxxxxx> Michal Privoznik <mprivozn@xxxxxxxxxx> Pavel Hrdina <phrdina@xxxxxxxxxx> Peter Krempa <pkrempa@xxxxxxxxxx> Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx> ------------------------------------------------------------ jobs: 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 pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail ------------------------------------------------------------ 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 http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 0df2f0404fdc87691c940565e42fbde83ce71679 Author: Peter Krempa <pkrempa@xxxxxxxxxx> Date: Wed Feb 18 18:05:21 2015 +0100 qemu: Exit job on error path of qemuDomainSetVcpusFlags() Commit e105dc981438bc33fa771bd67cece6234dbf6c8d moved some code but didn't adjust the jump labels so that the job would be terminated. commit 5c756e580f0ad4fd19f801e770d54167d1159162 Author: Pavel Hrdina <phrdina@xxxxxxxxxx> Date: Wed Feb 18 16:10:58 2015 +0100 daemon: Fix segfault by reloading daemon right after start Libvirt could crash with segfault if user issue "service reload" right after "service start". One possible way to crash libvirt is to run reload during initialization of QEMU driver. It could happen when qemu driver will initialize qemu_driver_lock but don't have a time to set it's "config" and the SIGHUP arrives. The reload handler tries to get qemu_drv->config during "virStorageAutostart" and dereference it which ends with segfault. Let's ignore all reload requests until all drivers are initialized. In addition set driversInitialized before we enter virStateCleanup to ignore reload request while we are shutting down. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1179981 Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit 794235e813ffa9c56f2756501640398b0450de79 Author: Ján Tomko <jtomko@xxxxxxxxxx> Date: Wed Feb 18 15:36:45 2015 +0100 docs: clarify nat range behavior All the addresses from the range are used, not just those that are in use on the host. https://bugzilla.redhat.com/show_bug.cgi?id=1079917 commit b4c7f7eaeaf7933cb559f1ed438e4ea6a82a6ffe Author: Daniel P. Berrange <berrange@xxxxxxxxxx> Date: Mon Feb 16 11:58:32 2015 +0000 docs: add page about virtlockd setup Introduce some basic docs describing the virtlockd setup. Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> commit 575c839b6efa0d093f422688179d8c2b57e8fb2d Author: Daniel P. Berrange <berrange@xxxxxxxxxx> Date: Fri Feb 13 17:02:44 2015 +0000 docs: split out sanlock setup docs In preparation for adding docs about virtlockd, split out the sanlock setup docs into a separate page. Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> commit 77a9dc0b8dc714212a8550314178b09684719546 Author: Pavel Hrdina <phrdina@xxxxxxxxxx> Date: Tue Feb 17 14:08:22 2015 +0100 qemu_cgroup: initialize mem_mask to NULL If 'virNumaGetHostNodeset()' fails then the error path will try to free uninitialized pointer mem_mask. Introduced by commit af2a1f058. Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit 5e4f49ab8aa2dc7e71b8482e2f15f2a7de1c1006 Author: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx> Date: Sun Feb 15 09:54:15 2015 +0530 PowerPC : Forbid NULL CPU model with 'host-model' mode. PowerPC : Forbid NULL CPU model with 'host-model' mode in qemu command line. This ensures that an XML such as following: ... <cpu mode='host-model'> <model fallback='allow'/> </cpu> ... will not generate a '-cpu host,compat=(null)' command line with qemu-system-ppc64. Signed-off-by: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx> commit bdbe723fcd8b55678b0ad984134f7b79d6fbeb89 Author: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx> Date: Sun Feb 15 09:48:00 2015 +0530 PowerPC : Make 'qemu-system-ppc64' the default emulator on ppc64[le]. PowerPC : Explicitly associate 'qemu-system-ppc64' as the default emulator for all 64-bit PowerPC guests ( both Big & Little Endian ) Signed-off-by: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx> commit 337265bb52122ee536430e2493618ab4aa565987 Author: Luyao Huang <lhuang@xxxxxxxxxx> Date: Tue Feb 17 11:37:52 2015 +0800 qemu: fix vm deadlock when try to use numatune in session mode https://bugzilla.redhat.com/show_bug.cgi?id=1126762 Commit 43b67f introduced a deadlock issue when we use numatune to change numa settings to a vm in session mode. Jump to endjob instead of jump to cleanup. Signed-off-by: Luyao Huang <lhuang@xxxxxxxxxx> commit 7832fac84741d65e851dbdbfaf474785cbfdcf3c Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Thu Feb 12 17:43:27 2015 +0100 qemuBuildMemoryBackendStr: Report backend requirement more appropriately So, when building the '-numa' command line, the qemuBuildMemoryBackendStr() function does quite a lot of checks to chose the best backend, or to check if one is in fact needed. However, it returned that backend is needed even for this little fella: <numatune> <memory mode="strict" nodeset="0,2"/> </numatune> This can be guaranteed via CGroups entirely, there's no need to use memory-backend-ram to let qemu know where to get memory from. Well, as long as there's no <memnode/> element, which explicitly requires the backend. Long story short, we wouldn't have to care, as qemu works either way. However, the problem is migration (as always). Previously, libvirt would have started qemu with: -numa node,memory=X in this case and restricted memory placement in CGroups. Today, libvirt creates more complicated command line: -object memory-backend-ram,id=ram-node0,size=X -numa node,memdev=ram-node0 Again, one wouldn't find anything wrong with these two approaches. Both work just fine. Unless you try to migrated from the older libvirt into the newer one. These two approaches are, unfortunately, not compatible. My suggestion is, in order to allow users to migrate, lets use the older approach for as long as the newer one is not needed. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 38064806966c04d7cf7525cd78aa6f82bd09e6d0 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Thu Feb 12 17:39:34 2015 +0100 qemuxml2argvtest: Fake response from numad Well, we can pretend that we've asked numad for its suggestion and let qemu command line be built with that respect. Again, this alone has no big value, but see later commits which build on the top of this. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 65c0fd9dfc712d23721e8052ce655100e230a3b3 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Thu Feb 12 17:37:46 2015 +0100 numatune_conf: Expose virDomainNumatuneNodeSpecified This function is going to be needed in the near future. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 073bef64128bd1320b9bc4951a49edc5ab2570b1 Author: Luyao Huang <lhuang@xxxxxxxxxx> Date: Sun Feb 15 16:49:09 2015 +0800 virsh: fix IP address in vncdisplay for listen type='network' Just like the fix for domdisplay in commit 1ba815. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |