Mount resources in UNKNOWN state after upgrading/modifying the Veritas Cluster Server (VCS) cluster configuration
|Article:TECH157024|||||Created: 2011-03-31|||||Updated: 2011-03-31|||||Article URL http://www.symantec.com/docs/TECH157024|
Mount resources in UNKNOWN state after upgrading/modifying the VCS cluster configuration
# hares -display mnt1 -sys blender
mnt1 State blender OFFLINE|STATE UNKNOWN
When upgrading Veritas Cluster Server (VCS) the file types.cf (/etc/VRTSvcs/conf/config/types.cf) used to define bundled resource types was not updated.
This lead to agent binaries/scripts being passed an unexpected number of arguments during resource probe and meant that the cluster high availability daemon (had) was unable to determine the state of cluster resources after start up.
To solve the issue had should be stopped and /etc/VRTSvcs/conf/config/types.cf replaced with the correct copy for the currently running version of VCS. This is normally placed at /etc/VRTSvcs/conf/types.cf during the VCS upgrade/installation.
The following shows an example of the scenario for a single node cluster with a Mount resource where VCS has just been upgraded from 5.0 to 5.0MP1 on HP-UX 11.31. Note that it is possible for similar issues to occur regardless of operating system as VCS requires the correct types.cf to be in place when started to sucessfully monitor resources/
blender# hastatus -sum
-- SYSTEM STATE
A blender RUNNING 0
-- GROUP STATE
B sg1 blender N Y OFFLINE
-- RESOURCES NOT PROBED
D sg1 Mount mnt1 blender <<<<<<<<< mnt1 is NOT probed
After upgrading VCS was simply restarted using hastart command without copying the new types.cf into place.
As shown the new VCS 5.0MP1 Mount Agent needs some additional entries from the types.cf to properly managed the Mount resources.
To solve the issue simply stop the high availability daemon, replace the types.cf and restart the high availability daemon.
blender# hastop -all # it will work for both single and multi node clusters
IMPORTANT! If the types.cf was previously customised i.e. via hatype -modify commands or using the VOM/HAGUI, such changes will need to be re-applied after types.cf replacement.
Article URL http://www.symantec.com/docs/TECH157024