* [libvirt test] 101218: regressions - FAIL
@ 2016-09-30 9:17 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2016-09-30 9:17 UTC (permalink / raw)
To: xen-devel, osstest-admin
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@redhat.com>
Laine Stump <laine@laine.org>
Martin Kletzander <mkletzan@redhat.com>
Michal Privoznik <mprivozn@redhat.com>
Roman Bogorodskiy <bogorodskiy@gmail.com>
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@laine.org>
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@redhat.com>
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@redhat.com>
commit 2bca7cec0ba9e861edb245f20d99d5b6fd22f760
Author: Michal Privoznik <mprivozn@redhat.com>
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@redhat.com>
commit 78da4296a614c5d8a777ea2de8380ea11208e59b
Author: Michal Privoznik <mprivozn@redhat.com>
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@redhat.com>
commit ff3112f3dc2c276a7e387ff7bb86f4fbbdf7bf2c
Author: Martin Kletzander <mkletzan@redhat.com>
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@redhat.com>
commit bcfa2f427d53264830ff5fa5d029b6897773702d
Author: John Ferlan <jferlan@redhat.com>
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@gmail.com>
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@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-09-30 9:17 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-30 9:17 [libvirt test] 101218: regressions - FAIL osstest service owner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).