[Linux-cluster] how to add user-defined fence device to cluster.conf?

bergman at merctech.com bergman at merctech.com
Sat Dec 13 00:31:42 UTC 2008

I've written a perl script, modeled after the fence_drac script, to control
outlets on a TrippLite PDUMH15ATNET PDU, and I'd like to contribute it to the

What do I need to do to make the cluster software (RHCS 5.2, under
CentOS 5.2, cman version 2.0.84) aware of the new agent so that I can
complete testing?

I've tried adding fencing methods and new fencedevice entries to
my cluster configuration, and there are no typos ("xmllint --noout
/etc/cluster/cluster.conf" runs cleanly).

There are no errors on the command-line or in log files when I use
"ccs_tool update /etc/cluster/cluster.conf" and "cman_tool version"
to update and propagate the new cluster configuration.

However, when I run "xmllint --relaxng  /usr/share/system-config-cluster/misc/cluster.ng  /etc/cluster/cluster.conf 1> /dev/null" I get the following errors:

	Relax-NG validity error : Extra element fencedevices in interleave
	/etc/cluster/cluster.conf:2: element cluster: Relax-NG validity error : Element cluster failed to validate content
	/etc/cluster/cluster.conf:15: element device: validity error : IDREF attribute name references an unknown ID "sbia-infr2-tripplite"
	/etc/cluster/cluster.conf fails to validate

Here's an subset of /etc/cluster.conf:

<?xml version="1.0"?>
<cluster alias="cluster" config_version="108" name="cluster>
        <fence_daemon clean_start="1" post_fail_delay="0" post_join_delay="30"/>
                <clusternode name="infr2" nodeid="1" votes="1">
                                <method name="1">
                                        <device modulename="" name="infr2-drac"/>
                                <method name="2">
                                        <device name="sphereon" port="2"/>
                                        <device name="sphereon" port="6"/>
                                <method name="3">
                                        <device name="infr2-tripplite"/>
                <clusternode name="infr1" nodeid="2" votes="1">
                                <method name="1">
                                        <device modulename="" name="infr1-drac"/>
                                <method name="2">
                                        <device name="sphereon" port="0"/>
                                        <device name="sphereon" port="4"/>
                                <method name="3">
                                        <device name="infr1-tripplite"/>
        <cman expected_votes="2" two_node="0"/>
                <fencedevice agent="fence_mcdata" ipaddr="" login="Administrator" name="sphereon" passwd_script="getpw_sphereon"/>
                <fencedevice agent="fence_drac" ipaddr="" login="root" name="infr1-drac" passwd_script="getpw_infr1-drac"/>
                <fencedevice agent="fence_drac" ipaddr="" login="root" name="infr2-drac" passwd_script="getpw_infr2-drac"/>
                <fencedevice agent="fence_tripplite" name="infr1-tripplite" ipaddr="pdu1" passwd_script="getpw_infr2-drac" operation="off" receptacle1="1" receptacle2="3"/>
                <fencedevice agent="fence_tripplite" name="infr2-tripplite" ipaddr="pdu1" passwd_script="getpw_infr2-drac" operation="off" receptacle1="2" receptacle2="4"/>

Finally, I'd like to warn people away from using the TrippLite PDU model
PDUMH15ATNET as a fencing device. While it seems to have nice features, it
has a design choice that is a serious problem with fencing--when a command
is given to power down an outlet, there is a "random" delay (observed
to be about 17 to 35 seconds) before that command is executed. This has
been acknowledged by TrippLite support as a design choice, with no option
or setting to override this behavior.



More information about the Linux-cluster mailing list