|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 63373: regressions - FAIL
flight 63373 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/63373/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: libvirt ac339206bfe98e78925b183cba058d0e2e7f03e3 baseline version: libvirt 3c7590e0a435d833895fc7b5be489e53e223ad95 Last test of basis 63340 2015-10-28 04:19:47 Z 3 days Failing since 63352 2015-10-29 04:20:29 Z 2 days 2 attempts Testing same since 63373 2015-10-30 04:21:45 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Laine Stump <laine@xxxxxxxxx> Luyao Huang <lhuang@xxxxxxxxxx> Maxim Perevedentsev <mperevedentsev@xxxxxxxxxxxxx> 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 fail 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 blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-armhf-armhf-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked 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 ac339206bfe98e78925b183cba058d0e2e7f03e3 Author: Laine Stump <laine@xxxxxxxxx> Date: Thu Oct 29 14:09:59 2015 -0400 util: set max wait for IPv6 DAD to 20 seconds This was originally set to 5 seconds, but times of 5.5 to 7 seconds were experienced. Since it's an arbitrary number intended to prevent an infinite hang, having it a bit too high won't hurt anything, and 20 seconds looks to be adequate (i.e. I think/hope we don't need to make it tunable in libvirtd.conf) commit d41a64a1948c88ccec5b4cff34fd04d3aae7a71e Author: Luyao Huang <lhuang@xxxxxxxxxx> Date: Thu Oct 29 17:47:33 2015 +0800 util: set error if DAD is not finished If DAD not finished in 5 seconds, user will get an unknown error like this: # virsh net-start ipv6 error: Failed to start network ipv6 error: An error occurred, but the cause is unknown Call virReportError to set an error. Signed-off-by: Luyao Huang <lhuang@xxxxxxxxxx> commit 7c8250d76561e83adf96b8e167f6932132252744 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Tue Oct 27 14:02:19 2015 +0100 wireshark: Install to generic plugin directory There has been a report on the list [1] that we are not installing the wireshark dissector into the correct plugin directory. And in fact we are not. The problem is, the plugin directory path is constructed at compile time. However, it's dependent on the wireshark version, e.g. /usr/lib/wireshark/plugins/1.12.6 This is rather unfortunate, because if libvirt RPMs were built with one version, but installed on a system with newer one, the plugins are not really loaded. This problem lead fedora packagers to unify plugin path to: /usr/lib/wireshark/plugins/ Cool! But this was enabled just in wireshark-1.12.6-4. Therefore, we must require at least that version. And while at it, on some distributions, the wireshark.pc file already has a variable that defines where plugin dir is. Use that if possible. 1: https://www.redhat.com/archives/libvirt-users/2015-October/msg00063.html Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 2589ca30196b305956f4211bc08132b63f77b6f2 Author: Roman Bogorodskiy <bogorodskiy@xxxxxxxxx> Date: Thu Oct 29 07:20:16 2015 +0300 Fix virNetDevWaitDadFinish stub Build on non-Linux fails because the virNetDevWaitDadFinish() stub has unused parameters. Fix by adding appropriate ATTRIBUTE_UNUSED for these parameters. Pushing under build-breaker rule. commit 0f7436ca54c9db2d5460bd54e7613f64f4727102 Author: Maxim Perevedentsev <mperevedentsev@xxxxxxxxxxxxx> Date: Tue Oct 20 18:44:18 2015 +0300 network: wait for DAD to finish for bridge IPv6 addresses commit db488c79 assumed that dnsmasq would complete IPv6 DAD before daemonizing, but in reality it doesn't wait, which creates problems when libvirt's bridge driver sets the matching "dummy tap device" to IFF_DOWN prior to DAD completing. This patch waits for DAD completion by periodically polling the kernel using netlink to check whether there are any IPv6 addresses assigned to bridge which have a 'tentative' state (if there are any in this state, then DAD hasn't yet finished). After DAD is finished, execution continues. To avoid an endless hang in case something was wrong with the kernel's DAD, we wait a maximum of 5 seconds. commit 131e7245a8336541ee61047eac8ecb447129b963 Author: Maxim Perevedentsev <mperevedentsev@xxxxxxxxxxxxx> Date: Tue Oct 20 18:44:19 2015 +0300 netlink: add support for multi-part netlink messages. Such messages do not have NLMSG_ERROR or NLMSG_DONE type but they are valid responses. We test 'multi-partness' by looking for NLM_F_MULTI flag. commit 4eac55238f856d29d07a60448adb2e0b2f8e28b5 Author: Luyao Huang <lhuang@xxxxxxxxxx> Date: Mon Oct 12 17:28:15 2015 +0800 qemu: Use live autoNodeset when numatune placement is auto https://bugzilla.redhat.com/show_bug.cgi?id=1270715 Commit id '9deb96f' removed the code to fetch the nodeset from the CpusetMems cgroup for a running vm in favor of using the return from virDomainNumatuneFormatNodeset introduced by commit id '43b67f2e7'. However, that API will return the value of the passed 'auto_nodeset' when placement is VIR_DOMAIN_NUMATUNE_PLACEMENT_AUTO, which happens to be NULL. Since commit id 'c74d58ad' started using priv->autoNodeset in order to manage the auto placement value during qemuProcessStart, it should be passed along in order to return the correct value if the domain requests the auto placement. Signed-off-by: Luyao Huang <lhuang@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |