Description of problem: from time to time we fail on timeout of "Check OVF_STORE volume status" task Version-Release number of selected component (if applicable): ovirt-hosted-engine-setup-2.6.3-1.el8ev.noarch 4.5.0.10 How reproducible: from time to time Steps to Reproduce: 1. Run the deployment of the hosted engine with restore from file flow or regular flow. Actual results: failed because the task "Check OVF_STORE volume status" reach his timeout and the "description['Updated']" still false as you can see: 00:01:41 FAILED - RETRYING: Check OVF_STORE volume status (1 retries left). 00:01:52 failed: [host1.com] (item={'name': 'OVF_STORE', 'image_id': ..., "stdout": "{\n \"apparentsize\": \"134217728\",\n \"capacity\": \"134217728\",\n \"children\": [],\n \"ctime\": \"1653425433\",\n \"description\": \"{\\\"Updated\\\":false,\\\"Last Updated\\\":null,\\\"Storage Domains\\\":[{\\\"uuid\\\":\\\... Expected results: To increase the timeout to make sure we are not failing because of it from time to time Additional info: I remember we saw this issue in the past and we considered this PR: https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/pull/336 which I copied in: https://github.com/oVirt/ovirt-ansible-collection/pull/190
related old bug: https://bugzilla.redhat.com/show_bug.cgi?id=1781102
since it seems related to other hosts restored from backup I doubt it happens on clean install.
errors seem to be cause by bug 1785061 which is still unfixed in 4.3. Please confirm this problem on a setup with either vdsm-4.30.53 or 4.40+
(In reply to Michal Skrivanek from comment #6) > errors seem to be cause by bug 1785061 which is still unfixed in 4.3. > Please confirm this problem on a setup with either vdsm-4.30.53 or 4.40+ I rebuild the same environment with 4.3 and I can see we have in the host: vdsm-4.30.52-1.el7ev.x86_64 if you want someone to look at this environment I keep it locked for a while :)
there's no need to look at a setup with 4.30.52, if it's not happening with 4.30.53 or 4.4 then we can close this as duplicate of 1785061
as Michal suggested mark it as duplicate *** This bug has been marked as a duplicate of bug 1785061 ***
I do not see that anything changed, it's still the same duplicate. please reopen only if you see this issue in an environment consisting only of hosts running that or newer builds. *** This bug has been marked as a duplicate of bug 1785061 ***