Bug 804805 - fence_node -U fences instead of unfencing
fence_node -U fences instead of unfencing
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: fence-agents (Show other bugs)
powerpc Unspecified
medium Severity high
: rc
: ---
Assigned To: Marek Grac
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2012-03-19 15:54 EDT by Kapetanakis Giannis
Modified: 2012-06-20 10:40 EDT (History)
8 users (show)

See Also:
Fixed In Version: 3.2.5-17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 10:40:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0943 normal SHIPPED_LIVE fence-agents bug fix and enhancement update 2012-06-19 17:00:16 EDT

  None (edit)
Description Kapetanakis Giannis 2012-03-19 15:54:02 EDT
Description of problem:
While starting /etc/init.d/cman there is a call to unfence_self()
which does fence_node -U
This actually fences the host at least with my fence_brocade.

s2# fence_node -U
unfence s2.example.com success

Mar 19 21:29:30 s2 kernel: qla2xxx 0000:05:00.0: LOOP DOWN detected (2 3 0 0).
Mar 19 21:29:40 s2 fence_node[28391]: unfence v2.example.com success

It actually disables both ports (6,7) instead of enabling them...
Same happens when I do /etc/init.d/cman start or when the machine boots.

This is my configuration:

<clusternode name="s2.example.com" nodeid="2">
       <method name="s2_san">
            <device name="san" port="6"/>
            <device name="san" port="7"/>
       <method name="s2_drac">
            <device name="fence_drac_s2"/>
       <device action="enable" name="san" port="6"/>
       <device action="enable" name="san" port="7"/>

My fence device (Brocade 300):
    <fencedevice agent="fence_brocade" ipaddr="" login="username" name="san" passwd="pass"/>

From command line the fence agent works fine
# fence_brocade -l username -p password -a -o enable/disable -n 6/7

Furthermore, I believe the call to fence_node -U in /etc/init.d/cman should be done prior to qdisk.
The qdisk device in on the SAN, so until the ports are enabled, qdisk device is not available.


Comment 2 Kapetanakis Giannis 2012-03-20 05:57:59 EDT
I've added debug actions in /usr/sbin/fence_brocade today
and when I'm doing
/etc/init.d/cman start
I get:

Tue Mar 20 11:19:11 2012
success: portdisable 6
Tue Mar 20 11:19:18 2012
success: portdisable 7

So it's actually doing portdisable instead of portenable

Comment 3 David Teigland 2012-03-20 10:09:18 EDT
We "standardized" on "action=" long ago, but it appears fence_brocade was never updated.  It still only uses "option=".  If you try option="enable" it may work.

WRT qdisk, I'd first check whether you really need qdisk at all; it's best not to use it.
Comment 4 Kapetanakis Giannis 2012-03-20 11:28:28 EDT
I've added both (just in case it gets updated) and now it works fine :)

   <device action="enable" option="enable" name="san" port="6"/>
   <device action="enable" option="enable" name="san" port="7"/>

I'm using two-node-cluster so I thought I should try qdisk. I've read that it helps...

Anyway shouldn't unfencing be performed prior to qdisk initialization?


Comment 5 Fabio Massimo Di Nitto 2012-03-26 08:57:46 EDT
(In reply to comment #4)

> I'm using two-node-cluster so I thought I should try qdisk. I've read that it
> helps...
> Anyway shouldn't unfencing be performed prior to qdisk initialization?

It is best to avoid qdisk in this scenario and use cman two_node + fence delay but it also depends on many other configuration bits. Please submit a GSS ticket for an architecture review and we will be able to provide more information.
Comment 6 Fabio Massimo Di Nitto 2012-03-26 08:59:36 EDT
Marek, can we fix fence_brocade to behave consistently?
Comment 14 errata-xmlrpc 2012-06-20 10:40:31 EDT
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.


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