Hastatus shows a resource or group in W_OFFLINE_REVERSE or W_OFFLINE_PROPAGATE.

Article: 100020740
Last Published: 2020-08-05
Ratings: 3 3
Product(s): InfoScale & Storage Foundation

Problem

The Veritas Cluster Server (VCS) command hastatus shows a resource or service group in W_OFFLINE_REVERSE or W_OFFLINE_PROPAGATE state.
 

Error Message

(node_name) VCS:13077:Agent is unable to offline resource(xxx). Administrative intervention may be required.
 

Cause

 When a resource fails to go offline when failing over to another clustered node or after a clean operation is called, the resource is stuck in a waiting to go offline state.

This may be represented as: W_OFFLINE, W_OFFLINE_PROPAGATE, or W_OFFLINE_REVERSE


The notifier should send an error and the resnotoff trigger is run. 

According to VCS (Veritas Cluster Server) User's Guide, we can see the following definition of 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.


The above two states indicate the resource is transitioning.

This can occur before the onlining or offlining of a service group until fully completed or if a reverse action command (offline-/online) is issued.

 

 

Solution

Try the following to clear the states:

1. Flush the Service Group.
 
# hagrp -flush <sg_name> -sys <sys_name>
# hares -probe <res_name> -sys <sys_name>


2) Now run the below command to see if any changes occurr to the status or the resources. 
 

     # hastatus -sum


3)  Restart the Veritas High Availability Daemon (HAD). This can be done while leaving all the applications running.
   
       o Firstly, freeze all the VCS service groups, one group at a time: 

# hagrp -list | grep <sys_name>
# hagrp -freeze <vcs_service_group_name>
 
Note : Service group cant be frozen  when it is transitioning in the cluster. Hence, proceed to the next step.

      o Next, force-stop the cluster & restart VCS
 
# haconf -dump -makero
# hastop -all -force
# hastart         ---->(execute this command on all nodes of the cluster)

       o Lastly, unfreeze the VCS service groups (if it is frozen earlier):  
 
# hagrp -list | grep <sys_name>
# hagrp -unfreeze <vcs_service_group_name>
 
 

 

Was this content helpful?