* [libvirt test] 61350: trouble: blocked/broken/pass
@ 2015-09-05 5:06 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2015-09-05 5:06 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 61350 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61350/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 3 host-install(3) broken REGR. vs. 61304
build-armhf 3 host-install(3) broken REGR. vs. 61304
build-armhf-pvops 3 host-install(3) broken REGR. vs. 61304
build-amd64 3 host-install(3) broken REGR. vs. 61304
build-i386-xsm 3 host-install(3) broken REGR. vs. 61304
build-i386-libvirt 3 host-install(3) broken REGR. vs. 61304
build-amd64-xsm 3 host-install(3) broken REGR. vs. 61304
build-amd64-pvops 3 host-install(3) broken REGR. vs. 61304
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-vhd 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-vhd 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-qcow2 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-qcow2 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-raw 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a
build-armhf-libvirt 1 build-check(1) blocked n/a
version targeted for testing:
libvirt a39ab909081ab126990ca705852d38ff056b8f13
baseline version:
libvirt 5c668a78d85b0d71e6ac8e23f2c605058b44df65
Last test of basis 61304 2015-09-02 12:32:03 Z 2 days
Testing same since 61350 2015-09-04 13:14:40 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Erik Skultety <eskultet@redhat.com>
Jim Fehlig <jfehlig@suse.com>
John Ferlan <jferlan@redhat.com>
Laine Stump <laine@laine.org>
Michal Privoznik <mprivozn@redhat.com>
Pavel Hrdina <phrdina@redhat.com>
jobs:
build-amd64-xsm broken
build-armhf-xsm broken
build-i386-xsm broken
build-amd64 broken
build-armhf broken
build-i386 pass
build-amd64-libvirt blocked
build-armhf-libvirt blocked
build-i386-libvirt broken
build-amd64-pvops broken
build-armhf-pvops broken
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked
test-amd64-amd64-libvirt-xsm blocked
test-armhf-armhf-libvirt-xsm blocked
test-amd64-i386-libvirt-xsm blocked
test-amd64-amd64-libvirt blocked
test-armhf-armhf-libvirt blocked
test-amd64-i386-libvirt blocked
test-amd64-amd64-libvirt-pair blocked
test-amd64-i386-libvirt-pair blocked
test-amd64-amd64-libvirt-qcow2 blocked
test-armhf-armhf-libvirt-qcow2 blocked
test-amd64-i386-libvirt-qcow2 blocked
test-amd64-amd64-libvirt-raw blocked
test-armhf-armhf-libvirt-raw blocked
test-amd64-i386-libvirt-raw blocked
test-amd64-amd64-libvirt-vhd blocked
test-armhf-armhf-libvirt-vhd blocked
test-amd64-i386-libvirt-vhd blocked
------------------------------------------------------------
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 build-armhf-xsm host-install(3)
broken-step build-armhf host-install(3)
broken-step build-armhf-pvops host-install(3)
broken-step build-amd64 host-install(3)
broken-step build-i386-xsm host-install(3)
broken-step build-i386-libvirt host-install(3)
broken-step build-amd64-xsm host-install(3)
broken-step build-amd64-pvops host-install(3)
Not pushing.
------------------------------------------------------------
commit a39ab909081ab126990ca705852d38ff056b8f13
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Aug 31 11:06:42 2015 -0400
qemu: Need to check for machine.os when using ADDRESS_TYPE_CCW
https://bugzilla.redhat.com/show_bug.cgi?id=1258361
When attaching a disk, controller, or rng using an address type ccw
or s390, we need to ensure the support is provided by both the machine.os
and the emulator capabilities (corollary to unconditional setting when
address was not provided for the correct machine.os and emulator.
For an inactive guest, an addition followed by a start would cause the
startup to fail after qemu_command builds the command line and attempts
to start the guest. For an active guest, libvirtd would crash.
commit d334c91751c8eea33abe8e92761433a145e38112
Author: John Ferlan <jferlan@redhat.com>
Date: Wed Sep 2 16:02:14 2015 -0400
qemu: Introduce qemuDomainMachineIsS390CCW
Rather than have different usages of STR function in order to determine
whether the domain is s390-ccw or s390-ccw-virtio, make a single API
which will check the machine.os prefix. Then use the function.
commit 682775fbb894d36d6b4d3a90009a16b1650c3981
Author: Erik Skultety <eskultet@redhat.com>
Date: Fri Sep 4 10:42:29 2015 +0200
vsh: Make vshInitDebug static
There's no reason why debug initialization could not be made completely
hidden, just like readline initialization is. The point of the global
initializer vshInit is to make initialization of smaller features transparent
to the user/caller.
commit a02de849a090e73fcd0074772f96a5cd09881e56
Author: Erik Skultety <eskultet@redhat.com>
Date: Fri Sep 4 11:19:55 2015 +0200
virsh: Do not make interactive mode default
Currently, we set interactive mode as default possibly reverting the
setting after we parse the command line arguments. There's nothing
particulary wrong with that, but a call to vshReadlineInit is performed
always in the global initializer just because the default mode is interactive.
Rather than moving vshReadlineInit call somewhere else (because another client
might want to implement interactive mode only), we could make the decision
if we're about to run in interactive mode once the command line is parsed.
commit f59d51f5184b3559538aaac8dc9bedc3e1e6c0f2
Author: Erik Skultety <eskultet@redhat.com>
Date: Thu Sep 3 16:59:01 2015 +0200
vsh: Introduce vshInitReload
Commit a0b6a36f separated vshInitDebug from the original vshInit
(before virsh got split and vshInit became virshInit - commit 834c5720)
in order to be able to debug command line parsing.
After the parsing is finished, debugging is reinitialized to work properly.
There might as well be other features that require re-initialization as
the command line could specify parameters that override our defaults which
had been set prior to calling vshArgvParse.
commit 57b8a38840fc0fd33b75783cbe5a496adcad6f02
Author: Erik Skultety <eskultet@redhat.com>
Date: Thu Sep 3 16:52:44 2015 +0200
vsh: adjust vshInit signature and remove redundant error label
As part of the effort to stay consistent, change the vshInit signature
from returning int to returning bool. Moreover, remove the
unnecessary error label as there is no cleanup that would make use of
it.
commit 6ce939c2472e8cd97dfe448e902bc878c826351e
Author: Jim Fehlig <jfehlig@suse.com>
Date: Thu Sep 3 10:14:20 2015 -0600
libxl: don't overwrite error from virNetSocketNewConnectTCP()
Remove redundant error reporting in libxlDomainMigrationPerform().
virNetSocketNewConnectTCP() is perfectly capable of reporting
sensible errors.
commit e92e5ba12825b32ccc929a527077fb7019c87d1b
Author: Pavel Hrdina <phrdina@redhat.com>
Date: Mon Aug 31 15:33:49 2015 +0200
domain-conf: escape string for socket attribute
Commit d091518b tried to escape all strings in produced XML, but missed
this one.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
commit 46cf0cefa0168a0d929ca87010f59e1cba6c689b
Author: Laine Stump <laine@laine.org>
Date: Wed Aug 26 00:18:26 2015 -0400
util: don't use netlink to save/set mac for macvtap+passthrough+802.1Qbh
Before libvirt sets the MAC address of the physdev (the physical
ethernet device) linked to a macvtap passthrough device, it always
saves the previous MAC address to restore when the guest is finished
(following a "leave nothing behind" policy). For a long time it
accomplished the save/restore with a combination of
ioctl(SIOCGIFHWADDR) and ioctl(SIOCSIFHWADDR), but in commit cbfe38c
(first in libvirt 1.2.15) this was changed to use netlink RTM_GETLINK
and RTM_SETLINK commands sent to the Physical Function (PF) of any
device that was detected to be a Virtual Function (VF).
We later found out that this caused problems with any devices using
the Cisco enic driver (e.g. vmfex cards) because the enic driver
hasn't implemented the function that is called to gather the
information in the IFLA_VFINFO_LIST attribute of RTM_GETLINK
(ndo_get_vf_config() for those keeping score), so we would never get
back a useful response.
In an ideal world, all drivers would implement all functions, but it
turns out that in this case we can work around this omission without
any bad side effects - since all macvtap passthrough <interface>
definitions pointing to a physdev that uses the enic driver *must*
have a <virtualport type='802.1Qbh'>, and since no other type of
ethernet devices use 802.1Qbh, libvirt can change its behavior in this
case to use the old-style. ioctl(SIOC[GS]IFHWADDR). That's what this
patch does.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1257004
commit 3ce08fab8477da2c76918329523a5e6a312cef06
Author: Laine Stump <laine@laine.org>
Date: Mon Aug 31 17:09:01 2015 -0400
util: make virNetDev(Replace|Restore)MacAddress public functions
These functions were made static as a part of commit cbfe38c since
they were no longer called from outside virnetdev.c. We once again
need to call them from another file, so this patch makes them once
again public.
commit e68930077034f786e219bdb015f8880dbc5a246f
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Thu Sep 3 12:11:53 2015 +0200
remoteClientCloseFunc: Don't mangle connection object refcount
Well, in 8ad126e6 we tried to fix a memory corruption problem.
However, the fix was not as good as it could be. I mean, the
commit has one line more than it should. I've noticed this output
just recently:
# ./run valgrind --leak-check=full --show-reachable=yes ./tools/virsh domblklist gentoo
==17019== Memcheck, a memory error detector
==17019== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17019== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==17019== Command: /home/zippy/work/libvirt/libvirt.git/tools/.libs/virsh domblklist gentoo
==17019==
Target Source
------------------------------------------------
fda /var/lib/libvirt/images/fd.img
vda /var/lib/libvirt/images/gentoo.qcow2
hdc /home/zippy/tmp/install-amd64-minimal-20150402.iso
==17019== Thread 2:
==17019== Invalid read of size 4
==17019== at 0x4EFF5B4: virObjectUnref (virobject.c:258)
==17019== by 0x5038CFF: remoteClientCloseFunc (remote_driver.c:552)
==17019== by 0x5069D57: virNetClientCloseLocked (virnetclient.c:685)
==17019== by 0x506C848: virNetClientIncomingEvent (virnetclient.c:1852)
==17019== by 0x5082136: virNetSocketEventHandle (virnetsocket.c:1913)
==17019== by 0x4ECD64E: virEventPollDispatchHandles (vireventpoll.c:509)
==17019== by 0x4ECDE02: virEventPollRunOnce (vireventpoll.c:658)
==17019== by 0x4ECBF00: virEventRunDefaultImpl (virevent.c:308)
==17019== by 0x130386: vshEventLoop (vsh.c:1864)
==17019== by 0x4F1EB07: virThreadHelper (virthread.c:206)
==17019== by 0xA8462D3: start_thread (in /lib64/libpthread-2.20.so)
==17019== by 0xAB441FC: clone (in /lib64/libc-2.20.so)
==17019== Address 0x139023f4 is 4 bytes inside a block of size 240 free'd
==17019== at 0x4C2B1F0: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17019== by 0x4EA8949: virFree (viralloc.c:582)
==17019== by 0x4EFF6D0: virObjectUnref (virobject.c:273)
==17019== by 0x4FE74D6: virConnectClose (libvirt.c:1390)
==17019== by 0x13342A: virshDeinit (virsh.c:406)
==17019== by 0x134A37: main (virsh.c:950)
The problem is, when registering remoteClientCloseFunc(), it's
conn->closeCallback which is ref'd. But in the function itself
it's conn->closeCallback->conn what is unref'd. This is causing
imbalance in reference counting. Moreover, there's no need for
the remote driver to increase/decrease conn refcount since it's
not used anywhere. It's just merely passed to client registered
callback. And for that purpose it's correctly ref'd in
virConnectRegisterCloseCallback() and then unref'd in
virConnectUnregisterCloseCallback().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit 4fdd873f1ad8995d8b36981a5936aafdc3f1df76
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Thu Sep 3 14:37:14 2015 +0200
vshInit: Don't leak @histsize_env
Caller is responsible for freeing the result of virStringJoin()
when no longer needed:
==10701== 1 bytes in 1 blocks are definitely lost in loss record 1 of 806
==10701== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10701== by 0xAADB679: strdup (in /lib64/libc-2.20.so)
==10701== by 0x4F18655: virStrdup (virstring.c:726)
==10701== by 0x4F175AF: virStringJoin (virstring.c:165)
==10701== by 0x131D4D: vshReadlineInit (vsh.c:2572)
==10701== by 0x1322DF: vshInit (vsh.c:2736)
==10701== by 0x1347C1: main (virsh.c:907)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit db9277a39bc364806e8d3e08a08fc128d59b7094
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Aug 24 12:38:13 2015 -0400
storage: Handle failure from refreshVol
Commit id '155ca616' added the 'refreshVol' API. In an NFS root-squash
environment it was possible that if the just created volume from XML wasn't
properly created with the right uid/gid and/or mode, then the followup
refreshVol will fail to open the volume in order to get the allocation/
capacity values. This would leave the volume still on the server and
cause a libvirtd crash because 'voldef' would be in the pool list, but
the cleanup code would free it.
commit 691dd388aee99f8b06177540303b690586d5f5b3
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Aug 24 12:48:40 2015 -0400
storage: Correct the 'mode' check
Commit id '7c2d65dde2' changed the default value of mode to be -1 if not
supplied in the XML, which should cause creation of the volume using the
default mode of VIR_STORAGE_DEFAULT_VOL_PERM_MODE; however, the check
made was whether mode was '0' or not to use default or provided value.
This patch fixes the issue to check if the 'mode' was provided in the XML
and use that value.
commit 35847860f65f92e444db9730e00cdaef45198e0c
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Aug 24 17:00:02 2015 -0400
virfile: Introduce virFileUnlink
In an NFS root-squashed environment the 'vol-delete' command will fail to
'unlink' the target volume since it was created under a different uid:gid.
This code continues the concepts introduced in virFileOpenForked and
virDirCreate[NoFork] with respect to running the unlink command under
the uid/gid of the child. Unlike the other two, don't retry on EACCES
(that's why we're here doing this now).
commit 1fafc1bc1cd5c18f36089ec697da08f72270b35c
Author: John Ferlan <jferlan@redhat.com>
Date: Mon Aug 24 12:37:41 2015 -0400
virfile: Add error for root squash change mode failure
This will only be seen when debugging, but in order to help determine
whether a virFileOpenForceOwnerMode failed during an NFS root-squash
volume/file creation, add an error message from the child.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2015-09-05 5:06 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-05 5:06 [libvirt test] 61350: trouble: blocked/broken/pass 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).