Issue with SRM failover while using NetApp SRA version 10.5

Products

• VMware Live Recovery

Issue/Introduction

Symptoms:

• SRM UI reports all the "Protection group" as not configured state whenever the NetApp SRA 10.5 is being deployed.

• Running "discoverDevices" on the array pair may show errors "'Storageport' not found" on the SRM UI.

Similar events are seen in /var/log/vmware/srm/vmware-dr.log

2026-01-29T13:00:57.090+10:00 info vmware-dr[01429] [SRM@6876 sub=Storage opID=#########-####-####-####-#############-reloadAdapters:####:####] HandleDiscovery
Fault: SRA discover devices command failed
--> N2Dr3Xml20XmlValidateExceptionE Expected element 'StoragePorts' not found

• As when the devices have started discovering, Below events in "/var/log/vmware/srm/vmware-dr.log" are observed.

  2026-01-29T13:14:59.747+10:00 error vmware-dr[02121] [SRM@6876 sub=StorageProvider opID=f1d35d92] Config file '[ds##] VM/VM .vmx' of virtual machine 'vm-314148:###' is located on a non-replicated datastore 'datastore-####'
2026-01-29T13:14:59.747+10:00 warning vmware-dr[01174] [SRM@6876 sub=StorageProvider opID=013c5356] Datastore 'datastore-###' is no longer replicated

Environment

VMware Live Recovery 9.x

Netapp Ontap Version (OTV) - 10.5 / SRA 10.5

Cause

A mismatch or conflict in the NFS details between the ESXi host’s device backing of the NFS datastore and the NFS list on the array manager causes the protection group to appear in a “Not Configured” state and results in the VMs being marked as Invalid.

 

Due to the issue on SRA version 10.5, It requires an NFS IP to updated on the SRM array manager instead of the FQDN. But since the NFS datastore on the ESXi host is mounted via FQDN there are configuration issues seen.

 "Discoverdevices" fails with "Storageports" not found are observed when the NFS hostnames or IP address is updated with FQDN.

Sametime on the ESXi host, we see that NFS datastore's device backing populated with FQDN

Due to the mismatch of the NFS details , The protection group on SRM shows configuration issues as it is unable to evaluate the correct NFS configurations.

In /var/log/vmware/srm/vmware-dr.log, Below similar mapping and unknown backing type events can be seen.

2026-01-29T13:14:59.764+10:00 warning vmware-dr[01421] [SRM@6876 sub=Replication opID=f1d35d92] SelectLocators failed for VM 'vm-####': (dr.storageProvider.fault.ConfigFileNotReplicated) {
-->    faultCause = (vmodl.MethodFault) null,
-->    faultMessage = <unset>,
-->    vm = 'vim.VirtualMachine:####3:vm-###',
-->    vmName = "#####",
-->    configFile = "[ds-###] VM/VM.vmx"

2026-02-29T13:15:06.507+10:00 warning vmware-dr[01421] [SRM@6876 sub=Replication opID=f1d35d92] [AutoConfigureDevices] Failed to auto-configure device with  unknown backing type:vim.vm.device.VirtualDisk.FlatVer2BackingInfo
2026-02-29T13:15:06.507+10:00 verbose vmware-dr[01421] [SRM@6876 sub=Replication opID=f1d35d92] [AutoConfigureDevices] Unable to auto-configure devicewith key 2000. No relevant mapping has been found.

Resolution

This is not an issue from Site recovery manager. Engage storage vendor to further investigate this issue.

Below steps can be followed as a workaround:

1. On SRM UI, Edit the local array manager and update with  NFS IP instead of FQDN.

2. On the VC UI, Select the datastore which is part of the array pair, Perform storage vMotion to migrate all the VM's to a different datastore.

3. Perform storage rescan by right clicking the host cluster.

3. On the "VC UI > Datastores"  right click > Unmount the NFS datastore.

4. On the "VC UI > Datastores"  right click >  Mount the NFS datastore with NFS IP instead of FQDN . So by doing this we are matching the NFS details with the array manager on the SRM UI. This makes sure that the backing device is correctly mapped with NFS details on the array manager.

5. Perform the "discoverDevices" on SRM UI > Array pair.

6. Once done , The protection group should be showing up with OK state.