This section cites the most common problems associated with bringing resources online and taking them offline. Bold text provides a description of the problem. Recommended action is also included, where applicable.
Service group brought online due to failover.
VCS attempts to bring resources online that were already online on the failed system, or were in the process of going online. Each parent resource must wait for its child resources to be brought online before starting.
Recommended Action: Verify that the child resources are online.
Waiting for service group states.
The state of the service group prevents VCS from bringing the resource online.
Recommended Action: Review the state of the service group.
See Cluster and system states.
Waiting for child resources.
One or more child resources of parent resource are offline.
Recommended Action: Bring the child resources online first.
Waiting for parent resources.
One or more parent resources are online.
Recommended Action: Take the parent resources offline first.
Waiting for resource to respond.
The resource is waiting to come online or go offline, as indicated. VCS directed the agent to run an online entry point for the resource.
Recommended Action: Verify the resource's IState attribute. See the engine and agent logs in /var/VRTSvcs/engine_A.log
Agent not running.
The resource's agent process is not running.
Recommended Action: Use
-summary to see if the agent is listed as faulted. Restart the agent:
Invalid agent argument list.
The scripts are receiving incorrect arguments.
Recommended Action: Verify that the arguments to the scripts are correct. Use the output of
-display resource to see the value of the ArgListValues attribute. If the ArgList attribute was dynamically changed, stop the agent and restart it.
To stop the agent:
To restart the agent:
The Monitor entry point of the disk group agent returns ONLINE even if the disk group is disabled.
This is expected agent behavior. VCS assumes that data is being read from or written to the volumes and does not declare the resource as offline. This prevents potential data corruption that could be caused by the disk group being imported on two hosts.
You can deport a disabled disk group when all I/O operations are completed or when all volumes are closed. You can then reimport the disk group to the same system.
Note A disk group is disabled if data including the kernel log, configuration copies, or headers in the private region of a significant number of disks is invalid or inaccessible. Volumes can perform read-write operations if no changes are required to the private regions of the disks.