Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 978956 - Fence host via proxy with rhevh failed
Summary: Fence host via proxy with rhevh failed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.2.0
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
: 3.3.0
Assignee: Eli Mesika
QA Contact: Elena
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-27 11:29 UTC by Artyom
Modified: 2016-02-10 19:00 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-21 13:42:17 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)
log (1.68 KB, text/x-log)
2013-06-27 11:29 UTC, Artyom
no flags Details

Description Artyom 2013-06-27 11:29:39 UTC
Created attachment 766060 [details]
log

Description of problem:
Fence host with power management via other host with rhevh failed
Fencing failed via GUI, via CLI also failed.
Via vdsClient fencing work

Version-Release number of selected component (if applicable):
rhevm sf18
Host with power management - vdsm-4.10.2-17.0.el6ev
Host with rhevh - vdsm-4.10.2-19.0.el6ev

How reproducible:
Install two hosts, that one of them with correct power management and another with rhevh
Fence host with power management(restart via power management)

Steps to Reproduce:
1. See above
2.
3.

Actual results:
Host with power management not restarted and error messages in events:
Failed to restart Host <host_with_pm>, (User: admin@internal).	
Failed to stop Host <host_with_pm>, (User: admin@internal).

Expected results:
Host with power management restarted

Additional info:

Comment 1 Eli Mesika 2013-06-27 12:53:01 UTC
Not sure this is related to rhevh 

Please specify the PM agent/s used 

Please redo the test with two RHEL hosts , only if the same test succeeded on 2 RHELs and fails on one RHEL and one RHEVH when RHEVH is the proxy we know that it is connected to RHEVH

Also, please do a oposite test where RHEVH host need to be fenced by a RHEL proxy

Comment 5 Artyom 2013-06-30 10:54:20 UTC
1) rhevh:
   vdsm-4.10.2-19.0.el6ev
   fence-agents-3.1.5-25.el6_4.2.x86_64

Rhel with last vdsm 3.3
2) rhel:
   vdsm-4.11.0-35.git34c1ef1.el6
   fence-agents-3.1.5-25.el6_4.2.x86_64
   I forget that my host was with last vdsm, when I fence host with power management via this host, no errors messages and host really restarted, but vds command seem to be the same as for fence with error message:

Thread-578::DEBUG::2013-06-30 12:45:14,808::API::1079::vds::(fenceNode) fenceNode(addr=10.35.23.24,port=,agent=apc_snmp,user=talayan,passwd=XXXX,action=status,secure=,options=port=4
secure=no)
Thread-578::DEBUG::2013-06-30 12:45:15,184::API::1105::vds::(fenceNode) rc 0 in agent=fence_apc_snmp
ipaddr=10.35.23.24
login=talayan
option=status
passwd=XXXX
port=4
secure=no out Status: ON
 err Parse error: Ignoring unknown option 'secure=no'

3) When trying to restart via rhel with 
   vdsm-4.10.2-22.0.el6ev
   fence-agents-3.1.5-25.el6_4.2.x86_64
One time it restart ok, other return error message and host not restarted

Comment 11 Barak 2013-07-04 14:41:02 UTC
Artyom, 
in order to avoid confusion and to make sure this is really an issue we need you to:
check fencing host X (same host in all below tests)
- check fencing through RHEVH (through UI after at least 5 minutes the host is maintenance).
- check fencing through  RHEL (through UI after at least 5 minutes the host is in maintenance)

According to the logs above it looks like some of the failures were due to insufficient quite time.

Comment 12 Artyom 2013-07-08 07:31:46 UTC
Fencing of host work fine via RHEL when given needed timeouts, also via RHEVH,
but it still question why it different format of command fenceNode via GUI and via vdsClient.

Comment 13 Eli Mesika 2013-07-21 09:26:27 UTC
(In reply to Artyom from comment #12)
> Fencing of host work fine via RHEL when given needed timeouts, also via
> RHEVH,
> but it still question why it different format of command fenceNode via GUI
> and via vdsClient.

Please elaborate on the difference you see in the formats

Comment 14 Artyom 2013-07-21 10:36:37 UTC
Via vdsClient
fenceNode(addr=aqua-vds7-mgmt.qa.lab.tlv.redhat.com,port=0,agent=ipmilan,user=root,passwd=XXXX,action=reboot,secure=False,options=)

Via GUI
fenceNode(addr=aqua-vds7-mgmt.qa.lab.tlv.redhat.com,port=,agent=ipmilan,user=root,passwd=XXXX,action=status,secure=,options=)

Comment 15 Eli Mesika 2013-07-21 13:02:47 UTC
(In reply to Artyom from comment #14)
> Via vdsClient
> fenceNode(addr=aqua-vds7-mgmt.qa.lab.tlv.redhat.com,port=0,agent=ipmilan,
> user=root,passwd=XXXX,action=reboot,secure=False,options=)

Please add the full command syntax to vdsClient

Comment 16 Artyom 2013-07-21 13:20:22 UTC
vdsClient fenceNode aqua-vds7-mgmt.qa.lab.tlv.redhat.com 0 ipmilan root calvin reboot

Comment 17 Eli Mesika 2013-07-21 13:42:17 UTC
(In reply to Artyom from comment #16)
> vdsClient fenceNode aqua-vds7-mgmt.qa.lab.tlv.redhat.com 0 ipmilan root
> calvin reboot

So, you are giving port=0 in the call to vdsClient and the default for secured is false , so its no matter if you give secure as an empty string or not given it at all , in both 'false' will be used

After consulting with Barak this is CLOSED with NOTABUG


Note You need to log in before you can comment on or make changes to this bug.