|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 101218: regressions - FAIL
flight 101218 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/101218/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 101200 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestore 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 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestore fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 guest-saverestore fail never pass version targeted for testing: libvirt a46aa8852fe7d7c906d2845f152f645467c9fc6c baseline version: libvirt f4332dd2d8535b10eef8bce14bf7dc61200495f1 Last test of basis 101200 2016-09-29 04:30:48 Z 1 days Testing same since 101218 2016-09-30 04:20:33 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: John Ferlan <jferlan@xxxxxxxxxx> Laine Stump <laine@xxxxxxxxx> Martin Kletzander <mkletzan@xxxxxxxxxx> Michal Privoznik <mprivozn@xxxxxxxxxx> Roman Bogorodskiy <bogorodskiy@xxxxxxxxx> jobs: build-amd64-xsm pass build-armhf-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-armhf-armhf-libvirt-xsm fail 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-qcow2 fail 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 a46aa8852fe7d7c906d2845f152f645467c9fc6c Author: Laine Stump <laine@xxxxxxxxx> Date: Thu Sep 29 13:38:07 2016 -0400 docs: correct version requirements for <kvm><hidden='on'/></kvm> When support was added for the kvm hidden='on' attribute in commit d07116, the version requirement was listed as "2.1.0 (QEMU only)". However, this was added when libvirt was at version 1.2.8 - it is *QEMU* that must be at version 2.1.0 or later. This went unnoticed for a very long time (over 2 years). Then a week or two ago a new Windows convert in the #virt channel on OFTC was told he needed to use this feature (to prevent nvidia drivers in a guest from refusing to work due to being run in a virtual machine). There was some problem with it being recognized and "someone" (it may have been me, or may have been someone else, I don't remember) pointed out that the documentation at http://www.libvirt.org/formatdomain.html says that it requires libvirt 2.1.0. The next several days were filled with agony as a new convert to Linux first tried to upgrade a Linux Mint host running their "LTS" version to something newer, then tried to install a libvirt build built for Ubuntu onto this, and later back to the old LTS Linux Mint. After this he tried building his own libvirt from source (with all the expected problems), and finally switched to Fedora. In the end it was hours and hours of everybody's lives that they will never get back. To now learn that he didn't need to do this (his original libvirt version was 1.3.3, so whatever his problem was, it was elsewhere) makes the pain all that much worse. To prevent this from happening again, this simple patch changes the version requirement for the kvm hidden attribute from "2.1.0 (QEMU only)" to "1.2.8 (QEMU 2.1.0)". commit 5fe66ea3bfdae386064f782b9128f45f2ac37f64 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Thu Sep 15 13:05:34 2016 +0200 sanlock: Properly init io_timeout https://bugzilla.redhat.com/show_bug.cgi?id=1292984 Hold on to your hats, because this is gonna be wild. In bd3e16a3 I've tried to expose sanlock io_timeout. What I had not realized (because there is like no documentation for sanlock at all) was very unusual way their APIs work. Basically, what we do currently is: sanlock_add_lockspace_timeout(&ls, io_timeout); which adds a lockspace to sanlock daemon. One would expect that io_timeout sets the io_timeout for it. Nah! That's where you are completely off the tracks. It sets timeout for next lockspace you will probably add later. Therefore: sanlock_add_lockspace_timeout(&ls, io_timeout = 10); /* adds new lockspace with default io_timeout */ sanlock_add_lockspace_timeout(&ls, io_timeout = 20); /* adds new lockspace with io_timeout = 10 */ sanlock_add_lockspace_timeout(&ls, io_timeout = 40); /* adds new lockspace with io_timeout = 20 */ And so on. You get the picture. Fortunately, we don't allow setting io_timeout per domain or per domain disk. So we just need to set the default used in the very first step and hope for the best (as all the io_timeout-s used later will have the same value). Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 2bca7cec0ba9e861edb245f20d99d5b6fd22f760 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Thu Sep 15 10:45:26 2016 +0200 m4: Check for sanlock_write_lockspace Currently, we are checking for sanlock_add_lockspace_timeout which is good for now. But in a subsequent patch we are going to use sanlock_write_lockspace (which sets an initial value for io timeout for sanlock). Now, there is no reason to check for both functions in sanlock library as the sanlock_write_lockspace was introduced in 2.7 release and the one we are currently checking for in the 2.5 release. Therefore it is safe to assume presence of sanlock_add_lockspace_timeout when sanlock_write_lockspace is detected. Moreover, the macro for conditional compilation is renamed to HAVE_SANLOCK_IO_TIMEOUT (as it now encapsulates two functions). Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 78da4296a614c5d8a777ea2de8380ea11208e59b Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Thu Sep 15 13:18:13 2016 +0200 lock_driver_sanlock: Avoid global driver variable whenever possible Global variables are bad, we should avoid using them. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit ff3112f3dc2c276a7e387ff7bb86f4fbbdf7bf2c Author: Martin Kletzander <mkletzan@xxxxxxxxxx> Date: Fri Sep 23 11:31:30 2016 +0200 qemu: Only use memory-backend-file with NUMA if needed If this reminds you of a commit message from around a year ago, it's 41c2aa729f0af084ede95ee9a06219a2dd5fb5df and yes, we're dealing with "the same thing" again. Or f309db1f4d51009bad0d32e12efc75530b66836b and it's similar. There is a logic in place that if there is no real need for memory-backend-file, qemuBuildMemoryBackendStr() returns 0. However that wasn't the case with hugepage backing. The reason for that was that we abused the 'pagesize' variable for storing that information, but we should rather have a separate one that specifies whether we really need the new object for hugepage backing. And that variable should be set only if this particular NUMA cell needs special treatment WRT hugepages. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372153 Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> commit bcfa2f427d53264830ff5fa5d029b6897773702d Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Wed Sep 28 15:01:55 2016 -0400 vsh: Write out history on "quit" or "exit" in interactive mode https://bugzilla.redhat.com/show_bug.cgi?id=1379895 Introduced by commit id '834c5720'. During the code motion and creation of vsh.c, the function 'vshDeinit()' in the (new) vsh.c was altered from whence it came in virsh.c such that calling 'vshReadlineDeinit(ctl)' was conditional on "ctl->imode". This causes a problem for the interactive running if the "quit" and "exit" commands are used because 'cmdQuit' will clear ctl->imode, thus when the interactive loop in main() of virsh.c exits because ctl->mode is clear and virshDeinit is called which calls vshDeinit, the history file is now not written. Conversely, if one had exited the interactive loop via pressing <ctrl>D the file would be created because loop control is broken on EOF and ctl->imode is not set to false. This patch will remove the conditional call to vshReadlineDeinit and restore the former behaviour. commit 13aa79842cfa6c20c3b768c2ccd283bb5ef9e071 Author: Roman Bogorodskiy <bogorodskiy@xxxxxxxxx> Date: Thu Sep 29 08:10:33 2016 +0300 bhyve: chase cpuCompareXML rename In commit 7f127de cpuCompareXML was renamed to virCPUCompareXML, so change the bhyve driver to use the new function and thus fix the build. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |