Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1150076

Summary: When ovirt-ha-broker down, agent try to start vm on second host and failed with error
Product: Red Hat Enterprise Virtualization Manager Reporter: Artyom <alukiano>
Component: ovirt-hosted-engine-haAssignee: Doron Fediuck <dfediuck>
Status: CLOSED DUPLICATE QA Contact: meital avital <mavital>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.5.0CC: ecohen, gklein, iheim, jmoskovc, lsurette
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-08 09:34:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs none

Description Artyom 2014-10-07 12:01:48 UTC
Created attachment 944550 [details]
logs

Description of problem:
I have hosted-engine environment with two hosts, on host where vm is run I kill ovirt-ha-broker, in result agent try to start he vm on second host and failed because libvirtError: internal error Failed to acquire lock: error -243(vm still run on first host and sanlock not released)

Version-Release number of selected component (if applicable):
ovirt-hosted-engine-ha-1.2.2-2.el6ev.noarch

How reproducible:
Always

Steps to Reproduce:
1. Setup HE environment with two hosts.
2. Kill ovirt-ha-broker service on host where vm run
3. Wait until second host state state=EngineUnexpectedlyDown

Actual results:
Vm continue running on host without broker

Expected results:
Vm killed on host without broker and start run on host with broker.

Additional info:

Comment 1 Jiri Moskovcak 2014-10-08 09:34:46 UTC

*** This bug has been marked as a duplicate of bug 1098285 ***

Comment 2 Jiri Moskovcak 2014-10-08 11:01:00 UTC
both this bz and 1098285 lead to metadata not being updated which makes other agents think that the engine vm is in bad state and they try to restart it. But since the vm is actually ok and running it holds the lock, so other agents fail to start the VM with this error message.