[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 141264: regressions - FAIL
flight 141264 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/141264/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 11 guest-start fail REGR. vs. 141241 test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 141241 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 141241 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 141241 test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-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-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-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 e0cb57c552b79016535199021dca5296c0ca89a3 baseline version: libvirt c5f690be75963432d44ac3eb437d5309231db260 Last test of basis 141241 2019-09-12 05:06:26 Z 1 days Testing same since 141264 2019-09-13 04:18:55 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Daniel P. Berrangé <berrange@xxxxxxxxxx> Jiang kun <jiang.kun2@xxxxxxxxxx> Michal Privoznik <mprivozn@xxxxxxxxxx> jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-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-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-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-arm64-arm64-libvirt-qcow2 fail 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 e0cb57c552b79016535199021dca5296c0ca89a3 Author: Daniel P. Berrangé <berrange@xxxxxxxxxx> Date: Thu Sep 12 16:04:20 2019 +0100 conf: correctly convert 'managed' attribute from network port The virNetworkPortDef config stores the 'managed' attribute as the virTristateBool type. The virDomainDef config stores the 'managed' attribute as the bool type. Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit fb0239ff304d8cb1e0e029a8494ae8b1c3f4d8e3 Author: Daniel P. Berrangé <berrange@xxxxxxxxxx> Date: Thu Sep 12 14:21:21 2019 +0100 conf: avoid looking up network port that doesn't exist If the hypervisor driver has not yet created the network port, the portid field will be "00000000-0000-0000-0000-000000000000". If a failure occurs during early VM startup, the hypervisor driver may none the less try to release the network port, resulting in an undesirable warning: 2019-09-12 13:17:42.349+0000: 16544: error : virNetworkObjLookupPort:1679 : network port not found: Network port with UUID 00000000-0000-0000-0000-000000000000 does not exist By checking if the portid UUID is valid, we can avoid polluting the logs in this way. Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit 2e3e942f99f29483c328f5ddafda37782bc2d43e Author: Daniel P. Berrangé <berrange@xxxxxxxxxx> Date: Thu Sep 12 14:12:02 2019 +0100 tools: fix XML validator detection of network port XML schema Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit 5c3def1dc2fc64be4bcee45eea9fc3d0ec998b03 Author: Daniel P. Berrangé <berrange@xxxxxxxxxx> Date: Thu Sep 12 14:06:51 2019 +0100 tools: add virsh docs for network port commands Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit 38816336a5026623d0a49988c6681b1323c79f09 Author: Jiang Kun <jiang.kun2@xxxxxxxxxx> Date: Thu Sep 12 16:05:39 2019 +0800 node_device_conf: Don't leak @physical_function in virNodeDeviceGetPCISRIOVCaps The pci_dev->physical_function is rewritten in virPCIGetPhysicalFunction() to a newly allocated pointer. Therefore, we must free the old one to avoid memleak. Signed-off-by: Jiang kun <jiang.kun2@xxxxxxxxxx> Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 4b3ab5d2135a0dccd654491ef3a4f5b71575deae Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Sat Sep 7 13:11:59 2019 +0200 virt-result.m4: Colourize summary printings The LIBVIRT_RESULT function takes two or three arguments. The first one is the name of the result (aka CHECK_NAME). It is printed before the colon character. The rest of the arguments is printed after the character. To produce colourized output a couple of changes needs to be made. Firstly, we need to print the CHECK_NAME using "echo -n" so that the new line is not appended at the end of the message. To achieve this, AS_MESSAGE_N function is introduced. It's a verbatim copy of AS_MESSAGE (which is just another alias to AC_MSG_NOTICE) except it doesn't put '\n' at the EOL. The alias is defined at /usr/share/autoconf-*/autoconf/general.m4 and the AS_MESSAGE is then defined at /usr/share/autoconf-2.69/m4sugar/m4sh.m4. Secondly, the rest of the arguments are printed colourized and to achieve that and also keep printing them into the log file the _AS_ECHO and COLORIZE_RESULT functions need to be called. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit c98174ce087fe23f567292132e961d4685faf337 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Sat Sep 7 08:58:14 2019 +0200 configure: Colorize output If we're running from a TTY we can put some colors around 'yes', 'no' and other messages. Shamelessly copied from Ruby source code and modified a bit to comply with syntax-check. https://github.com/ruby/ruby/commit/e4879592873abd4cd8aeed56f4cbaa360a3d3736 Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit e9d51a221c1871da246ae8dbc5b5f71191f48be2 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Mon Aug 5 11:29:05 2019 +0200 qemu: Use FW descriptors to report FW image paths Now that we have qemuFirmwareGetSupported() so that it also returns a list of FW image paths, we can use it to report them in domain capabilities instead of the old time default list. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> commit 5a5b8f74d4b8caf18f09a1e1c1d5954edb23dbe8 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Mon Aug 5 16:11:26 2019 +0200 qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> commit 78f8769a84ad2a799cd445f7739b5a0e285e0c8c Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Mon Aug 5 14:56:32 2019 +0200 qemu_firmware: Extend qemuFirmwareGetSupported to return FW paths The qemuFirmwareGetSupported() function is called from qemu driver to generate domain capabilities XML based on FW descriptor files. However, the function currently reports only some features from domcapabilities XML and not actual FW image paths. The paths reported in the domcapabilities XML are still from pre-FW descriptor era and therefore the XML might be a bit confusing. For instance, it may say that secure boot is supported but secboot enabled FW is not in the listed FW image paths. To resolve this problem, change qemuFirmwareGetSupported() so that it also returns a list of FW images (we have the list anyway). Luckily, we already have a structure to represent a FW image - virFirmware. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> commit bc7fe2f56ddd0a50b1e40086c586f3a395b65099 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Mon Aug 5 12:02:50 2019 +0200 qemu_firmware: Document qemuFirmwareGetSupported This function is going to get some new arguments. Document the current ones for clarity. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> commit 48f8aee2ab196db8bfa001e7f0c4a7fe8f2974a6 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Mon Aug 5 11:38:06 2019 +0200 virfirmware: Expose and define autoptr for virFirmwareFree This function frees a _virFirmware struct. So far, it doesn't need to be called from outside of the module, but this will change shortly. In the light of recent VIR_DEFINE_AUTOPTR_FUNC() additions, do the same to virFirmwareFree(). Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> commit 9713aed1abd6566a59ca455592a68b0e054230a5 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Sat Sep 7 13:13:35 2019 +0200 virt-result.m4: Align string more generously The times, when we had small CRTs are long gone. Now, in the era of wide screens we can be more generous when it comes to aligning the output of configure. The longest string before the colon is 'wireshark_dissector' which counts 19 characters. Therefore, align the strings at 20. At the same time, drop the useless result alignment. It behaves oddly - it puts a space at the end of each "no" because of the %-3s format we use. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> commit fe9821959646aae1f0b755f97de4d39fc9bfda32 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Sat Sep 7 12:44:31 2019 +0200 configure: Prefer LIBVIRT_RESULT over AC_MSG_NOTICE One of the advantages is that LIBVIRT_RESULT aligns the resulting message for us. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |