From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [libvirt test] 113119: trouble: blocked/broken/pass
Date: Thu, 07 Sep 2017 18:50:48 +0000 [thread overview]
Message-ID: <osstest-113119-mainreport@xen.org> (raw)
flight 113119 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113119/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 <job status> broken
build-arm64-xsm <job status> broken
build-arm64-pvops <job status> broken
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
build-arm64-xsm 2 hosts-allocate broken like 113032
build-arm64-pvops 2 hosts-allocate broken like 113032
build-arm64-xsm 3 capture-logs broken like 113032
build-arm64 2 hosts-allocate broken like 113032
build-arm64-pvops 3 capture-logs broken like 113032
build-arm64 3 capture-logs broken like 113032
test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail like 113032
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 113032
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 113032
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
version targeted for testing:
libvirt 01f3ea6488a1290d7af3af7b68aade64d937d424
baseline version:
libvirt 4ee36c33ed371a1d9dfb9cd97b2af0ee08abd3f3
Last test of basis 113032 2017-09-04 04:20:11 Z 3 days
Failing since 113046 2017-09-05 04:23:42 Z 2 days 3 attempts
Testing same since 113119 2017-09-07 04:20:18 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrea Bolognani <abologna@redhat.com>
Cole Robinson <crobinso@redhat.com>
Daniel P. Berrange <berrange@redhat.com>
Daniel Veillard <veillard@redhat.com>
Erik Skultety <eskultet@redhat.com>
John Ferlan <jferlan@redhat.com>
Michal Privoznik <mprivozn@redhat.com>
Richard W.M. Jones <rjones@redhat.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm broken
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 broken
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 broken
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 pass
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-job build-arm64 broken
broken-job build-arm64-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-xsm hosts-allocate
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-xsm capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs
Not pushing.
------------------------------------------------------------
commit 01f3ea6488a1290d7af3af7b68aade64d937d424
Author: Andrea Bolognani <abologna@redhat.com>
Date: Wed Sep 6 14:48:48 2017 +0200
travis: Install gettext
msgmerge(1) and friends are required to build libvirt, so the
corresponding package should be installed in the Travis worker.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
commit b023feeca377a843334fb5b30f5f0ac2a1334303
Author: Andrea Bolognani <abologna@redhat.com>
Date: Wed Sep 6 14:46:07 2017 +0200
travis: Sort build dependencies
Keeping the list of build dependencies sorted alphabetically
makes it way easier to visually scan it for issues.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
commit c57f3fd2f8999d17e01272246b26d31179ab7b6e
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Tue Sep 5 16:24:14 2017 +0200
conf: Validate device on update-device
https://bugzilla.redhat.com/show_bug.cgi?id=1439991
Whenever a device is being updated via
virDomainUpdateDeviceFlags() API, we parse the device XML and
ideally run some generic checks to validate the configuration
(e.g. if device defines per-device boot order but the domain has
os/boot element already). Well, that's the theory - due to a
missing check we've jumped early from that check function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
commit fbe315bdc89732225d2d5b898468569fd2a1fa25
Author: Andrea Bolognani <abologna@redhat.com>
Date: Tue Sep 5 16:37:50 2017 +0200
m4: Disable -Wdisabled-optimization
After b4f7793ce269, qemuxml2xmltest has apparently become big enough
to trigger a compilation error when using --enable-test-coverage on
aarch64:
CC qemuxml2xmltest.o
qemuxml2xmltest.c: In function 'mymain':
qemuxml2xmltest.c:1216:1: error: const/copy propagation disabled: 4361 basic blocks and 99285 registers [-Werror=disabled-optimization]
}
^
qemuxml2xmltest.c:1216:1: error: PRE disabled: 4361 basic blocks and 99285 registers [-Werror=disabled-optimization]
qemuxml2xmltest.c:1216:1: error: const/copy propagation disabled: 4361 basic blocks and 99285 registers [-Werror=disabled-optimization]
qemuxml2xmltest.c:1216:1: error: const/copy propagation disabled: 4361 basic blocks and 99285 registers [-Werror=disabled-optimization]
However, as the GCC documentation states, this warning is not really
caused by issues in our code, so it makes sense to disable it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
commit d143837bd181230719e23205554850798a1ebbfe
Author: John Ferlan <jferlan@redhat.com>
Date: Fri Sep 1 13:16:17 2017 -0400
qemu: Remove unused params from qemuDomainDeviceDefValidate
Neither @cfg nor (now) @driver is used in the API, so remove them
and mark @opaque as UNUSED.
NB: Commit id 'fa3c558596' dropped the unused @qemuCaps which was the
last consumer of @driver other than @cfg, but even @cfg was never used
even in the original implementation from commit id 'd987f63a'.
commit dda0da14cd6ebff98c2293b1407371286853a38f
Author: Cole Robinson <crobinso@redhat.com>
Date: Sun Aug 27 11:04:42 2017 -0400
qemu: Default to video type=virtio for machvirt
arm/aarch64 -M virt on KVM doesn't and will never work with standard
VGA card emulation. The recommended method is to use type=virtio, so
let's make it the default for video devices without an explicit type
set by the user.
https://bugzilla.redhat.com/show_bug.cgi?id=1404112
Signed-off-by: Cole Robinson <crobinso@redhat.com>
commit ef08a545388f388b7c76b99a3f3d2584daf05145
Author: Cole Robinson <crobinso@redhat.com>
Date: Sun Aug 27 11:04:41 2017 -0400
qemu: Set default video type in qemu PostParse
And not generic domain_conf code. We will need qemu private functions
in a bit.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
commit 29a90f071dd7c1764f82c7fcbfdded35d252b174
Author: Cole Robinson <crobinso@redhat.com>
Date: Sun Aug 27 11:04:40 2017 -0400
conf: domain: move video type validation to DeviceDefValidate
This allows drivers to set their own default. But if a driver neglects
to fill one in, we still error like we previously would at parse time.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
commit a2ca7ca52eb624883ac5a7e1d5deebb43981a410
Author: Cole Robinson <crobinso@redhat.com>
Date: Sun Aug 27 11:04:39 2017 -0400
conf: domain: add VIDEO_TYPE_DEFAULT
Will be needed for future patches to pull the default video type
setting out of XML parsing routines.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
commit 4c248e938a5541768614b94ad2f8b946a301434c
Author: Erik Skultety <eskultet@redhat.com>
Date: Tue Sep 5 10:06:33 2017 +0200
maint: Fix incorrect parenthesis placement causing true/false assignment
There were a few places in our code where the following pattern in 'if'
condition occurred:
if ((foo = bar() < 0))
do something;
This patch adjusts the conditions to the expected format:
if ((foo = bar()) < 0)
do something;
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1488192
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
commit a2b240e60e60ffa8b5dbcc336af1274b57c40108
Author: Andrea Bolognani <abologna@redhat.com>
Date: Mon Sep 4 15:06:16 2017 +0200
Makefile.nonreentrant: Rebuild against Fedora 26
According to the comments in the file and the git history, the
list of forbidden symbols was originally built against Fedora 9
in 2009 (!) and pretty much never refreshed afterwards.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
commit bc0108845c73d165f0abbd940f8755ccfccc1722
Author: Andrea Bolognani <abologna@redhat.com>
Date: Mon Sep 4 14:04:10 2017 +0200
docs: Fix typo deamon -> daemon
Suggested-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
commit 5f5c515bbdcb7ce8db12544033fad393eb2a1c41
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Fri Sep 1 13:47:04 2017 +0100
event: ignore attempts to replace the event loop impl
Although not previously explicitly documented, the expectation for
the libvirt event loop is that an implementation is registered early
in application startup, before calling any libvirt APIs and then
run forever after. Replacing a previously registered event loop is
not safe & subject to races even if virConnectClose has been called
on open handles, due to delayed deregistration of callbacks during
conenction close.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
commit 5a1a649dcf7f5a51ed117146facc8c45402ea4a3
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Mon Sep 4 12:42:46 2017 +0100
Add libxslt as build requires for mingw RPMs
The libxslt package is needed since:
commit 94d2d6429d686c5af95115d09c01f3c6bd5ea7c6
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed Jul 26 17:40:44 2017 +0100
docs: make xmllint & xsltproc compulsory
The native RPM had it already, but mingw build was missing it.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
commit e703039c203e9dd2dac97291f9c30098efe542a0
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Tue Aug 29 18:11:08 2017 +0200
lxcStateInitialize: Don't leak driver's caps
Funny thing. So when initializing LXC driver's capabilities,
firstly the virLXCDriverGetCapabilities() is called. This creates
new capabilities, stores them under driver->caps, ref() them and
return them. However, the return value is ignored. Secondly, the
function is called yet again and since we have driver->caps set,
they are ref()-ed again an returned. So in the end, driver's
capabilities have refcount of three when in fact they should have
refcount of one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit e8a9929229c3993b47fb22d2afd4994b79b921f2
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Mon Sep 4 12:29:55 2017 +0200
Post-release version bump to 3.8.0
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit d83dac00d9d3375b08759ad7422f8b1760a08ba2
Author: Daniel Veillard <veillard@redhat.com>
Date: Mon Sep 4 12:14:11 2017 +0200
Release of libvirt-3.7.0
* docs/news.xml: update for release
* po/*.po*: regenerated
commit 4c10c38275349805fac325b5c701c399cec0c9a3
Author: Richard W.M. Jones <rjones@redhat.com>
Date: Fri Aug 25 14:36:58 2017 +0100
vmx: Expose VMware Managed Object Reference (moref) in XML.
If you use the VDDK library to access virtual machines remotely, you
really need to know the Managed Object Reference ("moref") of the VM.
This must be passed each time you connect to the API.
For example nbdkit's VDDK plugin requires a moref to be passed to
mount up a VM's disk remotely:
nbdkit vddk user=root password=+/tmp/rootpw \
server=esxi.example.com thumbprint=xx:xx:xx:... \
vm=moref=2 \
file="[datastore1] Fedora/Fedora.vmdk"
Getting the moref is a huge pain. To get some idea of what it is, why
it is needed, and how much trouble it is to get it, see:
https://blogs.vmware.com/vsphere/2012/02/uniquely-identifying-virtual-machines-in-vsphere-and-vcloud-part-1-overview.html
https://blogs.vmware.com/vsphere/2012/02/uniquely-identifying-virtual-machines-in-vsphere-and-vcloud-part-2-technical.html
However the moref is available conveniently in the internals of the
libvirt VMX driver. This patch exposes it as a custom XML element
using the same "vmware:" namespace which was previously used for the
datacenterpath (see libvirt commit 636a99058758a044).
It appears in the XML like this:
<domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'>
<name>Fedora</name>
...
<vmware:datacenterpath>ha-datacenter</vmware:datacenterpath>
<vmware:moref>2</vmware:moref>
</domain>
Note that the moref can appear as either a simple ID (for esx://
connections) or as a "vm-<ID>" (for vpx:// connections). It should be
treated by users as an opaque string.
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
reply other threads:[~2017-09-07 18:50 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=osstest-113119-mainreport@xen.org \
--to=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).