|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 136480: regressions - FAIL
flight 136480 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/136480/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 136321 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 136321 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 136321 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 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 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 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 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 6d3ac4f722dbbf8062afdbc1f47a26f9e59afc10 baseline version: libvirt 91268c715cf0293f0751de0450e4d0c06bea18d8 Last test of basis 136321 2019-05-15 19:38:41 Z 4 days Testing same since 136480 2019-05-18 05:10:51 Z 2 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani <abologna@xxxxxxxxxx> Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Daniel P. Berrangé <berrange@xxxxxxxxxx> Ján Tomko <jtomko@xxxxxxxxxx> Michal Privoznik <mprivozn@xxxxxxxxxx> Peter Krempa <pkrempa@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 fail 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 pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-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 6d3ac4f722dbbf8062afdbc1f47a26f9e59afc10 Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Mon May 13 14:48:45 2019 +0200 examples: Fix installation on Windows We can't rely on $(noinst_PROGRAMS) retaining its original value, so let's use a separate $(EXAMPLES) variable instead. Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit 5cdd5d380bab5f6f7207e0ffd0c1322a8281feca Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Tue Apr 30 11:17:22 2019 +0200 lib: Avoid double close when passing FDs with virCommandPassFD() If an FD is passed into a child using: virCommandPassFD(cmd, fd, VIR_COMMAND_PASS_FD_CLOSE_PARENT); then the parent should refrain from touching @fd thereafter. This is even documented in virCommandPassFD() comment. The reason is that either at virCommandRun()/virCommandRunAsync() or virCommandFree() time the @fd will be closed. Closing it earlier, e.g. right after virCommandPassFD() call might result in undesired results. Another thread might open a file and receive the same FD which is then unexpectedly closed by virCommandFree() or virCommandRun(). Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx> commit e5df4edefa6b6b9db2ef620a1f16a901afda0274 Author: Daniel P. Berrangé <berrange@xxxxxxxxxx> Date: Thu May 16 09:27:45 2019 +0100 src: don't statically link code that's already in libvirt.so Various binaries are statically linking to libvirt_util.la and other intermediate libraries we build. These intermediate libs all get built into the main libvirt.so shared library eventually, so we can dynamically link to that instead and reduce the on disk footprint. In libvirt-daemon RPM: virtlockd: 1.6 MB -> 153 KB virtlogd: 1.6 MB -> 157 KB libvirt_iohelper: 937 KB -> 23 KB In libvirt-daemon-driver-network RPM: libvirt_leaseshelper: 940 KB -> 26 KB In libvirt-daemon-driver-storage-core RPM: libvirt_parthelper: 926 KB -> 21 KB IOW, about 5.6 MB total space saving in a build done on Fedora 30 x86_64 architecture. Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx> Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit 3c8d5762a9fcf3f7d23a41d0b49def0387ecddf7 Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Fri May 17 11:10:09 2019 +0200 m4: Drop needless string checks We provide default values for both MODPROBE and RMMOD and thus there is no way that their paths can be empty strings. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx> commit 523b799d3c356b9b4ea0b117a60cfc3b603eaffa Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Fri May 17 11:09:45 2019 +0200 m4: Provide default value fore UDEVADM https://bugzilla.redhat.com/show_bug.cgi?id=1710575 It may happen that the system where libvirt is built at doesn't have udevadm binary but the one where it runs does have it. If we change how udevadm is run in virWaitForDevices() then we can safely pass a default value in m4 macro. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx> commit 2944dcb2de014a881c3539a43f989c2a723e87ca Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Fri May 17 11:01:49 2019 +0200 lib: Drop UDEVSETTLE The udevsettle binary is no longer used anywhere as it was replaced by 'udevadm settle'. There's no reason for us to even check for it in configure. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx> commit 0cabcd98f1ef82588016a692afbe5a47a4a0b42e Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Fri May 17 11:10:27 2019 +0200 virWaitForDevices: Drop confusing part of comment It's not true that there is a backup loop. There isn't. Drop this part of the comment to not confuse anybody. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx> commit a251095e131bdc5f1e10f3fd778b318f242bde51 Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Thu May 16 12:04:48 2019 +0200 qemu: Only probe available machine types Since we know the full list of machine types supported by the QEMU binary when probing machine type properties, we can save some work (and eventually test suite churn, as more architecture-specific machine types need to be probed) by only probing machines that we know exist. Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit 35e4c153261e0ecc79f98cb778dfdb599e5b8cae Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Thu May 16 16:29:53 2019 +0200 tests: Refresh capabilities for QEMU on ppc64 Now that we're probing machine type properties using the latest machine type rather than the "spapr-machine" parent, we can finally discover properties that are not available on all machine types. This commit refreshes replies for QEMU 4.0.0 as well as 3.1.0 to show not only that we're actually discovering new machine type properties this way, but also that the number of available machine type properties increases with each subsequent QEMU release. If qom-list-properties had been available in QEMU 2.10.0, we could now drop the explicit version number checks for the QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT and QEMU_CAPS_MACHINE_PSERIES_RESIZE_HPT capabilities, but unfortunately it wasn't, so we have to keep them around still. Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit d22c6221fc569c5119f3fc7f42d913f00759f6bf Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Thu May 16 10:34:01 2019 +0200 qemu: Probe canonicalized machine type Now that we have the list of machine types available when probing machine type properties, we can list properties for the canonicalized version of the "pseries" machine type instead of having to go through "spapr-machine", which we know to be the parent type for all "pseries-*-machine" types. By doing this, we'll be able to find even properties that are only available from a certain versioned machine type forward, and can't thus be obtained when looking at the parent type only. Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit f3f9d8e37662f67a0f611c697ab6b359b9adb252 Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Thu May 16 10:18:58 2019 +0200 qemu: Add -machine suffix automatically The QOM type for machine types is the machine type name followed by the -machine suffix. Since this is always the case, we can make virQEMUCapsMachineProps more readable and avoid repetition by not including the suffix there and adding it automatically while processing the data; moreover, when later on we will start figuring out which specific versioned machine type to probe at runtime instead of doing so statically, adding the suffix dynamically will become necessary. Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit 295a42e19ff1adb9b845d479cff0963d0c232863 Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Thu May 16 15:46:58 2019 +0200 qemu: Move call to virQEMUCapsProbeQMPMachineProps() We're going to need information about available machine types when probing machine type properties soon, and that means we have to change the order we call QMP commands. Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit 4ad8d620ccbcfed9c392d4cef1042b87be5e29e3 Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Thu May 16 15:45:08 2019 +0200 qemu: Introduce virQEMUCapsProbeQMPMachineProps() Up until now we've probed machine type properties, along with properties for other types, in virQEMUCapsProbeQMPDevices(), but soon we're going to need some logic that is specific to machine types and as such wouldn't quite fit into that function. Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit 4d8cc5a07a0dcc0ac99377f66a4649d219705452 Author: Peter Krempa <pkrempa@xxxxxxxxxx> Date: Fri May 17 10:15:53 2019 +0200 qemu: blockjob: Fix saving of inactive XML after completed legacy blockjob Commit c257352797 introduced a logic bug where we will never save the inactive XML after a blockjob as the variable which was determining whether to do so is cleared right before. Thus even if we correctly modify the inactive state it will be rolled back when libvirtd is restarted. Reported-by: Thomas Stein <hello@xxxxxxxxx> Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx> Reviewed-by: Ján Tomko <jtomko@xxxxxxxxxx> commit 02de59ccb6e83fa9d3b9437c61bb889821709ef4 Author: Ján Tomko <jtomko@xxxxxxxxxx> Date: Mon May 13 16:22:40 2019 +0200 build: drop check for udev_monitor_set_receive_buffer_size It has been exported by systemd commit commit a571c23e954cb88cdd5faa28593b19bd7c340130 libudev: export udev_monitor_set_receive_buffer_size() released in v183. Signed-off-by: Ján Tomko <jtomko@xxxxxxxxxx> Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit 385d4b851f4a21def77bee7fb5e1c0ca97438a92 Author: Ján Tomko <jtomko@xxxxxxxxxx> Date: Mon May 13 16:17:46 2019 +0200 build: bump minimum udev version to 219 This is the version of systemd RHEL/CentOS 7 uses: https://repology.org/project/systemd/versions Oldest tracked openSUSE distros have 228, Ubuntu 16.04 has 229 and Gentoo's alternative eudev has bumped the version to 219 back in 2015. Signed-off-by: Ján Tomko <jtomko@xxxxxxxxxx> Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit 0541b65464a2047fca6c0ab83e4d693ba0cc41a2 Author: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Date: Wed May 15 13:35:32 2019 +0200 virt-aa-helper: allow sysfs path used for vhost-scsi When a vhost scsi device is hotplugged virt-aa-helper is called to add the respective path. For example the config: <hostdev mode='subsystem' type='scsi_host' managed='no'> <source protocol='vhost' wwpn='naa.50014059de6fba4f'/> </hostdev> Will call it to add: /sys/kernel/config/target/vhost//naa.50014059de6fba4f But in general /sys paths are filtered in virt-aa-helper.c:valid_path To allow the path used for vhost-scsi we need to add it to the list of known and accepted overrides. Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1829223 Signed-off-by: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Reviewed-by: Daniel P. Berrangé <berrange@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 |