Perform this procedure to finish Oracle Solaris Cluster upgrade. Perform all steps from the global zone only.
Before You Begin
Ensure that all steps in How to Verify the Upgrade are completed.
After upgrade, the resource_security property for the cluster is reset to COMPATIBLE. To use a different security policy for RGM resources, run the following command from one node of the cluster:
phys-schost# cluster set -p resource_security=policy clustername
You can alternatively use the clsetup utility from the Other Cluster Tasks menu option. For more information about the resource_security property, see the cluster (1CL) man page.
You must migrate all resources to the Oracle Solaris Cluster 4.2 resource-type version to use the new features and bug fixes that are provided in this release.
See Upgrading a Resource Type in Oracle Solaris Cluster Data Services Planning and Administration Guide , which contains procedures which use the command line. Alternatively, you can perform the same tasks by using the Resource Group menu of the clsetup utility. The process involves performing the following tasks:
Registering the new resource type.
Migrating the eligible resource to the new version of its resource type.
Modifying the extension properties of the resource type.
The clsetup Main Menu is displayed.
The Resource Group Menu is displayed.
Type q to back out of each submenu, or press Ctrl-C.
# clresource enable resource
# clresource status
# clresourcegroup online -emM resourcegroup
# clresourcegroup status
# clresourcegroup online -Z zonecluster resource-group # clresource enable -Z zonecluster resource # clresourcegroup online -eM -Z zonecluster resource-group
Also perform this task if you want to configure automatic reboot for the first time.
phys-schost# clnode show
phys-schost# clnode set -p reboot_on_path_failure=enabled node
Specifies the property to set
Specifies that the node will reboot if all monitored disk paths fail, provided that at least one of the disks is accessible from a different node in the cluster.
phys-schost# clnode show === Cluster Nodes === Node Name: node … reboot_on_path_failure: enabled …
phys-schost# zpool get all rootpool > filename
Store the file in a location outside the cluster. If you make any root pool configuration changes, run this command again to capture the changed configuration. If necessary, you can use this information to restore the root pool partition configuration. For more information, see the zpool(1M) man page.
An archived backup of your cluster configuration facilitates easier recovery of your cluster configuration.
For more information, see How to Back Up the Cluster Configuration in Oracle Solaris Cluster System Administration Guide .
Resource-type migration failure - Normally, you migrate resources to a new resource type while the resource is offline. However, some resources need to be online for a resource-type migration to succeed. If resource-type migration fails for this reason, error messages similar to the following are displayed:
phys-schost - Resource depends on a SUNW.HAStoragePlus type resource that is not online anywhere.
(C189917) VALIDATE on resource nfsrs, resource group rg, exited with non-zero exit status.
(C720144) Validation of resource nfsrs in resource group rg on node phys-schost failed.
If resource-type migration fails because the resource is offline, use the clsetup utility to re-enable the resource and then bring its related resource group online. Then repeat migration procedures for the resource.
Java binaries location change - If the location of the Java binaries changed during the upgrade of Oracle Solaris software, you might see error messages similar to the following when you attempt to run the cacaoadm start command:
phys-schost# /usr/sbin/cacaoadm start
No suitable Java runtime found. Java 1.7 or higher is required.
Jan 3 17:10:26 ppups3 cacao: No suitable Java runtime found. Java 1.7 or higher is required.
Cannot locate all the dependencies
This error is generated because the start command cannot locate the current location of the Java binaries. The JAVA_HOME property still points to the directory where the previous version of Java was located, but that previous version was removed during upgrade.
To correct this problem, change the setting of JAVA_HOME in the following configuration file to use the current Java directory:
The cluster upgrade is complete.