- Oracle Solaris Cluster version management
Note - Beginning with the Sun Cluster 3.2 release, Oracle Solaris Cluster software includes an object-oriented command set. Although Oracle Solaris Cluster software still supports the original command set, Oracle Solaris Cluster procedural documentation uses only the object-oriented command set. For more information about the object-oriented command set, see the Intro(1CL) man page.
The scversions command commits the cluster to a new level of functionality after a rolling–upgrade to new Oracle Solaris Cluster software. With no arguments, the scversions command prints a message indicating whether a commitment is needed.
The following operands are supported:
Commit the set of nodes that are currently active members of the cluster to the highest possible level of functionality.
When you upgrade a node (either through upgrade to a new release of the product or by application of a patch) and boot it back into the cluster, some of the internal protocols on that node might have to run at lower versions in order to cooperate correctly with other nodes in the cluster. When the cluster is in this state, some administrative actions might be disabled and some new functionality introduced in the upgrade might be unavailable.
When you run this command once from any node after all nodes are upgraded, the cluster switches to the highest versions of internal protocols possible. Assuming that all nodes have the same Oracle Solaris Cluster software installed at that time, all new functionality becomes available and any administrative restrictions are removed.
If a node that has not been upgraded is an active member of the cluster at the time you run the -c option to scversions, the command has no effect because the cluster is already running at the highest possible level of functionality.
If a node has not been upgraded and is not an active member of the cluster when you run the -c option to scversions (for example, if that node is down for maintenance), the internal protocols of the cluster are upgraded to the highest possible versions. You might have to upgrade the node that was not an active member of the cluster to enable it to rejoin the cluster.
See attributes(5) for descriptions of the following attributes: