From: xen.org <Ian.Jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [libvirt test] 30444: trouble: blocked/broken/fail/pass
Date: Sat, 27 Sep 2014 21:06:38 +0100 [thread overview]
Message-ID: <osstest-30444-mainreport@xen.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 8867 bytes --]
flight 30444 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/30444/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3) broken REGR. vs. 30408
build-armhf-pvops 3 host-install(3) broken REGR. vs. 30408
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start fail never pass
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
version targeted for testing:
libvirt 9e159b521dbf18c6da6976e54e29c8553f831eb6
baseline version:
libvirt 92b0577db269764dfbb2b5139647796315f73702
------------------------------------------------------------
People who touched revisions under test:
Daniel P. Berrange <berrange@redhat.com>
Guido Günther <agx@sigxcpu.org>
Jincheng Miao <jmiao@redhat.com>
Ján Tomko <jtomko@redhat.com>
Michal Privoznik <mprivozn@redhat.com>
Pavel Hrdina <phrdina@redhat.com>
Peter Krempa <pkrempa@redhat.com>
Tomoki Sekiyama <tomoki.sekiyama@hds.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt broken
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops broken
build-i386-pvops pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt blocked
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 9e159b521dbf18c6da6976e54e29c8553f831eb6
Author: Guido Günther <agx@sigxcpu.org>
Date: Thu Sep 25 10:30:58 2014 +0200
qemu: remove capabilities.monitor.sock when done
Prompted by
http://bugs.debian.org/761131
commit e02908880259c2587c7ec42d5ab5d967a7daa0a1
Author: Jincheng Miao <jmiao@redhat.com>
Date: Thu Sep 25 19:28:33 2014 +0800
conf: report error in virCPUDefParseXML
When detected invalid 'memAccess', virCPUDefParseXML should report error.
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1146334
Signed-off-by: Jincheng Miao <jmiao@redhat.com>
commit b987c4c3f4829eb8a0134b687cb9748ff724f98a
Author: Ján Tomko <jtomko@redhat.com>
Date: Mon Sep 22 13:54:52 2014 +0200
Check for NULL in qemu monitor event filter
When virConnectDomainQemuMonitorEventRegister is called with the
VIR_CONNECT_DOMAIN_QEMU_MONITOR_EVENT_REGISTER_REGEX flag,
ignore the flag instead of crashing.
https://bugzilla.redhat.com/show_bug.cgi?id=1144920
commit 42571dfa867acb89fea9a731f2e816005c9ab787
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Fri Sep 26 11:20:56 2014 +0100
Fix typo s/EMULATORIN/EMULATORPIN/
Fix the typo in VIR_DOMAIN_TUNABLE_CPU_EMULATORIN
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
commit 0778c0be8deec25c8f040d4bdeddee50cbb26234
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Thu Sep 25 17:48:01 2014 +0100
Rename tunable event constants
For the new VIR_DOMAIN_EVENT_ID_TUNABLE event we have a bunch of
constants added
VIR_DOMAIN_EVENT_CPUTUNE_<blah>
VIR_DOMAIN_EVENT_BLKDEVIOTUNE_<blah>
This naming convention is bad for two reasons
- There is no common prefix unique for the events to both
relate them, and distinguish them from other event
constants
- The values associated with the constants were chosen
to match the names used with virConnectGetAllDomainStats
so having EVENT in the constant name is not applicable in
that respect
This patch proposes renaming the constants to
VIR_DOMAIN_TUNABLE_CPU_<blah>
VIR_DOMAIN_TUNABLE_BLKDEV_<blah>
ie, given them a common VIR_DOMAIN_TUNABLE prefix.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
commit c99f66ac4c831b2ff9116c2e2ca003cd3550bff8
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Tue Sep 23 10:44:42 2014 +0200
lxc_monitor_protocol: Redefine xdr_uint64_t if needed
https://bugzilla.redhat.com/show_bug.cgi?id=993411
On some systems (using libtirpc instead of glibc's
implementation), xdr_uint64_t exists rather under different name:
xdr_u_int64_t. This makes compilation fail then:
libvirt_lxc-lxc_monitor_protocol.o: In function `xdr_virLXCMonitorInitEventMsg':
/usr/local/src/libvirt/libvirt-1.1.1/src/./lxc/lxc_monitor_protocol.c:31: undefined reference to `xdr_uint64_t'
Therefore we rather mirror the d707c866 commit and redefine
xdr_uint64_t if needed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit 3a3c3780b478ccf137b434754c7c6b1ddbdf1ac2
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Thu Sep 25 14:39:19 2014 +0200
qemuPrepareNVRAM: Save domain after NVRAM path generation
On a domain startup, the variable store path is generated if needed.
The path is intended to be generated only once. However, the updated
domain definition is not saved into config dir rather than state XML
only. So later, whenever the domain is destroyed and the daemon is
restarted, the generated path is forgotten and the file may be left
behind on virDomainUndefine() call.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit f2729283107dc749037453e30b6e21ef3af8d468
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Thu Sep 25 11:18:50 2014 +0200
remoteNodeGetFreePages: Don't alloc args.pages.pages_val
There's no one to free() it anyway. Instead, we can just pass the
provided array pointer directly.
==20039== 48 bytes in 4 blocks are definitely lost in loss record 658 of 787
==20039== at 0x4C2A700: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20039== by 0x4EA661F: virAllocN (viralloc.c:191)
==20039== by 0x50386EF: remoteNodeGetFreePages (remote_driver.c:7625)
==20039== by 0x5003504: virNodeGetFreePages (libvirt.c:21379)
==20039== by 0x154625: cmdFreepages (virsh-host.c:374)
==20039== by 0x12F718: vshCommandRun (virsh.c:1935)
==20039== by 0x1339FB: main (virsh.c:3747)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit efafc9c1ceacda4522b8501514699241c007f5a2
Author: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
Date: Thu Sep 25 16:02:21 2014 -0400
nodeinfo: fix version of nodeAllocPages
Fix comments about the version in which '.nodeAllocPages' are added.
Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
commit fe7ef7b112b3b4d6f9c9edf499a79683fb0b7edb
Author: Peter Krempa <pkrempa@redhat.com>
Date: Thu Sep 25 17:30:28 2014 +0200
qemu: Always re-detect backing chain
Since 363e9a68 we track backing chain metadata when creating snapshots
the right way even for the inactive configuration. As we did not yet
update other code paths that modify the backing chain (blockpull) the
newDef backing chain gets out of sync.
After stopping of a VM the new definition gets copied to the next start
one. The new VM then has incorrect backing chain info. This patch
switches the backing chain detector to always purge the existing backing
chain and forces re-detection to avoid this issue until we'll have full
backing chain tracking support.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1144922
commit f06a6257d5c2c29aff5140c38583a7fcd07d2b93
Author: Pavel Hrdina <phrdina@redhat.com>
Date: Thu Sep 25 15:03:46 2014 +0200
event_example: cleanup example code for tunable event
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
reply other threads:[~2014-09-27 20:06 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-30444-mainreport@xen.org \
--to=ian.jackson@eu.citrix.com \
--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).