Hastatus shows a resource or group in W_OFFLINE_REVERSE or W_OFFLINE_PROPAGATE.
| Article:TECH69675 | | | Created: 2009-01-15 | | | Updated: 2010-01-19 | | | Article URL http://www.symantec.com/docs/TECH69675 |
Problem
Hastatus shows a resource or group in W_OFFLINE_REVERSE or W_OFFLINE_PROPAGATE.
Error
TAG_B 2008/06/06 06:24:58 (g3ah6010) VCS:13077:Agent is unable to offline resource(xxx). Administrative intervention may be required.
Solution
When a resource fails to offline when failing over or after a clean is called, then the resource is stuck in a waiting to go offline state: W_OFFLINE, W_OFFLINE_PROPAGATE, or W_OFFLINE_REVERSE.
The notifier should send an error and the "resnotoff" trigger is run.
According to VCS User's Guide, we can see the following Definition in "Resource Attributes",
================
WAITING TO GO ONLINE (reverse)
Resource waiting to be brought online, but when it is online it automatically attempts to go offline. Typically this is the result of issuing an offline command while resource was waiting to go online.
WAITING TO GO OFFLINE (reverse/propagate)
Same as above, but resource propagates offlining.
================
Basically the above two states (W_OFFLINE_PROPOGATE and W_OFFLINE_REVERSE ) indicate the resource "is transitioning". A most common cause is before an operation, either onlining or offlining of a service group, is completed (fully), an reverse action command (offline-/online) is issued .
You can try the followings to clear the states.
1- If it's ok for the resource to go offline. Flush Service Group to clear the "reverse" and intent to online the resource. The "offline" intent can not be cleared via commands.
hagrp -flush <sg_name> -sys <sys_name>
hares -probe <res_name> -sys <sys_name>
Then run hastatus -sum again to see if any changes occurred
to the status. If the above does not resolve the issue then.
If it's ok to bring down the resource and group (to failover, perhaps), then manually offline the resource outside of VCS.
2- If the resource should stay online, VCS must be restarted.
This can be done while leaving all the applications running.
First freeze all the VCS service groups, one group at a time:
If it's ok to bring down the resource and group (to failover, perhaps), then manually offline the resource outside of VCS.
2- If the resource should stay online, VCS must be restarted.
This can be done while leaving all the applications running.
First freeze all the VCS service groups, one group at a time:
hagrp
-list | grep <sys_name>
hagrp
-freeze <vcs_service_group_name>
Then restart VCS
haconf
-dump -makero
hastop
-all -force
hastart
Now, unfreeze the VCS service
groups:
hagrp
-list | grep <sys_name>
hagrp
-unfreeze <vcs_service_group_name>
|
|
Related Articles
Legacy ID
323172
Article URL http://www.symantec.com/docs/TECH69675
Terms of use for this information are found in Legal Notices
Thank you.