Back to bug 1029035

Who When What Removed Added
Michal Skrivanek 2013-11-12 11:28:23 UTC Depends On 1026811
Link ID oVirt gerrit 21049
Link ID RHEV gerrit 10270
Status NEW MODIFIED
errata-xmlrpc 2013-11-26 08:46:48 UTC Status MODIFIED ON_QA
Charlie 2013-11-28 00:42:55 UTC CC rgolan
Flags needinfo?(rgolan)
Pavel Novotny 2013-11-28 14:24:54 UTC Status ON_QA ASSIGNED
Omer Frenkel 2013-12-02 14:03:36 UTC Status ASSIGNED ON_QA
CC ofrenkel
Pavel Novotny 2013-12-02 15:59:04 UTC Status ON_QA VERIFIED
Charlie 2013-12-04 04:25:12 UTC CC cboyle
Doc Text The problem was seen as a host htpervisor went into non-responding mode. A VM that was running on it stopped responding and spice didn't work to access that VM's console. While trying to stop/reboot the problematic host, the VM appeared on 2 different hosts (via UI and on virsh command line). Eventually this caused the FS on that VM to become corrupted, which resulted in having to reinstall that VM. This was caused by the fence command running at the same time. This fix runs fence command mutually exclusive.
errata-xmlrpc 2013-12-17 00:02:31 UTC Status VERIFIED RELEASE_PENDING
errata-xmlrpc 2013-12-18 14:10:37 UTC Status RELEASE_PENDING CLOSED
Resolution --- ERRATA
Last Closed 2013-12-18 09:10:37 UTC
Roy Golan 2014-02-09 12:01:36 UTC Doc Text The problem was seen as a host htpervisor went into non-responding mode. A VM that was running on it stopped responding and spice didn't work to access that VM's console. While trying to stop/reboot the problematic host, the VM appeared on 2 different hosts (via UI and on virsh command line). Eventually this caused the FS on that VM to become corrupted, which resulted in having to reinstall that VM. This was caused by the fence command running at the same time. This fix runs fence command mutually exclusive. The problem was seen as a host htpervisor went into non-responding mode. A VM that was running on it stopped responding and spice didn't work to access that VM's console. While trying to stop/reboot the problematic host, the VM appeared on 2 different hosts (via UI and on virsh command line). Eventually this caused the FS on that VM to become corrupted, which resulted in having to reinstall that VM. This was caused by the fence command running at the same time. This fix runs fence command mutually exclusive.

* Cause: a race between 2 Fence operation, one triggered by UI and one automatically
* Consequence: the end of the fence command is to start VMs up, since the race exist the process starts VMs without knowing it started already
* Fix: make fence operations exclusive by taking an engine-lock
* Result: now the 2nd fence operation should fail with Can Do Action since one is already in progress
Flags needinfo?(rgolan)

Back to bug 1029035