This is the same process we went through when we created the cluster in the first place. We will get used to this sequence of commands. If we didn't experience any problems during the running of cmcheckconf , we shouldn't find any problems at this stage. Again, I have included the output from my cluster when I ran cmapplyconf for my clockwatch package.
root@hpeos001[clockwatch] # cmapplyconf -v -k -P clockwatch.conf Checking existing configuration ... Done Gathering configuration information ... Done Parsing package file: clockwatch.conf. Attempting to add package clockwatch. Maximum configured packages parameter is 10. Configuring 1 package(s). 9 package(s) can be added to this cluster. Modify the package configuration ([y]/n)? y Adding the package configuration for package clockwatch. Completed the cluster update.
When the binary configuration file is distributed, Serviceguard does not automatically start the application as we can see when we look at the output from cmviewcl . Take note that I am looking only at the information for my package, i.e., I am using the “p <package name > option to cmviewcl .
root@hpeos001[clockwatch] # cmviewcl -v -p clockwatch UNOWNED_PACKAGES PACKAGE STATUS STATE AUTO_RUN NODE clockwatch down halted disabled unowned Policy_Parameters: POLICY_NAME CONFIGURED_VALUE Failover configured_node Failback manual Script_Parameters: ITEM STATUS NODE_NAME NAME Subnet up hpeos001 192.168.0.0 Subnet up hpeos002 192.168.0.0 Node_Switching_Parameters: NODE_TYPE STATUS SWITCHING NAME Primary up enabled hpeos001 Alternate up enabled hpeos002 root@hpeos001[clockwatch] #