NFS Storage can get list of all vmkernel IPs from a specific cluster during SRM Recovery Tasks and cause a new access group or export policy to be created

Products

• VMware Live Recovery

Issue/Introduction

This article covers an expected behavior between SRM and some SRA adapters where access group or export list may get recreated with all the vmkernel IPs (including management,vmotion,etc.) and not just the NFS storage specific IPs during SRM recovery task.

Symptoms:
NFS Storage access group or export policy is being over written when recovery tasks are initiated by SRM

Environment

VMware Site Recovery Manager 6.x
VMware vCenter Site Recovery Manager 8.x

Cause

SRM by design will validate all the hba adapters and vmkernel IPs of ESXi hosts in the cluster which are associated with placeholder VMs for a given Protection Group being recovered and pass them along to SRA Command line for failover

Here is an sample command output :

2021-03-01T17:13:06.567-05:00 info vmware-dr[02514] [SRM@6876 sub=SraCommand opID=ca19ce35-135b-4aad-b338-ad8be2179e5e-failover:f5cb:6abe:a6f8:6065] Command line for failover: /usr/bin/docker exec -i -u 660:660 d33f8318710a /srm/sra/command
--> <?xml version="1.0" encoding="UTF-8"?>
--> <Command xmlns="http://www.vmware.com/srm/sra/v2">
--> <Name>failover</Name>
--> <OutputFile>/tmp/sra-output-4556-111</OutputFile>
--> <StatusFile>/tmp/sra-status-4557-161</StatusFile>
--> <LogLevel>verbose</LogLevel>
--> <LogDirectory>/srm/sra/log</LogDirectory>
--> <Connections>
--> <Connection id="primary">
--> <Addresses>
--> <Address id="mgmtIP">10.8.8.x</Address>
--> </Addresses>
--> <Username>***</Username>
--> <Password>***</Password>
--> <Opaques>
--> <Opaque id="NFS IP">10.8.6.x</Opaque>
--> <Opaque id="SVM Name">HRS-NFS02</Opaque>
--> <Opaque id="VolumeInclusion">vol064,vol1012,vol1014,vol058,mh88,vol_mh81,vol_mh82,vol_mh151,vol_mh13,vol_mh150,vol_mh89,vol_mh14,vol_mh15,vol_mh16,vol_mh17,vol_mh73,vol_mh34,vol_mh46,vol_mh78,vol_mh10,vol_mh102,vol_mh47,vol_mh1071,vol_mh1039,vol_mh1084,vol_mh26,vol_mh48,vol_mh59</Opaque>
--> </Opaques>
--> </Connection>
--> </Connections>
--> <FailoverParameters>
--> <ArrayId>hrs1netapp:NFS02</ArrayId>
--> <AccessGroups>
--> <AccessGroup id="domain-c26">
--> <Initiator id="10.8.2.x" type="NFS"/>
--> <Initiator id="10.8.3.x" type="NFS"/>
......
--> <Initiator id="169.254.0.x" type="NFS"/>
--> <Initiator id="10.8.2.x" type="NFS"/>
--> <Initiator id="10.8.3.x" type="NFS"/>
--> <Initiator id="10.8.6.x" type="NFS"/>
--> <Initiator id="169.254.0.x" type="NFS"/>
--> </AccessGroup>
--> </AccessGroups>
--> <TargetDevices>
--> <TargetDevice key="//NFS02/vol064_sac1netapp">
--> <AccessGroups>
--> <AccessGroup id="domain-c26"/>
--> </AccessGroups>
--> </TargetDevice>
--> </TargetDevices>
--> </FailoverParameters>
--> </Command>

Resolution

This is an expected behavior between SRM and SRA currently and there is no filter mechanism available. Since there is no impact to SRM workflow OR ESXi mounting the volumes, this can be ignored. It would be advised that network configuration is appropriately done or the NFS mounts may use any available vmkernel IP with the modified access group/export list created on Storage.

Additional Information

NetApp has an article which explains on how SRA fetches the IP address and what determines whether or not to create a new access group or export group policy:

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/Storage_Replication_Adapter_for_Data_ONTAP/What_determines_if_a_new_initator_group_or_export_policy_is_created_during_a_failover_operation%3F