|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 100404: regressions - FAIL
flight 100404 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/100404/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-build fail REGR. vs. 100381 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 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-amd64-libvirt 12 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestore fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 guest-saverestore fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestore fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail never pass version targeted for testing: libvirt 9aea8cd4ae76b5f62ea365dd56d4d9beb96bb024 baseline version: libvirt 5b8643099a99dc4ee0dac4bf543a874ffc4c314f Last test of basis 100381 2016-08-10 04:20:25 Z 1 days Testing same since 100404 2016-08-11 04:20:33 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Chen Hanxiao <chenhanxiao@xxxxxxxxx> Cole Robinson <crobinso@xxxxxxxxxx> Erik Skultety <eskultet@xxxxxxxxxx> Jiri Denemark <jdenemar@xxxxxxxxxx> Laine Stump <laine@xxxxxxxxx> Michal Privoznik <mprivozn@xxxxxxxxxx> jobs: build-amd64-xsm fail 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 blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm blocked 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 9aea8cd4ae76b5f62ea365dd56d4d9beb96bb024 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Tue Aug 9 19:25:44 2016 +0200 virNetDevMacVLanCreateWithVPortProfile: Drop @ret Usually, this variable is used to hold the return value for a function of ours. Well, this is not the case. Its use does not match our pattern and therefore it is very misleading. Drop it and define an alternative @rc variable, but only in that single block where it is needed. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 42712002fd49e7407e3279ebb947f5b7f8faa7f0 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Tue Aug 9 19:23:15 2016 +0200 virNetDevMacVLanCreateWithVPortProfile: Drop @rc This variable is very misleading. We use VIR_FORCE_CLOSE to set it to -1 and returning it even though it does not refer to a FD at all. It merely holds 0 or -1. Drop it completely. Also, at the same time some corner cases are fixed too. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 96e24861564dfdc21b843f00d094d71e696366bd Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Tue Aug 9 18:47:49 2016 +0200 virNetDevMacVLanCreateWithVPortProfile: Don't mask virNetDevMacVLanTapOpen error https://bugzilla.redhat.com/show_bug.cgi?id=1240439 In this function we create a macvtap device and open its tap device. Possibly multiple times. Now the thing is, if opening the tap device fails, that is virNetDevMacVLanTapOpen() returns a negative value, we unroll all the changes BUT return 0 fooling caller into thinking everything went okay. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 856965b36246b26002af409262846317477ea631 Author: Cole Robinson <crobinso@xxxxxxxxxx> Date: Wed Aug 10 10:32:03 2016 -0400 qemu: fix qemu.conf security_driver Since a9331394 (first release v2.1.0), specifying a manual security_driver setting in qemu.conf causes the daemon to fail to start, erroring with 'Duplicate security driver X'. The duplicate checking was incorrectly comparing every entry against itself, guaranteeing a false positive. https://bugzilla.redhat.com/show_bug.cgi?id=1365607 commit a220f43a65cca6c6f2ca268cdbbf8f997b2e2b13 Author: Laine Stump <laine@xxxxxxxxx> Date: Sat Aug 6 19:03:31 2016 -0400 conf: restrict expander buses to connect only to a root bus More misunderstanding/mistaken assumptions on my part - I had thought that a pci-expander-bus could be plugged into any legacy PCI slot, and that pcie-expander-bus could be plugged into any PCIe slot. This isn't correct - they can both be plugged ontly into their respective root buses. This patch adds that restriction. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358712 commit b70e3d0123fcb6e22e99d1b272239e03a84262cb Author: Laine Stump <laine@xxxxxxxxx> Date: Fri Aug 5 15:01:08 2016 -0400 conf: restrict where dmi-to-pci-bridge can be connected libvirt had allowed a dmi-to-pci-bridge to be plugged in anywhere a normal PCIe endpoint can be connected, but this is wrong - it will only work if it's plugged into pcie-root (the PCIe root complex) or a pcie-expander-bus (the qemu device pxb-pcie). This patch adjusts the connection flags accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363648 commit b70e54342bbd1756234e07ed6b22bdd3cd12b689 Author: Laine Stump <laine@xxxxxxxxx> Date: Thu Aug 4 13:04:12 2016 -0400 conf: don't allow connecting upstream-port directly to pce-expander-bus I apparently misunderstood Marcel's description of what could and couldn't be plugged into qemu's pxb-pcie controller (known as pcie-expander-bus in libvirt) - I specifically allowed directly connecting a pcie-switch-upstream-port, and it turns out that causes the guest kernel to crash. This patch forbids such a connection, and updates the xml docs appropriately. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1361172 commit 10031fe5f218fe0acbf873a3063ce42a02fa83d9 Author: Laine Stump <laine@xxxxxxxxx> Date: Fri Aug 5 21:19:27 2016 -0400 conf: improve error log when PCI devices don't match requested controller The virDomainPCIAddressFlagsCompatible() error logs report that a device required a controller that accepted standard PCI endpoint devices, or PCI Express endpoint devices, and if hotplug was required by the configuration but not provided by the selected controller. But the wording of the error messages was apparently confusing (according to the bugzilla report referenced below). On top of that, if the device was something other than an endpoint device (e.g. a pcie-switch-downstream-port) the error message was a complete punt - it would just say that the flags were incorrect. This patch makes the messages for PCI/PCIe endpoint and hotplug requirements more clear, and also specifically indicates what was the device type when it is other than an endpoint device. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363627 commit 4914494eb8e25ff7938a12fd089c746ec6042bbb Author: Erik Skultety <eskultet@xxxxxxxxxx> Date: Tue Aug 9 16:11:26 2016 +0200 virt-admin: Fix the error when an invalid URI has been provided After commit 9d479dd1 fiddled with the cmdConnect's output which used to be a bit more verbose prior to the mentioned commit, the program flow would result in a quite confusing error if an invalid URI has been provided: error: Failed to connect to the admin server Connected to the admin server error: <some error> The problem is that the commit mentioned above relied on the fact that connect routine always succeeds which is not true. Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx> commit 300f668c665f1ec0f834917fe8a58b5991322441 Author: Jiri Denemark <jdenemar@xxxxxxxxxx> Date: Tue Aug 9 15:15:20 2016 +0200 cpu_x86: Fix host-model CPUs on hosts with CMT Since the introduction of CMT features (commit v1.3.5-461-gf294b83) starting a domain with host-model CPU on a host which supports CMT fails because QEMU complains about unknown 'cmt' feature: qemu-system-x86_64: CPU feature cmt not found https://bugzilla.redhat.com/show_bug.cgi?id=1355857 Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx> commit 58ba240df89a7dd7bff16ebb65d9aadd49fb8bbb Author: Jiri Denemark <jdenemar@xxxxxxxxxx> Date: Tue Aug 9 15:03:20 2016 +0200 tests: Add a test for host-model CPU with CMT feature The generated command line wouldn't work since QEMU doesn't know what 'cmt' is. The following patch will fix this issue. https://bugzilla.redhat.com/show_bug.cgi?id=1355857 Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx> commit 1ac897a15da11d1bfca2642bce3b0beaad32bcf1 Author: Jiri Denemark <jdenemar@xxxxxxxxxx> Date: Tue Jun 28 11:12:41 2016 +0200 cpu_x86: Properly drop non-migratable features By removing a non-migratable feature in a for loop we would fail to drop every second non-migratable feature if the features array contained several of them in a row. Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx> commit dbb14bb0f1316d92c89541fca816c91dce0dc8fb Author: Jiri Denemark <jdenemar@xxxxxxxxxx> Date: Tue Jun 28 10:51:41 2016 +0200 cpu_x86: Introduce x86FeatureIsMigratable Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx> commit 73b647d4189ced1f0189b53290cf22c1531219bc Author: Chen Hanxiao <chenhanxiao@xxxxxxxxx> Date: Fri Aug 5 15:23:52 2016 +0800 virsh: clarify snapshot --live In libvirt, snapshot means disk snapshot. snapshot --live is more like VM checkpoint. Make it clear in virsh.pod. Signed-off-by: Chen Hanxiao <chenhanxiao@xxxxxxxxx> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |