3.1.4.1.52 ApiMoveGroup (Opnum 51)

(Protocol Version 2) The ApiMoveGroup method instructs the server to move ownership of the specified group to another node in the cluster. The server SHOULD select the destination node based on preferences and limitations on where the resources in the group can be owned and any preferred node that is associated with the group. These policies are configured and executed by using implementation-specific methods between servers.

The server MUST initiate transition of all resources that are contained in the ClusterResourceOnline group state to the ClusterResourceOffline state. When all the resources have reached either the ClusterResourceOffline or ClusterResourceFailed state, the server MUST attempt to transfer ownership of the group to another active node in the cluster.

On the destination node, the server MUST initiate transition of each resource in the group to its persistent state. That is, if the persistent state of the resource is ClusterResourceOnline, the server MUST attempt to transition the resource from the ClusterResourceOffline state to the ClusterResourceOnline state. It is possible for the final group state on the destination node to be different from the group state prior to the move.

The server MAY return from this method while the move procedure is executed asynchronously. In this case, the server MUST return 0x000003E5 (ERROR_IO_PENDING). After completion of the move procedure, depending on whether the resources that are contained in the designated group were successfully brought to their persistent states, the server MUST set the group state as specified in section 3.1.4.1.46.

If the server executes the full move procedure synchronously, and if the server fails to bring the resources that are contained in the group to their persistent states, the server MUST return a nonzero error code other than 0x000003E5 and set the group state as specified in section 3.1.4.1.46.

Whether the move procedure is executed synchronously or asynchronously, it is possible for the resources in the group to fail to reach their persistent state on the destination node. In this case, the server SHOULD attempt recovery actions, such as moving the group to another node in the cluster, which might include moving the group to the node that was the owner prior to the move request.

The server MUST fail this method if the specified group is in the ClusterGroupPending state, as specified in section 3.1.4.1.46, or if any of the group resources are in either the ClusterResourceOnlinePending or ClusterResourceOfflinePending states.

The server MUST accept an ApiMoveGroup request only if its protocol server state is read/write, as specified in section 3.1.1.

 error_status_t ApiMoveGroup(
   [in] HGROUP_RPC hGroup
 );

hGroup: An HGROUP_RPC context handle that is obtained in a previous ApiOpenGroup or ApiCreateGroup method call.

Return Values: The method MUST return the following error codes for the specified conditions.

Return value/code	Description
0x00000000 ERROR_SUCCESS	The move of the designated group was successfully completed.
0x00000005 ERROR_ACCESS_DENIED	Access is denied.
0x00000006 ERROR_INVALID_HANDLE	The hGroup parameter does not represent a valid HGROUP_RPC context handle.
0x000003E5 ERROR_IO_PENDING	The ownership of the group is in transition.
0x0000138D ERROR_HOST_NODE_NOT_AVAILABLE	A cluster node is not available for this operation.

For any other condition, this method MUST return a value that is not one of the values listed in the preceding table. The client MUST behave in one consistent, identical manner for all values that are not listed in the preceding table. The client SHOULD treat errors specified in 3.2.4.6 as recoverable errors and initiate the reconnect procedure as specified in section 3.2.4.6.