Bug 1054778

Summary: OVIRT35 - [RFE] Allow to perform fence operations from a host in another DC
Product: [Retired] oVirt Reporter: Sven Kieske <s.kieske>
Component: ovirt-engine-webadminAssignee: Eli Mesika <emesika>
Status: CLOSED CURRENTRELEASE QA Contact: sefi litmanovich <slitmano>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 3.3CC: ecohen, emesika, gklein, iheim, mgoldboi, oourfali, rbalakri, slitmano, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: 3.5.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: infra
Fixed In Version: ovirt-3.5.0-alpha1 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1114253 (view as bug list) Environment:
Last Closed: 2014-10-17 12:43:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1090803    
Bug Blocks: 1114253    

Description Sven Kieske 2014-01-17 13:03:12 UTC
Description of problem:

When you shut down a host in a data center with no other host, you are
unable to start it using the configured power management in ovirt.
Version-Release number of selected component (if applicable):

ovirt-engine 3.3.2 on EL 6

How reproducible:
shut down a host in a datacenter with a single host (e.g. "init 0" on a shell)

Steps to Reproduce:
1. shut down a host e.g. in a local storage DC
2. the host becomes "non responsive"
3. try to start the host via the configured powermanagement

Actual results:

Error while executing action:

hostname:

    There is no other Host in the Data Center that can be used to test the Power Management settings.

Expected results:

the hosts starts, there is no test of power management necessary.

Additional info:

no other action helps to circumvent this test:
put host in maintenance, confirm manually host has been rebooted.

you end up with the failing power management test (why should it test it with
another host in the first place?)

Related Bug: BZ1053434

Comment 1 Itamar Heim 2014-01-17 17:56:07 UTC
my first instinct was this was similar to bug 837539, but its not.

the engine doesn't perform fence operations from the engine rather from another host in the cluster/dc, hence needs "another running host" (by asking vdsm on the other host to call the fence script)

eli, maybe until we can do this from engine, we can allow doing this from a host not in same DC?
(wouldn't work for an engine with really only a single host, but for most use cases should be good enough?)

Comment 2 Eli Mesika 2014-01-26 15:30:23 UTC
(In reply to Itamar Heim from comment #1)

> eli, maybe until we can do this from engine, we can allow doing this from a
> host not in same DC?
> (wouldn't work for an engine with really only a single host, but for most
> use cases should be good enough?)

Yes, we have now the pm_proxy_preferences field that is set by default to "cluster,DC" maybe we can support that by adding "other" such that in hosts that have this value set to "cluster,DC,other" we will search for proxy in other DCs

Comment 3 Itamar Heim 2014-02-13 18:31:06 UTC
pushing to target release 3.5, assuming its not planned for 3.4 at this point...

Comment 4 Eli Mesika 2014-04-07 20:19:18 UTC
We will address for 3.5 only the option to look for proxy outside the DC where the host is located and try to use other DCs

This will be done by adding to the pm_proxy_preferences field which is defaulted now to "cluster,DC" another option named otherDC.
(The pm_proxy_preferences value is available via the UI Host New/Edit PM TAB in the field named "source" , in the API it is under <pm_proxies>)

The default will stay "cluster,DC" and the admin can change this value per host using the API

Comment 5 Sandro Bonazzola 2014-10-17 12:43:31 UTC
oVirt 3.5 has been released and should include the fix for this issue.