InfoScale™ Cluster Server 9.0 Bundled Agents Reference Guide - AIX
- Introducing bundled agents
- Storage agents
- DiskGroup agent
- Notes for DiskGroup agent
- Sample configurations for DiskGroup agent
- DiskGroupSnap agent
- Notes for DiskGroupSnap agent
- Sample configurations for DiskGroupSnap agent
- Volume agent
- VolumeSet agent
- Sample configurations for VolumeSet agent
- LVMVG agent
- Notes for LVMVG agent
- Mount agent
- Sample configurations for Mount agent
- SFCache agent
- Network agents
- About the network agents
- IP agent
- NIC agent
- IPMultiNIC agent
- MultiNICA agent
- About the IPMultiNICB and MultiNICB agents
- IPMultiNICB agent
- Sample configurations for IPMultiNICB agent
- MultiNICB agent
- Sample configurations for MultiNICB agent
- DNS agent
- Agent notes for DNS agent
- About using the VCS DNS agent on UNIX with a secure Windows DNS server
- Sample configurations for DNS agent
- File share agents
- NFS agent
- NFSRestart agent
- Share agent
- About the Samba agents
- Notes for configuring the Samba agents
- SambaServer agent
- SambaShare agent
- NetBios agent
- Service and application agents
- Apache HTTP server agent
- Application agent
- Notes for Application agent
- Sample configurations for Application agent
- CoordPoint agent
- LPAR agent
- Notes for LPAR agent
- MemCPUAllocator agent
- MemCPUAllocator agent notes
- Process agent
- Usage notes for Process agent
- Sample configurations for Process agent
- ProcessOnOnly agent
- RestServer agent
- WPAR agent
- Infrastructure and support agents
- Testing agents
- Replication agents
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:
when the volume group has pending I/O operations, or
when an application or upper-level resources in the resource dependency tree uses the volume group.
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:
- Set the POSTOFFLINE value in TriggersEnabled attribute of service group containing the LVMVG resource.
- 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.