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

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.

9 months, 2 weeks

3
5
0 / 0

Error: Adding new Host to ovirt-engine

by Ahmad Khiet

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>

1 year, 2 months

7
10
0 / 0

[ANN] oVirt 4.4.8 Async update #1

by Sandro Bonazzola

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.*

3 years, 1 month

2
1
0 / 0

Python SDK 4.4.15 problems

by francesco＠shellrent.com

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

3 years, 2 months

4
3
0 / 0

ovirt-engine has been tagged (ovirt-engine-4.4.8.5)

by Tal Nisan

3 years, 2 months

2
1
0 / 0

2021-08-23 oVirt 4.4.z branching status update

by Sandro Bonazzola

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.*

3 years, 2 months

1
0
0 / 0

Vdsm: ovirt-4.4.z branch created

by Milan Zamazal

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

3 years, 2 months

1
0
0 / 0

[IMPORTANT] ovirt-engine-4.4 branch was created, master branch will be used for upcoming oVirt Engine 4.5 version

by Martin Perina

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.

3 years, 2 months

1
0
0 / 0

Re: RHV and oVirt CBT issue

by luwen.zhang

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-EOxYYl3oFZOA9VMMBte5WyBoUO... VDSM logs: https://drive.google.com/file/d/1x0B8lGqnKEDrgn666CuN3hqUGwD7f... 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/V2AEZX2V6JI... -- Regards, Eyal Shenitzky

3 years, 2 months

1
0
0 / 0

Re: RHV and oVirt CBT issue

by Eyal Shenitzky

+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?us... > VDSM logs: > https://drive.google.com/file/d/1x0B8lGqnKEDrgn666CuN3hqUGwD7fcYv/view?us... > > 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/V2AEZX2V6JI... > -- Regards, Eyal Shenitzky

3 years, 2 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Devel August 2021