August 2021 - Devel - oVirt List Archives

[VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
by Edward Haas 11 Jan '24

11 Jan '24

Hi, I have a VM which acts as an oVirt host with VDSM installed. I use it for testing without connecting it to Engine. Recently VDSM fails to come up and I see this error: Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+0000: 12176: error : virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired Any hint on how to generate or fetch a new certificate without the help of Engine? Thanks, Edy.

3 5

Error: Adding new Host to ovirt-engine
by Ahmad Khiet 14 Aug '23

14 Aug '23

Hi, Can't add new host to ovirt engine, because the following error: 2019-06-12 12:23:09,664 p=4134 u=engine | TASK [ovirt-host-deploy-facts : Set facts] ************************************* 2019-06-12 12:23:09,684 p=4134 u=engine | ok: [10.35.1.17] => { "ansible_facts": { "ansible_python_interpreter": "/usr/bin/python2", "host_deploy_vdsm_version": "4.40.0" }, "changed": false } 2019-06-12 12:23:09,697 p=4134 u=engine | TASK [ovirt-provider-ovn-driver : Install ovs] ********************************* 2019-06-12 12:23:09,726 p=4134 u=engine | fatal: [10.35.1.17]: FAILED! => {} MSG: The conditional check 'cluster_switch == "ovs" or (ovn_central is defined and ovn_central | ipaddr and ovn_engine_cluster_version is version_compare('4.2', '>='))' failed. The error was: The ipaddr filter requires python's netaddr be installed on the ansible controller The error appears to be in '/home/engine/apps/engine/share/ovirt-engine/playbooks/roles/ovirt-provider-ovn-driver/tasks/configure.yml': line 3, column 5, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - block: - name: Install ovs ^ here 2019-06-12 12:23:09,728 p=4134 u=engine | PLAY RECAP ********************************************************************* 2019-06-12 12:23:09,728 p=4134 u=engine | 10.35.1.17 : ok=3 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 whats missing!? Thanks -- Ahmad Khiet Red Hat <https://www.redhat.com/> akhiet(a)redhat.com M: +972-54-6225629 <https://red.ht/sig>

7 10

[ANN] oVirt 4.4.8 Async update #1
by Sandro Bonazzola 22 Sep '21

22 Sep '21

oVirt 4.4.8 Async update #1 On August 26th 2021 the oVirt project released an async update to the following packages: - ovirt-ansible-collection 1.6.2 - ovirt-engine 4.4.8.5 - ovirt-release44 4.4.8.1 - oVirt Node 4.4.8.1 - oVirt Appliance 4.4-20210826 Fixing the following bugs: - Bug 1947709 <https://bugzilla.redhat.com/show_bug.cgi?id=1947709> - [IPv6] HostedEngineLocal is an isolated libvirt network, breaking upgrades from 4.3 - Bug 1966873 <https://bugzilla.redhat.com/show_bug.cgi?id=1966873> - [RFE] Create Ansible role for remove stale LUNs example remove_mpath_device.yml - Bug 1997663 <https://bugzilla.redhat.com/show_bug.cgi?id=1997663> - Keep cinbderlib dependencies optional for 4.4.8 - Bug 1996816 <https://bugzilla.redhat.com/show_bug.cgi?id=1996816> - Cluster upgrade fails with: 'OAuthException invalid_grant: The provided authorization grant for the auth code has expired. oVirt Node Changes: - Consume above oVirt updates - GlusterFS 8.6: https://docs.gluster.org/en/latest/release-notes/8.6/ - Fixes for: - CVE-2021-22923 <https://access.redhat.com/security/cve/CVE-2021-22923> curl: Metalink download sends credentials - CVE-2021-22922 <https://access.redhat.com/security/cve/CVE-2021-22922> curl: Content not matching hash in Metalink is not being discarded Full diff list: --- ovirt-node-ng-image-4.4.8.manifest-rpm 2021-08-19 07:57:44.081590739 +0200 +++ ovirt-node-ng-image-4.4.8.1.manifest-rpm 2021-08-27 08:11:54.863736688 +0200 @@ -2,7 +2,7 @@ -ModemManager-glib-1.10.8-3.el8.x86_64 -NetworkManager-1.32.6-1.el8.x86_64 -NetworkManager-config-server-1.32.6-1.el8.noarch -NetworkManager-libnm-1.32.6-1.el8.x86_64 -NetworkManager-ovs-1.32.6-1.el8.x86_64 -NetworkManager-team-1.32.6-1.el8.x86_64 -NetworkManager-tui-1.32.6-1.el8.x86_64 +ModemManager-glib-1.10.8-4.el8.x86_64 +NetworkManager-1.32.8-1.el8.x86_64 +NetworkManager-config-server-1.32.8-1.el8.noarch +NetworkManager-libnm-1.32.8-1.el8.x86_64 +NetworkManager-ovs-1.32.8-1.el8.x86_64 +NetworkManager-team-1.32.8-1.el8.x86_64 +NetworkManager-tui-1.32.8-1.el8.x86_64 @@ -94 +94 @@ -curl-7.61.1-18.el8.x86_64 +curl-7.61.1-18.el8_4.1.x86_64 @@ -106,4 +106,4 @@ -device-mapper-1.02.177-5.el8.x86_64 -device-mapper-event-1.02.177-5.el8.x86_64 -device-mapper-event-libs-1.02.177-5.el8.x86_64 -device-mapper-libs-1.02.177-5.el8.x86_64 +device-mapper-1.02.177-6.el8.x86_64 +device-mapper-event-1.02.177-6.el8.x86_64 +device-mapper-event-libs-1.02.177-6.el8.x86_64 +device-mapper-libs-1.02.177-6.el8.x86_64 @@ -140,36 +140,36 @@ -fence-agents-all-4.2.1-74.el8.x86_64 -fence-agents-amt-ws-4.2.1-74.el8.noarch -fence-agents-apc-4.2.1-74.el8.noarch -fence-agents-apc-snmp-4.2.1-74.el8.noarch -fence-agents-bladecenter-4.2.1-74.el8.noarch -fence-agents-brocade-4.2.1-74.el8.noarch -fence-agents-cisco-mds-4.2.1-74.el8.noarch -fence-agents-cisco-ucs-4.2.1-74.el8.noarch -fence-agents-common-4.2.1-74.el8.noarch -fence-agents-compute-4.2.1-74.el8.noarch -fence-agents-drac5-4.2.1-74.el8.noarch -fence-agents-eaton-snmp-4.2.1-74.el8.noarch -fence-agents-emerson-4.2.1-74.el8.noarch -fence-agents-eps-4.2.1-74.el8.noarch -fence-agents-heuristics-ping-4.2.1-74.el8.noarch -fence-agents-hpblade-4.2.1-74.el8.noarch -fence-agents-ibmblade-4.2.1-74.el8.noarch -fence-agents-ifmib-4.2.1-74.el8.noarch -fence-agents-ilo-moonshot-4.2.1-74.el8.noarch -fence-agents-ilo-mp-4.2.1-74.el8.noarch -fence-agents-ilo-ssh-4.2.1-74.el8.noarch -fence-agents-ilo2-4.2.1-74.el8.noarch -fence-agents-intelmodular-4.2.1-74.el8.noarch -fence-agents-ipdu-4.2.1-74.el8.noarch -fence-agents-ipmilan-4.2.1-74.el8.noarch -fence-agents-kdump-4.2.1-74.el8.x86_64 -fence-agents-mpath-4.2.1-74.el8.noarch -fence-agents-redfish-4.2.1-74.el8.x86_64 -fence-agents-rhevm-4.2.1-74.el8.noarch -fence-agents-rsa-4.2.1-74.el8.noarch -fence-agents-rsb-4.2.1-74.el8.noarch -fence-agents-sbd-4.2.1-74.el8.noarch -fence-agents-scsi-4.2.1-74.el8.noarch -fence-agents-vmware-rest-4.2.1-74.el8.noarch -fence-agents-vmware-soap-4.2.1-74.el8.noarch -fence-agents-wti-4.2.1-74.el8.noarch +fence-agents-all-4.2.1-75.el8.x86_64 +fence-agents-amt-ws-4.2.1-75.el8.noarch +fence-agents-apc-4.2.1-75.el8.noarch +fence-agents-apc-snmp-4.2.1-75.el8.noarch +fence-agents-bladecenter-4.2.1-75.el8.noarch +fence-agents-brocade-4.2.1-75.el8.noarch +fence-agents-cisco-mds-4.2.1-75.el8.noarch +fence-agents-cisco-ucs-4.2.1-75.el8.noarch +fence-agents-common-4.2.1-75.el8.noarch +fence-agents-compute-4.2.1-75.el8.noarch +fence-agents-drac5-4.2.1-75.el8.noarch +fence-agents-eaton-snmp-4.2.1-75.el8.noarch +fence-agents-emerson-4.2.1-75.el8.noarch +fence-agents-eps-4.2.1-75.el8.noarch +fence-agents-heuristics-ping-4.2.1-75.el8.noarch +fence-agents-hpblade-4.2.1-75.el8.noarch +fence-agents-ibmblade-4.2.1-75.el8.noarch +fence-agents-ifmib-4.2.1-75.el8.noarch +fence-agents-ilo-moonshot-4.2.1-75.el8.noarch +fence-agents-ilo-mp-4.2.1-75.el8.noarch +fence-agents-ilo-ssh-4.2.1-75.el8.noarch +fence-agents-ilo2-4.2.1-75.el8.noarch +fence-agents-intelmodular-4.2.1-75.el8.noarch +fence-agents-ipdu-4.2.1-75.el8.noarch +fence-agents-ipmilan-4.2.1-75.el8.noarch +fence-agents-kdump-4.2.1-75.el8.x86_64 +fence-agents-mpath-4.2.1-75.el8.noarch +fence-agents-redfish-4.2.1-75.el8.x86_64 +fence-agents-rhevm-4.2.1-75.el8.noarch +fence-agents-rsa-4.2.1-75.el8.noarch +fence-agents-rsb-4.2.1-75.el8.noarch +fence-agents-sbd-4.2.1-75.el8.noarch +fence-agents-scsi-4.2.1-75.el8.noarch +fence-agents-vmware-rest-4.2.1-75.el8.noarch +fence-agents-vmware-soap-4.2.1-75.el8.noarch +fence-agents-wti-4.2.1-75.el8.noarch @@ -215,7 +215,7 @@ -glusterfs-8.5-2.el8.x86_64 -glusterfs-cli-8.5-2.el8.x86_64 -glusterfs-client-xlators-8.5-2.el8.x86_64 -glusterfs-events-8.5-2.el8.x86_64 -glusterfs-fuse-8.5-2.el8.x86_64 -glusterfs-geo-replication-8.5-2.el8.x86_64 -glusterfs-server-8.5-2.el8.x86_64 +glusterfs-8.6-1.el8.x86_64 +glusterfs-cli-8.6-1.el8.x86_64 +glusterfs-client-xlators-8.6-1.el8.x86_64 +glusterfs-events-8.6-1.el8.x86_64 +glusterfs-fuse-8.6-1.el8.x86_64 +glusterfs-geo-replication-8.6-1.el8.x86_64 +glusterfs-server-8.6-1.el8.x86_64 @@ -301,5 +301,5 @@ -kernel-4.18.0-326.el8.x86_64 -kernel-core-4.18.0-326.el8.x86_64 -kernel-modules-4.18.0-326.el8.x86_64 -kernel-tools-4.18.0-326.el8.x86_64 -kernel-tools-libs-4.18.0-326.el8.x86_64 +kernel-4.18.0-331.el8.x86_64 +kernel-core-4.18.0-331.el8.x86_64 +kernel-modules-4.18.0-331.el8.x86_64 +kernel-tools-4.18.0-331.el8.x86_64 +kernel-tools-libs-4.18.0-331.el8.x86_64 @@ -310 +310 @@ -kmod-kvdo-6.2.5.65-79.el8.x86_64 +kmod-kvdo-6.2.5.72-79.el8.x86_64 @@ -363 +363 @@ -libcurl-7.61.1-18.el8.x86_64 +libcurl-7.61.1-18.el8_4.1.x86_64 @@ -381,6 +381,6 @@ -libgfapi0-8.5-2.el8.x86_64 -libgfchangelog0-8.5-2.el8.x86_64 -libgfrpc0-8.5-2.el8.x86_64 -libgfxdr0-8.5-2.el8.x86_64 -libglusterd0-8.5-2.el8.x86_64 -libglusterfs0-8.5-2.el8.x86_64 +libgfapi0-8.6-1.el8.x86_64 +libgfchangelog0-8.6-1.el8.x86_64 +libgfrpc0-8.6-1.el8.x86_64 +libgfxdr0-8.6-1.el8.x86_64 +libglusterd0-8.6-1.el8.x86_64 +libglusterfs0-8.6-1.el8.x86_64 @@ -416 +415,0 @@ -libmetalink-0.1.3-7.el8.x86_64 @@ -558,2 +557,2 @@ -lvm2-2.03.12-5.el8.x86_64 -lvm2-libs-2.03.12-5.el8.x86_64 +lvm2-2.03.12-6.el8.x86_64 +lvm2-libs-2.03.12-6.el8.x86_64 @@ -641 +640 @@ -ovirt-ansible-collection-1.6.0-1.el8.noarch +ovirt-ansible-collection-1.6.2-1.el8.noarch @@ -649 +648 @@ -ovirt-node-ng-image-update-placeholder-4.4.8-1.el8.noarch +ovirt-node-ng-image-update-placeholder-4.4.8.1-1.el8.noarch @@ -657,2 +656,2 @@ -ovirt-release-host-node-4.4.8-1.el8.noarch -ovirt-release44-4.4.8-1.el8.noarch +ovirt-release-host-node-4.4.8.1-1.el8.noarch +ovirt-release44-4.4.8.1-1.el8.noarch @@ -665,3 +664,3 @@ -pacemaker-cluster-libs-2.1.0-5.el8.x86_64 -pacemaker-libs-2.1.0-5.el8.x86_64 -pacemaker-schemas-2.1.0-5.el8.noarch +pacemaker-cluster-libs-2.1.0-6.el8.x86_64 +pacemaker-libs-2.1.0-6.el8.x86_64 +pacemaker-schemas-2.1.0-6.el8.noarch @@ -773 +772 @@ -python3-gluster-8.5-2.el8.x86_64 +python3-gluster-8.6-1.el8.x86_64 @@ -835 +834 @@ -python3-perf-4.18.0-326.el8.x86_64 +python3-perf-4.18.0-331.el8.x86_64 @@ -935,2 +934,2 @@ -selinux-policy-3.14.3-75.el8.noarch -selinux-policy-targeted-3.14.3-75.el8.noarch +selinux-policy-3.14.3-76.el8.noarch +selinux-policy-targeted-3.14.3-76.el8.noarch @@ -941 +940 @@ -shadow-utils-4.6-13.el8.x86_64 +shadow-utils-4.6-14.el8.x86_64 @@ -948 +947 @@ -sos-4.1-4.el8.noarch +sos-4.1-5.el8.noarch -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 1

Python SDK 4.4.15 problems
by francesco＠shellrent.com 27 Aug '21

27 Aug '21

Hi, in a new deployed host (Centos8, oVirt 4.4) with python module ovirt-engine-sdk-python 4.4.15 I was unable to use the Python SDK API. The script hanged in the connection test, with the following strace: .... futex(0x7fc03e47a9e8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1629103636, tv_nsec=938478000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out) futex(0x7fc03e47aa40, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x7fc03e47a9e8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1629103636, tv_nsec=943557000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out) futex(0x7fc03e47aa40, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x7fc03e47a9e8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1629103636, tv_nsec=948631000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out) futex(0x7fc03e47aa40, FUTEX_WAKE_PRIVATE, 1) = 0 ... API via a simple curl worked fine, in another host (still Centos8, oVirt 4.4) with the module version 4.4.14 everything works fine. Downgrading the python module from 4.4.15 to 4.4.14 via pip3 fixed the problem. What could be the problem and it could be related to the recent branches split (I doubt but...). Regards, Francesco

4 3

ovirt-engine has been tagged (ovirt-engine-4.4.8.5)
by Tal Nisan 26 Aug '21

26 Aug '21

2 1

2021-08-23 oVirt 4.4.z branching status update
by Sandro Bonazzola 23 Aug '21

23 Aug '21

A few projects haven't branched yet or haven't configured CI to push the master branch to the ovirt-4.4 pipeline as well. In order to check status: - install CentOS Stream 8 VM # dnf module enable javapackages-tools # dnf module enable postgresql:12 # dnf module disable virt # dnf install https://resources.ovirt.org/pub/yum-repo/ovirt-release44-snapshot.rpm # dnf distro-sync # dnf repoclosure -n --check=ovirt-4.4-snapshot \ --repo=baseos,appstream,extras,ovirt-4.4-centos-ceph-pacific,ovirt-4.4-centos-gluster8,\ ovirt-4.4-centos-opstools,ovirt-4.4-centos-stream-advanced-virtualization,ovirt-4.4-centos-stream-nfv-openvswitch,\ ovirt-4.4-centos-stream-ovirt44,ovirt-4.4-copr:copr.fedorainfracloud.org:sac:gluster-ansible,ovirt-4.4-epel,\ ovirt-4.4-openstack-victoria,ovirt-4.4-snapshot-static,ovirt-4.4-virtio-win-latest,powertools Result: package: ovirt-engine-4.4.9-0.0.master.20210819161534.git14ede44030d.el8.noarch from ovirt-4.4-snapshot unresolved deps: ovirt-ansible-collection >= 1.2.0 ovirt-dependencies >= 4.4.2 ovirt-engine-ui-extensions >= 1.0.4 ovirt-engine-wildfly-overlay >= 23 ovirt-web-ui ovirt-imageio-daemon >= 2.0.10-1 ovirt-provider-ovn >= 1.2.1 ovirt-cockpit-sso package: ovirt-engine-backend-4.4.9-0.0.master.20210819161534.git14ede44030d.el8.noarch from ovirt-4.4-snapshot unresolved deps: java-client-kubevirt >= 0.5.0 ovirt-engine-extensions-api >= 1.0.0 vdsm-jsonrpc-java >= 1.6.0 vdsm-jsonrpc-java < 1.7.0 ovirt-engine-extension-aaa-jdbc >= 1.2.0 package: ovirt-engine-setup-base-4.4.9-0.0.master.20210819161534.git14ede44030d.el8.noarch from ovirt-4.4-snapshot unresolved deps: python3-ovirt-setup-lib >= 1.1.1 I'm looking into ovirt-setup-lib. package: ovirt-engine-setup-plugin-imageio-4.4.9-0.0.master.20210819161534.git14ede44030d.el8.noarch from ovirt-4.4-snapshot unresolved deps: ovirt-imageio-daemon >= 2.0.10-1 package: ovirt-engine-setup-plugin-ovirt-engine-4.4.9-0.0.master.20210819161534.git14ede44030d.el8.noarch from ovirt-4.4-snapshot unresolved deps: ovirt-engine-extension-aaa-jdbc >= 1.2.0 ovirt-engine-dwh-setup >= 4.4.1.2 ovirt-vmconsole >= 1.0.7 ovirt-provider-ovn >= 1.2.1 package: ovirt-engine-tools-4.4.9-0.0.master.20210819161534.git14ede44030d.el8.noarch from ovirt-4.4-snapshot unresolved deps: ovirt-engine-metrics >= 1.3.4.1 package: ovirt-engine-vmconsole-proxy-helper-4.4.9-0.0.master.20210819161534.git14ede44030d.el8.noarch from ovirt-4.4-snapshot unresolved deps: ovirt-vmconsole-proxy package: ovirt-host-4.4.8-1.1.20210817163956.git6573056.el8.x86_64 from ovirt-4.4-snapshot unresolved deps: cockpit-ovirt-dashboard ovirt-provider-ovn-driver package: ovirt-host-4.4.8-1.1.20210817164006.git6573056.el8.ppc64le from ovirt-4.4-snapshot unresolved deps: ovirt-host-dependencies = 4.4.8-1.1.20210817164006.git6573056.el8 package: ovirt-host-dependencies-4.4.8-1.1.20210817163956.git6573056.el8.x86_64 from ovirt-4.4-snapshot unresolved deps: vdsm-client >= 4.40.80 ovirt-imageio-client ovirt-vmconsole-host ovirt-vmconsole vdsm >= 4.40.80 vdsm is being handled by Milan on https://gerrit.ovirt.org/c/vdsm/+/116281 package: ovirt-host-dependencies-4.4.8-1.1.20210817164006.git6573056.el8.ppc64le from ovirt-4.4-snapshot unresolved deps: vdsm-client >= 4.40.80 ovirt-imageio-client ovirt-vmconsole-host ovirt-vmconsole vdsm >= 4.40.80 package: ovirt-hosted-engine-setup-2.5.4-0.0.master.20210820145731.gitbb3f623.el8.noarch from ovirt-4.4-snapshot unresolved deps: ovirt-ansible-collection >= 1.5.4 ovirt-hosted-engine-ha >= 2.4 python3-ovirt-engine-sdk4 >= 4.3.1 python3-ovirt-setup-lib >= 1.3.2 vdsm-python >= 4.40.0 package: ovirt-node-ng-image-update-4.4.8-1.el8.noarch from ovirt-4.4-snapshot unresolved deps: imgbased >= 0.7.2 package: ovirt-release-host-node-4.4.9-0.0.master.20210823132234.git7d863f8.el8.noarch from ovirt-4.4-snapshot unresolved deps: python3-ovirt-engine-sdk4 ovirt-node-ng-nodectl vdsm-gluster imgbased imgbased is being handled at https://gerrit.ovirt.org/c/imgbased/+/116305 -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0

Vdsm: ovirt-4.4.z branch created
by Milan Zamazal 19 Aug '21

19 Aug '21

Hi, similarly to Engine, as announced here today, Vdsm branch ovirt-4.4.z for further 4.4 development was created. Regular development continues on master, with 4.5 as the upcoming release. Bug fixes that should go to 4.4 must be backported from master to ovirt-4.4.z. Regards, Milan

1 0

[IMPORTANT] ovirt-engine-4.4 branch was created, master branch will be used for upcoming oVirt Engine 4.5 version
by Martin Perina 19 Aug '21

19 Aug '21

Hi, Earlier today the ovirt-engine-4.4 branch was created. This branch should be used for fixes for upcoming oVirt Engine 4.4.z release: https://gerrit.ovirt.org/q/project:ovirt-engine+branch:ovirt-engine-4.4 Master branch is going to be used for the upcoming oVirt Engine 4.5 release. This means that any fix for oVirt Engine 4.4.z needs to be merged to master first and only then backported to ovirt-engine-4.4 branch. Also please be aware that database upgrade scripts on master should start with 04_05 prefix, so all patches which are not yet merged on master and contain database upgrade scripts should be updated to 4.5 numbering, for example: https://gerrit.ovirt.org/116267 Thanks, Martin -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

1 0

Re: RHV and oVirt CBT issue
by luwen.zhang 18 Aug '21

18 Aug '21

Thank you so much for the update Pavel! Ok, we will try to check the DB leftovers and will share with you if we find something new. But so far we haven’t seen the same problem again. Best regards! Luwen Zhang ------------------ Original ------------------ From: Pavel Bar <pbar(a)redhat.com> Date: Tue,Aug 17,2021 11:30 PM To: luwen.zhang <luwen.zhang(a)vinchin.com>, huangchuanbo(a)vinchin.com <huangchuanbo(a)vinchin.com> Cc: devel(a)ovirt.org <devel(a)ovirt.org> Subject: Re: [ovirt-devel] Re: RHV and oVirt CBT issue Hi,After investigating the logs I believe that there were few issues that might have caused this unstable behavior. 1) Looks like the DB still contained some leftovers from the already fixed bug which was causing duplicate entries. Even after the date of engine upgrade I still saw some "Duplicate key" errors. I suggest cleaning the DB (if that is possible). 2) Also saw a few other known (and already reported) issues that also might have caused the problem. The issues are going to be fixed in the coming 4.4.9 version, resulting in more stability. I asked our QE team to inform me if they encounter this 'disks stuck in FINALIZING' issue, so I'll be able to try and investigate it locally. But again, this issue might be caused by either some DB leftovers or issues that we are already WIP fixing them. If you opened a bug, please send the link to it here. Thank you in advance. Pavel On Wed, 11 Aug 2021 at 15:24, Pavel Bar <pbar(a)redhat.com> wrote: Hi,Just a short status update FYI. The issue is not forgotten, I'm looking at it. Found in logs a few known issues that are gonna be fixed in the next version, but still not sure that the issue you described will be fixed by them. WIP, will continue updating. Thank you! Pavel On Sun, 1 Aug 2021 at 10:38, Eyal Shenitzky <eshenitz(a)redhat.com> wrote: +Pavel Bar +Benny Zlotnik  On Sun, 1 Aug 2021 at 08:53, luwen.zhang <luwen.zhang(a)vinchin.com> wrote: Sorry I was trying to open a new thread for this issue, but it seems I failed to submit. Here let me explain how the issue is reproduced. It’s a regular backup by using CBT+imageip API, after a series of successful backup, at one of the backup session beginning, when we try to obtain the VM config and the snapshot list (obtain snapshot list can determine the VM virtual disk format is RAW or QCOW2) by using `GET vms/<vm-id>/snapshots`, but get the following error. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault>     <detail>duplicate key acf1edaa-e950-4c4f-94df-1bd6b3da49c1 (attempted merging values org.ovirt.engine.core.common.businessentities.storage.diskimage@5103046c and org.ovirt.engine.core.common.businessentities.storage.diskimage@d973046c)</detail>     <reason>Operation Failed</reason> </fault>  After this, on oVirt engine web console, the VM show 2 disks (actually it only has 1) , and the disk status always showing “Finalizing”, it’s been more than 30 hours now, and during this, cannot modify VM disk or take snapshots. Before upgrading oVirt engine to 4.4.7.7-1.el8 this problem happened frequently, after upgrading, the frequency is reduced. Here I’m adding the engine logs and vdsm logs. Engine logs: https://drive.google.com/file/d/1T3-EOxYYl3oFZOA9VMMBte5WyBoUO48… VDSM logs: https://drive.google.com/file/d/1x0B8lGqnKEDrgn666CuN3hqUGwD7fcY… Thanks & regards! On 07/29/2021 19:20，Nir Soffer<nsoffer(a)redhat.com> wrote： On Thu, Jul 29, 2021 at 10:08 AM luwen.zhang <luwen.zhang(a)vinchin.com> wrote: The problem occurred yesterday, but we waited for more than 20 hours, still 2 disks and in Finalizing state. If the image transfer is "finalizing" it means the image transfer is trying to finalize, but the operation could not complete. In this phase the disk remains locked, and it should not be possible to start a new image transfer (e.g perform another backup). Engine and vdsm logs should explain why the image transfer is stuck in the finalizing phase. Can you add detailed instructions on how to reproduce this issue? _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/V2AEZX2V6JICY… -- Regards, Eyal Shenitzky

1 0

Re: RHV and oVirt CBT issue
by Eyal Shenitzky 17 Aug '21

17 Aug '21

+Pavel Bar <pbar(a)redhat.com> +Benny Zlotnik <bzlotnik(a)redhat.com> On Sun, 1 Aug 2021 at 08:53, luwen.zhang <luwen.zhang(a)vinchin.com> wrote: > > Sorry I was trying to open a new thread for this issue, but it seems I > failed to submit. Here let me explain how the issue is reproduced. > > It’s a regular backup by using CBT+imageip API, after a series of > successful backup, at one of the backup session beginning, when we try to > obtain the VM config and the snapshot list (obtain snapshot list can > determine the VM virtual disk format is RAW or QCOW2) by using `GET > vms/<vm-id>/snapshots`, but get the following error. > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> > > <fault> > > <detail>duplicate key acf1edaa-e950-4c4f-94df-1bd6b3da49c1 (attempted > merging values > org.ovirt.engine.core.common.businessentities.storage.diskimage@5103046c > and org.ovirt.engine.core.common.businessentities.storage.diskimage@d973046c > )</detail> > > <reason>Operation Failed</reason> > </fault> > > After this, on oVirt engine web console, the VM show 2 disks (actually it > only has 1) , and the disk status always showing “Finalizing”, it’s been > more than 30 hours now, and during this, cannot modify VM disk or take > snapshots. > > Before upgrading oVirt engine to 4.4.7.7-1.el8 this problem happened > frequently, after upgrading, the frequency is reduced. > > Here I’m adding the engine logs and vdsm logs. > Engine logs: > https://drive.google.com/file/d/1T3-EOxYYl3oFZOA9VMMBte5WyBoUO48U/view?usp=… > VDSM logs: > https://drive.google.com/file/d/1x0B8lGqnKEDrgn666CuN3hqUGwD7fcYv/view?usp=… > > Thanks & regards! > On 07/29/2021 19:20，Nir Soffer<nsoffer(a)redhat.com> <nsoffer(a)redhat.com> > wrote： > > On Thu, Jul 29, 2021 at 10:08 AM luwen.zhang <luwen.zhang(a)vinchin.com> > wrote: > > The problem occurred yesterday, but we waited for more than 20 hours, > still 2 disks and in Finalizing state. > > > If the image transfer is "finalizing" it means the image transfer is > trying to finalize, but the operation could not complete. > > In this phase the disk remains locked, and it should not be possible > to start a new image transfer > (e.g perform another backup). > > Engine and vdsm logs should explain why the image transfer is stuck in > the finalizing phase. > > Can you add detailed instructions on how to reproduce this issue? > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/V2AEZX2V6JICY… > -- Regards, Eyal Shenitzky

2 2

Vdsm: ovirt-4.4.8 branch created
by Milan Zamazal 16 Aug '21

16 Aug '21

Hi, ovirt-4.4.8 branch has been created for 4.4.8 backports. You can merge 4.4.9 stuff to master now. I'm aware about the current CI problems and that we may need fixes for the new branch. Once the CI problems are resolved we can decide what contingent fixes to apply in ovirt-4.4.8 branch. Regards, Milan

1 0

Vdsm 4.4.8 branch?
by Milan Zamazal 16 Aug '21

16 Aug '21

Hi, we are after code freeze for 4.4.8 now. Can we create a 4.4.8 branch in Vdsm now and start 4.4.9 development on master or does anybody need to postpone the branch? Thanks, Milan

3 2

Inconsistent Jenkins node time zones - use UTC?
by Nir Soffer 13 Aug '21

13 Aug '21

We found a broken test that fail when running on EDT timezone: https://gerrit.ovirt.org/c/vdsm/+/116187 However this test fails randomly. Looking at the run logs, we see that some nodes are using UTC: [2021-08-13T15:04:26.855Z] ## Fri Aug 13 15:04:26 UTC 2021 Running env: el8stream:centos-stream-8-x86_64 But others use EDT: [2021-08-13T16:32:26.866Z] ## Fri Aug 13 12:32:26 PM EDT 2021 Running env: el8stream:centos-stream-8-x86_64 Run logs: - https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_st… - https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_st… Having different time zones on the same system wastes time for everyone. Please use the same timezone on all systems. I think using UTC will make everyone life easier since developers and admins are located on multiple timezones and everyone know what is UTC. Nir

1 0

[VDSM] CI fails in QemuGuestAgentTests.test_pci_devices
by Nir Soffer 12 Aug '21

12 Aug '21

VDSM CI is failing now consistently. Last related change is: https://gerrit.ovirt.org/c/vdsm/+/116090 Build: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/29212//artifact/che… _____________________ QemuGuestAgentTests.test_pci_devices _____________________ self = <virt.qemuguestagent_test.QemuGuestAgentTests testMethod=test_pci_devices> def test_pci_devices(self): devices = self.qga_poller._qga_call_get_devices(self.vm)['pci_devices'] # Ethernet is returned twice by the agent but should appear only # once in the list assert len(devices) == 2 eth = [d for d in devices if d['device_id'] == 4096][0] assert eth == { 'device_id': 4096, 'driver_date': '2019-08-12', 'driver_name': 'Red Hat VirtIO Ethernet Adapter', 'driver_version': '100.80.104.17300', 'vendor_id': 6900, } balloon = [d for d in devices if d['device_id'] == 4098][0] > assert balloon == { 'device_id': 4098, 'driver_date': '2019-08-12', 'driver_name': 'VirtIO Balloon Driver', 'driver_version': '100.80.104.17300', 'vendor_id': 6900, } E AssertionError: assert {'device_id':...4.17300', ...} == {'device_id':...4.17300', ...} E Omitting 4 identical items, use -vv to show E Differing items: E {'driver_date': '2019-08-11'} != {'driver_date': '2019-08-12'} Are we using real time in this test? E Use -v to get the full diff

2 5

Proposing Eyal Shenitsky as ovirt-engine backend maintener
by Benny Zlotnik 11 Aug '21

11 Aug '21

Hi, Eyal has been working on ovirt-engine for a while now and is currently the most prolific active contributor from the storage team. As such, I would like to propose Eyal as an ovirt-engine maintainer

4 3

ovirt-engine has been tagged (ovirt-engine-4.4.8.4)
by Tal Nisan 11 Aug '21

11 Aug '21

2 1

OST HE: Engine VM went down due to cpu load (was: [oVirt Jenkins] ovirt-system-tests_he-basic-suite-master - Build # 2126 - Failure!)
by Yedidyah Bar David 10 Aug '21

10 Aug '21

On Tue, Aug 3, 2021 at 7:50 AM <jenkins(a)jenkins.phx.ovirt.org> wrote: > > Project: https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/ > Build: https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126/ > Build Number: 2126 > Build Status: Failure > Triggered By: Started by timer > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #2126 > [Michal Skrivanek] basic: skipping just the VNC console part of test_virtual_machines > > > > > ----------------- > Failed Tests: > ----------------- > 2 tests failed. > FAILED: he-basic-suite-master.test-scenarios.test_012_local_maintenance_sdk.test_local_maintenance > > Error Message: > ovirtsdk4.Error: Failed to read response: [(<pycurl.Curl object at 0x5555faf11228>, 7, 'Failed to connect to 192.168.200.99 port 443: Connection refused')] This looks very similar to the issue we have with dns/dig failures that cause the engine VM to go down, and it's similar, but different. dig didn't fail (it now uses TCP), but something else caused the agent to stop the engine VM - a combination of high cpu load and low free memory, after restarting the engine VM as part of test_008. https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/2126… : ===================================================================================== MainThread::INFO::2021-08-03 06:46:55,068::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state ReinitializeFSM (score: 0) MainThread::INFO::2021-08-03 06:47:04,089::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:47:04,169::brokerlink::73::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify) Success, was notification of state_transition (ReinitializeFSM-GlobalMaintenance) sent? ignored MainThread::INFO::2021-08-03 06:47:05,249::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 3400) MainThread::INFO::2021-08-03 06:47:14,439::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:47:25,526::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score) Penalizing score by 814 due to cpu load MainThread::INFO::2021-08-03 06:47:25,527::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2586) MainThread::INFO::2021-08-03 06:47:25,537::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:47:26,029::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2586) MainThread::INFO::2021-08-03 06:47:35,050::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:47:35,576::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2586) MainThread::INFO::2021-08-03 06:47:45,597::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:47:46,521::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2586) MainThread::INFO::2021-08-03 06:47:55,577::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:47:56,559::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2586) MainThread::INFO::2021-08-03 06:47:56,559::hosted_engine::525::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Best remote host ost-he-basic-suite-master-host-1 (id: 2, score: 3400) MainThread::INFO::2021-08-03 06:48:05,633::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:48:06,188::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score) Penalizing score by 820 due to cpu load MainThread::INFO::2021-08-03 06:48:06,188::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2580) MainThread::INFO::2021-08-03 06:48:16,256::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:48:16,950::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score) Penalizing score by 831 due to cpu load MainThread::INFO::2021-08-03 06:48:16,951::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2569) MainThread::INFO::2021-08-03 06:48:26,053::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:48:26,999::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score) Penalizing score by 839 due to cpu load MainThread::INFO::2021-08-03 06:48:26,999::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2561) MainThread::INFO::2021-08-03 06:48:36,026::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:48:36,802::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score) Penalizing score by 844 due to cpu load MainThread::INFO::2021-08-03 06:48:36,802::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2556) MainThread::INFO::2021-08-03 06:48:45,827::state_decorators::51::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Global maintenance detected MainThread::INFO::2021-08-03 06:48:46,401::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score) Penalizing score by 849 due to cpu load MainThread::INFO::2021-08-03 06:48:46,401::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state GlobalMaintenance (score: 2551) MainThread::INFO::2021-08-03 06:48:56,588::brokerlink::73::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify) Success, was notification of state_transition (GlobalMaintenance-ReinitializeFSM) sent? ignored MainThread::INFO::2021-08-03 06:48:58,685::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state ReinitializeFSM (score: 0) MainThread::INFO::2021-08-03 06:49:05,729::brokerlink::73::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify) Success, was notification of state_transition (ReinitializeFSM-EngineStarting) sent? ignored MainThread::INFO::2021-08-03 06:49:06,146::states::176::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score) Penalizing score by 830 due to cpu load MainThread::INFO::2021-08-03 06:49:06,146::states::72::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_penalize_memory) Penalizing score by 400 due to free memory 1782 being lower than required 3171 MainThread::INFO::2021-08-03 06:49:06,146::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state EngineStarting (score: 2170) MainThread::INFO::2021-08-03 06:49:06,150::state_decorators::95::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check) Timeout cleared while transitioning <class 'ovirt_hosted_engine_ha.agent.states.EngineStarting'> -> <class 'ovirt_hosted_engine_ha.agent.states.EngineUp'> MainThread::INFO::2021-08-03 06:49:06,172::brokerlink::73::ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(notify) Success, was notification of state_transition (EngineStarting-EngineUp) sent? ignored MainThread::INFO::2021-08-03 06:49:06,178::hosted_engine::517::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_monitoring_loop) Current state EngineUp (score: 2570) MainThread::ERROR::2021-08-03 06:49:16,197::states::398::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(consume) Host ost-he-basic-suite-master-host-1 (id 2) score is significantly better than local score, shutting down VM on this host ===================================================================================== I looked a bit at /var/log/messages of the host, and while there is quite some noise there, can't tell specifically what might have caused the high cpu load. Also looked at logs of previous runs, and there is indeed a similar pattern, where the cpuload on the host causes the agent to penalize the score, but according to the agent log the load goes down faster, up to the point of being quite low when the engine is up, and only then we exit global maintenance, allowing the agent to take actions. I now ran it again, but think that otherwise I'll ignore this for now, unless we see more similar failures. If we do, we might want to check/monitor/log the cpu load on the hosts, and/or change test_008 to wait, after the engine is up, until the cpu load on the host goes down a bit. Before the port to pytest we waited a hard-coded 5 minutes and I changed that then to only wait until the engine VM is not migrating, and this worked more-or-less ok. We might need to refine that, although I'd rather not introduce another arbitrary long delays but wait for some condition. I also noticed that this ran was started at "03:04 AM" (UTC), by timer, whereas all previous timer-based runs started at 01:55 AM, somewhat earlier - perhaps there are some other things that run at that time that cause load. Best regards, -- Didi

4 10

ovirt-engine-sdk repository changes
by Martin Necas 09 Aug '21

09 Aug '21

Hi, just bit summary of few changes in ovirt-engine-sdk repo [1]. There was the decision to split the SDK generator and the python SDK itself. So we created a new repository on GitHub called python-ovirt-engine-sdk4 [2]. We switched from Travis CI to GitHub Actions, because Travis no longer supported .org domain where we had our tests. The GitHub Actions automatically builds the SDK and pushes it to the new repo similar to the Go SDK. There were some issues with the documentation generator [3] so we switched to the new version of pdoc [4]. We migrated the SDK examples because the examples have nothing to do with the generator itself moved it to the new repository [6]. Martin Necas [1] https://github.com/ovirt/ovirt-engine-sdk [2] https://github.com/ovirt/python-ovirt-engine-sdk4 [3] http://ovirt.github.io/ovirt-engine-sdk/master/ [4] https://pdoc.dev/docs/pdoc.html [5] https://gerrit.ovirt.org/#/c/ovirt-engine-sdk/+/116066/ [6] https://github.com/oVirt/python-ovirt-engine-sdk4/tree/main/examples

3 2

Migration without shared storage is unsafe (was: Change in ovirt-system-tests[master]: HE: Use node image)
by Yedidyah Bar David 09 Aug '21

09 Aug '21

On Sun, Aug 8, 2021 at 5:42 PM Code Review <gerrit(a)ovirt.org> wrote: > > From Jenkins CI <jenkins(a)ovirt.org>: > > Jenkins CI has posted comments on this change. ( https://gerrit.ovirt.org/c/ovirt-system-tests/+/115392 ) > > Change subject: HE: Use node image > ...................................................................... > > > Patch Set 13: Continuous-Integration-1 > > Build Failed While trying to deactivate a host, the engine wanted to migrate a VM (vm0) from host-0 to host-1. vdsm log of host-0 says: 2021-08-08 14:31:10,076+0000 ERROR (migsrc/cde311f9) [virt.vm] (vmId='cde311f9-9a33-4eb9-8338-fa22ff49edc2') Failed to migrate (migration:503) Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line 477, in _regular_run time.time(), machineParams File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line 578, in _startUnderlyingMigration self._perform_with_conv_schedule(duri, muri) File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line 667, in _perform_with_conv_schedule self._perform_migration(duri, muri) File "/usr/lib/python3.6/site-packages/vdsm/virt/migration.py", line 596, in _perform_migration self._migration_flags) File "/usr/lib/python3.6/site-packages/vdsm/virt/virdomain.py", line 159, in call return getattr(self._vm._dom, name)(*a, **kw) File "/usr/lib/python3.6/site-packages/vdsm/virt/virdomain.py", line 101, in f ret = attr(*args, **kwargs) File "/usr/lib/python3.6/site-packages/vdsm/common/libvirtconnection.py", line 131, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python3.6/site-packages/vdsm/common/function.py", line 94, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python3.6/site-packages/libvirt.py", line 2126, in migrateToURI3 raise libvirtError('virDomainMigrateToURI3() failed') libvirt.libvirtError: Unsafe migration: Migration without shared storage is unsafe Any idea? -- Didi

2 6

Failing to build ovn2.11 / openvswitch2.11 for el9
by Sandro Bonazzola 06 Aug '21

06 Aug '21

Hi, I'm trying to rebuild laters ovn rpm from centos build system for el8s to copr for el9s. It fails for me here: sed -f ./build-aux/extract-odp-netlink-h < datapath/linux/compat/include/linux/openvswitch.h > include/odp-netlink.h sh -f ./build-aux/extract-odp-netlink-macros-h include/odp-netlink.h > include/odp-netlink-macros.h PYTHONPATH=./python":"$PYTHONPATH PYTHONDONTWRITEBYTECODE=yes /usr/bin/python3 ./ovsdb/ovsdb-idlc.in annotate ./vswitchd/vswitch.ovsschema ./lib/vswitch-idl.ann > lib/vswitch-idl.ovsidl.tmp && mv lib/vswitch-idl.ovsidl.tmp lib/vswitch-idl.ovsidl PYTHONPATH=./python":"$PYTHONPATH PYTHONDONTWRITEBYTECODE=yes /usr/bin/python3 ./ovsdb/ovsdb-idlc.in c-idl-source lib/vswitch-idl.ovsidl > lib/vswitch-idl.c.tmp && mv lib/vswitch-idl.c.tmp lib/vswitch-idl.c Traceback (most recent call last): File "/builddir/build/BUILD/ovn2.11-2.11.1/./ovsdb/ovsdb-idlc.in", line 1581, in <module> func(*args[1:]) File "/builddir/build/BUILD/ovn2.11-2.11.1/./ovsdb/ovsdb-idlc.in", line 442, in printCIDLSource replace_cplusplus_keyword(schema) File "/builddir/build/BUILD/ovn2.11-2.11.1/./ovsdb/ovsdb-idlc.in", line 179, in replace_cplusplus_keyword for columnName in table.columns: RuntimeError: dictionary keys changed during iteration make: *** [Makefile:8534: lib/vswitch-idl.c] Error 1 similar for openvswitch2.11 (this still with parallel make with -j2): Traceback (most recent call last): File "/builddir/build/BUILD/ovs-2.11.3/build-shared/../ovsdb/ovsdb-idlc.in", line 1597, in <module> func(*args[1:]) File "/builddir/build/BUILD/ovs-2.11.3/build-shared/../ovsdb/ovsdb-idlc.in", line 458, in printCIDLSource replace_cplusplus_keyword(schema) File "/builddir/build/BUILD/ovs-2.11.3/build-shared/../ovsdb/ovsdb-idlc.in", line 179, in replace_cplusplus_keyword for columnName in table.columns: RuntimeError: dictionary keys changed during iteration make: *** [Makefile:8383: lib/vswitch-idl.c] Error 1 make: *** Waiting for unfinished jobs.... Traceback (most recent call last): File "/builddir/build/BUILD/ovs-2.11.3/build-shared/../ovsdb/ovsdb-idlc.in", line 1597, in <module> func(*args[1:]) File "/builddir/build/BUILD/ovs-2.11.3/build-shared/../ovsdb/ovsdb-idlc.in", line 185, in printCIDLHeader replace_cplusplus_keyword(schema) File "/builddir/build/BUILD/ovs-2.11.3/build-shared/../ovsdb/ovsdb-idlc.in", line 179, in replace_cplusplus_keyword for columnName in table.columns: RuntimeError: dictionary keys changed during iteration make: *** [Makefile:8385: lib/vswitch-idl.h] Error 1 I thought it could have been due to parallel make so I forced make to run with -j1 but without changing the result. Any clue on how to get the build working? Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

3 5

glance.ovirt.org planned outage: 10.08.2021 at 01:00 UTC
by Evgheni Dereveanchin 06 Aug '21

06 Aug '21

Hi everyone, There's an outage scheduled in order to move glance.ovirt.org to new hardware. This will happen after midnight the upcoming Tuesday between 1AM and 3AM UTC. It will not be possible to pull images from our Glance image registry during this period. Other services will not be affected. If you see any CI jobs failing on Glance tests - please re-run them in the morning after the planned outage window is over. If issues persist please report it via JIRA or reach out to me personally. -- Regards, Evgheni Dereveanchin

1 0

OST: How to run ost.sh with a local custom repo?
by Milan Zamazal 05 Aug '21

05 Aug '21

Hi, when I try to run ost.sh on a local repo with --custom-repo=file:///home/pdm/rpmbuild/repodata/repomd.xml, I get the following error: requests.exceptions.InvalidSchema: No connection adapters were found for 'file:///home/pdm/rpmbuild/repodata/repomd.xml I tried using file:/home/... and /home/... but neither works. https://... works fine. How can I run the script with a custom repo in a local directory? Thanks, Milan

3 4

ovirt-engine has been tagged (ovirt-engine-4.4.8.3)
by Martin Perina 05 Aug '21

05 Aug '21

2 6

lago is dead, long live ost!
by Michal Skrivanek 04 Aug '21

04 Aug '21

Hi, we worked for a while on removing our dependency on lago that has been more or less abandoned for a long time now. We got to the minimal feature set that is simple to replace with bunch of virsh commands, and most of the advanced logic is implemented in pytest. We’ve just merged the last patches that freed us up from lago for local and beaker CI runs. There’s a new ost.sh wrapper for the simple operations of running the suite, inspecting the environment and shutting it down. Hopefully it’s self explanatory…. ./ost.sh command [arguments] run <suite> <distro> [<pytest args>...] initializes the workspace with preinstalled distro ost-images, launches VMs and runs the whole suite add extra repos with --custom-repo=url skip check that extra repo is actually used with --skip-custom-repos-check status show environment status, VM details shell <host> [command ...] opens ssh connection console <host> opens virsh console destroy stop and remove the running environment Right now lago and run_suite.sh still works and it is still used by the mock-based jenkins.ovirt.org runs. It will go away in future. Thanks, michal

3 3