Bug 1528950

Summary: [downstream clone - 4.1.9] Editing VM properties task hangs forever. The only way out is remove job_id from postgres and engine restart
Product: Red Hat Enterprise Virtualization Manager Reporter: rhev-integ
Component: ovirt-engineAssignee: Eyal Shenitzky <eshenitz>
Status: CLOSED ERRATA QA Contact: Yosi Ben Shimon <ybenshim>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.1.0CC: amureini, bugs, lsurette, lveyde, pagranat, pstehlik, ratamir, rbalakri, Rhev-m-bugs, srevivo, tjelinek, tnisan, ykaul, ylavi
Target Milestone: ovirt-4.1.9Keywords: ZStream
Target Release: ---Flags: lsvaty: testing_plan_complete-
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: ovirt-engine-4.1.9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1516907 Environment:
Last Closed: 2018-01-24 14:43:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1516907    
Bug Blocks:    

Description rhev-integ 2017-12-25 09:53:22 UTC
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1516907 +++
======================================================================

+++ This bug was initially created as a clone of Bug #1492473 +++

Description of problem:
Setting of High Availability properties cause Tasks window to hang up

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.create VM, run , open 'High Available' tab, check High Availability box and choose nfs_2 from drop down list, ok brings a message that VM must be restarted.
2.poweroff the VM. Open the 'High Available' again. change the nfs_2 to nfs_1. ok
3.run VM 

Actual results:
In tasks tab (right upper corner)  you see the 'Editing VM properties' task in  'Finalizing' state which just hangs up and never ends. the only way is remove job_id from job table of postgres , and then restart engine

Expected results:
VM is started with new High Available settings

Additional info:
sometimes you have to repeate the scenario (open High Availability tab/run VM) twice to reproduce

--- Additional comment from Polina on 2017-09-17 11:38 EDT ---



--- Additional comment from Tomas Jelinek on 2017-09-18 02:39:37 EDT ---

please always attach engine and vdsm logs to bug reports

--- Additional comment from Polina on 2017-10-02 10:11 EDT ---



--- Additional comment from Tomas Jelinek on 2017-10-06 07:01:57 EDT ---

There are simpler steps to reproduce:
- create VM
- edit VM and set it as HA with lease on SD1
- save
- (quickly) edit again and change the lease to SD2

The problem looks like a regression from https://gerrit.ovirt.org/#/c/72120/
Before that patch, the vm lease commands were sync so the VM was locked while running this commands.

Since that patch the lease commands are async and take a while to run, but the VM is for some reason not locked. And since the VM is not locked, it is possible to run an another edit (even of the lease) on it. This race causes the jobs not being finished properly.

Moving to storage for further investigation.

--- Additional comment from Polina on 2017-11-21 03:49:10 EST ---

the negative effect of the bug even worse, since after this the leases in HA tab disappear. impossible to choose HA lease.

(Originally by Gajanan Chakkarwar)

Comment 2 Yosi Ben Shimon 2018-01-22 13:19:11 UTC
Tested according to this scenario:
- create VM
- edit VM and set it as HA with lease on SD1
- save
- (quickly) edit again and change the lease to SD2

and the actual result is that i get the message: "Cannot edit VM. VM is being updated." and no additional task is added and/or left to be hang.

Tested on:
ovirt-engine-4.1.9.1-0.1.el7.noarch

Moving to VERIFIED

Comment 5 errata-xmlrpc 2018-01-24 14:43:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0135

Comment 6 Franta Kust 2019-05-16 12:55:06 UTC
BZ<2>Jira re-sync

Comment 7 Daniel Gur 2019-08-28 13:14:14 UTC
sync2jira

Comment 8 Daniel Gur 2019-08-28 13:18:31 UTC
sync2jira