Deactivation failure using the varyoffvg command on losing storage connectivity

In certain circumstances, the varyoffvg command does not deactivate all the volume groups on a node. This failure can prevent the failback of the LVMVG resource.

In situations where storage connectivity is lost, the LVMVG resources fails over. Failback for the LVMVG resource requires the deactivation of the volume groups on the node that lost its connectivity to storage. VCS uses the varyoffvg command to deactivate the volume groups. The LVMVG resource cannot fail back, however, when deactivation is unsuccessful.

When the volume group loses its storage connectivity, the clean function executes the varyoffvg command. Deactivation using the varyoffvg command can fail, however, if the volume group is busy.

Criteria that can cause this failure can include:

To overcome this deactivation failure, a post offline trigger has been added to issue the varyoffvg command. A side effect of the post offline trigger is that you must set the value of the OnlineRetryLimit attribute to 0.

Following steps are performed to enable the lvmvg_postofline trigger:

  1. Set the POSTOFFLINE value in TriggersEnabled attribute of service group containing the LVMVG resource.
  2. Install the lvmvg_postoffline trigger script from the sample triggers directory into the triggers directory:

    # cp /opt/VRTSvcs/bin/sample_triggers/VRTSvcs/lvmvg_postoffline /opt/VRTSvcs/bin/triggers/postoffline

    Change the file permissions to make it executable.

After the restoration of storage connectivity, you must ensure that the volume groups are deactivated on the node. You can then clear the fault on the resources. If you find active volume groups, deactivate them using the varyoffvg command.

The LVMVG resource must be the bottom-most resource in the resource dependency tree in the service group. A resource under the LVMVG resource can potentially fail to go offline if the volume group's deactivation fails.