|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 104036: regressions - FAIL
flight 104036 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/104036/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 104005 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 104005 test-armhf-armhf-libvirt 13 saverestore-support-check fail like 104005 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 104005 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 104005 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 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 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass version targeted for testing: libvirt 1d0fde7ee137d2a80c937db1037cbc5fd2e2cde5 baseline version: libvirt 0735ddf744f95cd9f88c5f8465b1a64883710d37 Last test of basis 104005 2017-01-03 04:20:30 Z 2 days Failing since 104021 2017-01-04 04:20:15 Z 1 days 2 attempts Testing same since 104036 2017-01-05 04:20:32 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani <abologna@xxxxxxxxxx> John Ferlan <jferlan@xxxxxxxxxx> Martin Kletzander <mkletzan@xxxxxxxxxx> Michal Privoznik <mprivozn@xxxxxxxxxx> Peter Krempa <pkrempa@xxxxxxxxxx> 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 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 pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-armhf-armhf-libvirt-qcow2 pass 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 Not pushing. ------------------------------------------------------------ commit 1d0fde7ee137d2a80c937db1037cbc5fd2e2cde5 Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Fri Nov 18 08:55:35 2016 -0500 util: Remove need for extra VIR_FREE's in virGetFCHostNameByWWN Rather than extraneous VIR_FREE's depending on where we are in the code, move them to the top of the loop and in the cleanup path. Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> commit 9fdc8c4269d710328c4d57292d6404ff13b6f632 Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Tue Jan 3 17:00:36 2017 -0500 scsi: Converge more createVport checks Remove duplicated code - make one simple path through Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> commit 476ecf2a2a7f9d7498fbe61b0431006f4088125d Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Fri Nov 18 07:44:52 2016 -0500 scsi: Change order of checks in createVport Move the check for an already existing vHBA to the top of the function. No sense in first decoding a provided parent if the next thing we're going to do is fail if a provided wwnn/wwpn already exists. Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> commit 79ab093518ffd07724eb0f8950a07b81d878e9b3 Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Fri Nov 18 07:19:28 2016 -0500 scsi: Clean up createVport exit paths Use the ret = -1, goto cleanup, etc. rather than current hodgepodge. Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> commit 8b629a3c01b8c5e148f8bbe3776f19150784cf80 Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Wed Nov 16 17:50:09 2016 -0500 nodedev: Add ability to find a vport capable vHBA If a <parent> is not supplied in the XML used to create a non-persistent vHBA, then instead of failing, let's try to find a "vports" capable node device and use that. Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> commit 8f3054a0f8339f52aed0c537361507820b8441bd Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Thu Nov 17 15:03:00 2016 -0500 nodedev: Create helpers to search for vport capable nodedevs Extract out code from virNodeDeviceGetParentHost into helpers - it's going to be reused in upcoming patches to search on more fields Create virNodeDeviceFindVPORTCapDef in order to return a virNodeDevCapsDefPtr of the VPORT_OPS and virNodeDeviceFindFCParentHost to use the function and generate an error message if the device doesn't have the capability. Also clean up the processing in virNodeDeviceGetParentHost to remove need for goto's. Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> commit 79bf25cd9c7c75fdd9eb1c4fa678d2f1c8e8d24a Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Wed Jan 4 18:05:16 2017 +0100 NEWS: Remove spurious period All other entries in the release notes omit the leading period, and so should this one in order to maintain consistency. commit 2e86c0816fc8ab573745f1a9a650be09bd66e300 Author: Peter Krempa <pkrempa@xxxxxxxxxx> Date: Wed Jan 4 13:23:31 2017 +0100 qemu: snapshot: Resume VM after live snapshot Commit 4b951d1e38259ff5d03e9eedb65095eead8099e1 missed the fact that the VM needs to be resumed after a live external checkpoint (memory snapshot) where the cpus would be paused by the migration rather than libvirt. commit 6488a6c6e25950980d35fee9adcf63cec6921990 Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Wed Jan 4 14:46:21 2017 +0100 HACKING: Reduce vertical whitespace When generating the plain text version of the contributor guidelines we add a ludicrous amount of vertical whitespace in some spots. Tweak the XSLT stylesheet and regenerate the now much better looking file. commit dd78da09b03a4fb3db69e7405fa177dc39a4936d Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Wed Jan 4 14:24:16 2017 +0100 qemuDomainCreateDevice: Be more careful about device path Again, not something that I'd hit, but there is a chance in theory that this might bite us. Currently the way we decide whether or not to create /dev entry for a device is by marching first four characters of path with "/dev". This might be not enough. Just imagine somebody has a disk image stored under "/devil/path/to/disk". We ought to be matching against "/dev/". Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit ce01a2b11ce88da772923ebcbbfe66f228a7bfee Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Wed Jan 4 14:06:09 2017 +0100 qemuDomainAttachDeviceMknodHelper: Don't unlink() so often Not that I'd encounter any bug here, but the code doesn't look 100% correct. Imagine, somebody is trying to attach a device to a domain, and the device's /dev entry already exists in the qemu namespace. This is handled gracefully and the control continues with setting up ACLs and calling security manager to set up labels. Now, if any of these steps fail, control jump on the 'cleanup' label and unlink() the file straight away. Even when it was not us who created the file in the first place. This can be possibly dangerous. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 3aae99fe71ccee523bafeb54ebd0338eeed66868 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Wed Jan 4 13:57:06 2017 +0100 qemu: Handle EEXIST gracefully in qemuDomainCreateDevice https://bugzilla.redhat.com/show_bug.cgi?id=1406837 Imagine you have a domain configured in such way that you are assigning two PCI devices that fall into the same IOMMU group. With mount namespace enabled what happens is that for the first PCI device corresponding /dev/vfio/X entry is created and when the code tries to do the same for the second mknod() fails as /dev/vfio/X already exists: 2016-12-21 14:40:45.648+0000: 24681: error : qemuProcessReportLogError:1792 : internal error: Process exited prior to exec: libvirt: QEMU Driver error : Failed to make device /var/run/libvirt/qemu/windoze.dev//vfio/22: File exists Worse, by default there are some devices that are created in the namespace regardless of domain configuration (e.g. /dev/null, /dev/urandom, etc.). If one of them is set as backend for some guest device (e.g. rng, chardev, etc.) it's the same story as described above. Weirdly, in attach code this is already handled. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 8388b1c8268d1d8141f85c7b42649f87056d7fa7 Author: Martin Kletzander <mkletzan@xxxxxxxxxx> Date: Wed Dec 28 21:21:03 2016 +0100 networkxml2conftest: Rename outxml to outconf Just a name, I know, but it bothered me a lot since it does not refer to XML. Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> commit 6e0a1663bd0c4252c0e7ab1660461e17b2f702ce Author: Martin Kletzander <mkletzan@xxxxxxxxxx> Date: Wed Dec 14 11:24:40 2016 +0100 docs: Use href_base in absolute links That way all links work even if you click them in a subdirectory. Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> commit d39e3b71ea6436cb5995ff285cc27f0bd1632a6f Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Wed Jan 4 13:53:59 2017 +0100 HACKING: Regenerate When updating the source file in commit bd4f4d168660, I forgot that we also store the generated plain text version in git and didn't regenerate it. I also missed one spot that required an additional <p> tag, so fix both mistakes in one go. commit f0af48f0ddf6bcc9be4f011592b9d3387ccd3af0 Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Wed Jan 4 12:47:01 2017 +0100 util: Fix syntax-check Commit b9cc24839b75 introduced a new #define but neglected to format it properly, thus breaking syntax-check. commit bd4f4d168660f563435968207fc36dad7c8c9e46 Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Wed Jan 4 12:14:13 2017 +0100 docs: Add missing <p> elements Some of the <li> elements in the "General tips for contributing patches" section were missing the corresponding inner <p> element, so they ended up all lumped together. commit b9cc24839b755c47e1a85b267321d1119d2735f2 Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Mon Jan 2 19:15:30 2017 +0100 util: Turn virFirewallAddRule() into a macro Clang 3.9 refuses to compile the existing code with the following error: util/virfirewall.c:425:20: error: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Werror,-Wvarargs] va_start(args, layer); ^ util/virfirewall.c:420:37: note: parameter of type 'virFirewallLayer' is declared here virFirewallLayer layer, ^ This happens because 'layer' is of type virFirewallLayer, which is an enum type and not a standard type such as eg. void* or int. To solve the issue, turn virFirewallAddRule() from a very thin wrapper around virFirewallAddRuleFullV() to a macro that expands to a call to virFirewallAddRuleFull() - itself a very thin wrapper around the aforementioned virFirewallAddRuleFullV() - with no loss of functionality or type safety. commit 7f7d99048350935a394d07b98a13d7da9c4b0502 Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Thu Dec 22 07:12:49 2016 -0500 qemu: Don't assume secret provided for LUKS encryption https://bugzilla.redhat.com/show_bug.cgi?id=1405269 If a secret was not provided for what was determined to be a LUKS encrypted disk (during virStorageFileGetMetadata processing when called from qemuDomainDetermineDiskChain as a result of hotplug attach qemuDomainAttachDeviceDiskLive), then do not attempt to look it up (avoiding a libvirtd crash) and do not alter the format to "luks" when adding the disk; otherwise, the device_add would fail with a message such as: "unable to execute QEMU command 'device_add': Property 'scsi-hd.drive' can't find value 'drive-scsi0-0-0-0'" because of assumptions that when the format=luks that libvirt would have provided the secret to decrypt the volume. Access to unlock the volume will thus be left to the application. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |