Shutdown reboot off a node in cluster results in cluster outage.
|Article:TECH201065|||||Created: 2012-12-20|||||Updated: 2013-02-12|||||Article URL http://www.symantec.com/docs/TECH201065|
The vxfen module fails to stop when you manually restart a node by issuing
the shutdown -r now command.
The /var/VRTSvcs/log/vxfen/vxfen.log will report the following.
Tue Oct 16 18:42:42 GMT 2012 Invoked vxfen. Starting
Tue Oct 16 18:42:42 GMT 2012 calling stop_fun
Tue Oct 16 18:42:42 GMT 2012 stopping vxfen..
Tue Oct 16 18:42:43 GMT 2012 starting /sbin/vxfen-shutdown
Tue Oct 16 18:42:43 GMT 2012 starting retry loop
Tue Oct 16 18:42:43 GMT 2012 count is 0
Tue Oct 16 18:42:43 GMT 2012 vxfenconfig -U returned 1
Tue Oct 16 18:42:43 GMT 2012 vxfenconfig -U output is VXFEN vxfenconfig ERROR V-11-2-1023 Unable to unconfigure fencing since clients still active
VXFEN vxfenconfig ERROR V-11-2-1060 Please retry after shutting down VCS (GAB port h)
and/or CVM (GAB ports u/v/w).
RHEL5U8, RHEL6, SLES10, and SLES11
Storage Foundation HA 5.1SP1RP3
You cannot stop the vxfen module by rebooting the node if any of
its client processes, such as Veritas Cluster Server and so on, are running.
Typically, a node reboot stops all the client processes of vxfen and
subsequently stops the vxfen module. For some reason if the node restart does
not stop the client processes, then the attempt to stop vxfen module also fails
because client processes are still running.
Symantec has implemented a retry logic such that after a node
restart happens the vxfen module periodically tries to stop itself for a
specific number of times. The retry logic gives client processes enough time
This is fixed in 5.1SP1RP3P2.
Etrack tracking ID is 3002932
Article URL http://www.symantec.com/docs/TECH201065