In a failover situation, the cluster looks for the best solution for the node. It goes to the most preferred node if it can. If that node is not available, it attempts to go to the next node in the resource’s preferred nodes list. It considers if the node is available and if it has an Resource Mutual Exclusion rules that must be obeyed for resources that are already mounted on the target node. If all of the nodes in the resource’s preferred nodes list are not available or have RME conflicts, the resource goes comatose instead of failing over to one of the nodes in its preferred nodes list.
In a cluster migration situation, the resource is currently online and you specify a target node. The resource cannot go to the specified node if any of the following conditions exist, and it stays online on the original node. You can view the target node’s log to understand why the resource was not available.
The specified node is not in the resource’s preferred nodes list.
The specified node is in the resource’s preferred nodes list, but the node is currently running another resource that is a Resource Mutual Exclusion conflict for the resource you are attempting to migrate.
The specified node is in the resource’s preferred nodes list, but the node is not available.
The specified node is in the resource’s preferred nodes list, but the node does not support the NSS media on the pool resource.
NOTE:The cluster resource migration fails with the following error in /Var/log/messages.
POOL_REVISION_CHECK (sfcbd:0:13): Cannot online resource '<Resource-Name>' on node '<Node_Name>', because NSS on the node may not understand the newer NSS media associated with the resource