Search the VMware Knowledge Base (KB)
View by Article ID

Creating a protection group with NFS datastore fails in VMware vCenter Site Recovery Manager 4.x and 5.x (2009622)

  • 1 Ratings


When using storage replication adapters (SRA) that support NFS volume replication, you experience these symptoms:
  • Under the SRA Properties > Devices, NFS volume replication pairs show up correctly but the datastore column does not show any datastore associated with the NFS volume replication pairs.
  • Under Protection groups, the Create new protection group link is grayed out.
  • Site Recovery Manager is unable to calculate any datastore groups.
  • In the Site Recovery Manager logs, you see datastore group entries similar to:

    <YYYY-MM-DD>T<Time >.673-05:00 [06712 info 'DatastoreGroupManager' opID=4388fd21] Calculating datastore groups for array pair 'array-pair-1640'
    <YYYY-MM-DD>T<Time>.673-05:00 [06712 verbose 'DatastoreGroupManager' opID=4388fd21] Matched 0 devices of total 33
    <YYYY-MM-DD>T<Time>.673-05:00 [06712 warning 'DatastoreGroupManager' opID=4388fd21] No replicated datastores found for array pair 'array-pair-1640'
    <YYYY-MM-DD>T<Time>.673-05:00 [06712 verbose 'DatastoreGroupManager' opID=4388fd21] Recomputed datastore groups for array pair 'array-pair-1640': 0 replicated datastores, 0 replicated RDMs, 0 free devices, 0 datastore groups

  • After upgrading SRM 4.x to SRM 5.x and use the SRM migration tool to import SRM 4.x configuration (inventory mapping, protection groups, and recovery plans) into SRM 5.x, the tool fails to import protection groups or recovery plans.
  • The source NFS volumes are mounted on the ESX/ESXi hosts using the NFS server FQDN (fully qualified domain name) or the NFS server short name and the SRM server. When you edit array managers or refresh the SRA replication device list, you see these entries in the vmware-dr.log file:

    <YYYY-MM-DD>T<Time >.592-06:00 [10056 trivia 'Storage' opID=46f96b1a] Skipping unknown NFS server 'Prod_NFS_Svr1'
    <YYYY-MM-DD>T<Time>.592-06:00 [10056 trivia 'DatastoreGroupManager' opID=46f96b1a] No match found for datastore 'datastore-70760: Prod_NFS_Svr1_Vol-01'
    <YYYY-MM-DD>T<Time>.592-06:00 [10056 trivia 'Storage' opID=46f96b1a] Skipping unknown NFS server 'Prod_NFS_Svr1'
    <YYYY-MM-DD>T<Time>.592-06:00 [10056 trivia 'DatastoreGroupManager' opID=46f96b1a] No match found for datastore 'datastore-70779: Prod_NFS_Svr1_Vol-02'

  • SRA response logs to the discoverDevices command report the storage ports and the NFS volume replication pairs correctly:

    <YYYY-MM-DD>T<Time >.861-06:00 [08624 info 'SraCommand' opID=1EBBBF83-0000002D] discoverDevices exited with exit code 0
    <YYYY-MM-DD>T<Time>.862-06:00 [08624 verbose 'SraCommand' opID=1EBBBF83-0000002D] discoverDevices responded with:
    --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    --> <Response xmlns="">
    --> <ReplicatedDevices>
    --> <StoragePorts>
    --> <StoragePort type="NFS" id=""/>
    --> </StoragePorts>
    --> <SourceDevices>
    --> <SourceDevice state="read-write" id="fs144-144">
    --> <Name>Prod_NFS_Svr1_Vol-01</Name>
    --> <Identity>
    --> <NfsName>/Prod_NFS_Svr1_Vol-01</NfsName>
    --> </Identity>
    --> <TargetDevice key="349_APM00099999728_0000_342_APM00099999121_0000"/>
    --> </SourceDevice>
    --> <SourceDevice state="read-write" id="fs146-146">
    --> <Name>Prod_NFS_Svr1_Vol-02</Name>
    --> <Identity>
    --> <NfsName>/Prod_NFS_Svr1_Vol-02</NfsName>
    --> </Identity>
    --> <TargetDevice key="352_APM00099999728_0000_345_APM00099999121_0000"/>
    --> </SourceDevice>
    --> </SourceDevices>
    --> </ReplicatedDevices>
    --> </Response>


This issue occurs when SRM is unable to calculate datastore groups and associate them with replicated NFS devices.
Site Recovery Manger cannot match the Fully Qualified Domain Name (FQDN) or short name of the NFS server that is used to mount the source NFS volumes on the ESX/ESXi hosts with the StoragePort information that is reported in the SRA response to the discoverdevices command. For example:
-->     <StoragePorts>
-->        <StoragePort type="NFS" id=""/>
-->     </StoragePorts>

In this example, in the SRA response log, the storage port reported by the SRA is The SRM log shows that in the datastore group calculation, SRM skips the NFS server Prod_NFS_Svr1  because to SRM, the NFS server is unknown. The NFS server is unknown because SRM cannot match IP address to the NFS server Prod_NFS_Svr1


To resolve this issue, calculate the datastore groups and associate them with replicated NFS devices in SRM:

Note: The resolution contains two parts that must be implemented.
  1. On the SRM site where NFS array managers are configured, edit the array manager that is connected to the NFS array and add the short name or the FQDN of the NFS server in the Include ports field which is known as the Opaque field in SRM terminology. Whether you use the FQDN or the short name for the NFS server, it must match the NFS server name used on the ESX/ESXi hosts for mounting the NFS volumes from this NFS array. Otherwise SRM cannot match the two together.
  2. If you are using the EMC VNX SRA together with the EMC Replication Enabler (for Celerra), you must upgrade the Replication Enabler to version 5.0.9. Because earlier versions of the replication enabler do not process the Opaque field specified in the array manager. If you are using the NetApp SRA for the NetApp NFS arrays, this SRA is already aware of Opaque field and can process it if specified in the array manager.

    After implementing the resolution, in the input XML file for Site Recovery Manager discoverdevices command, you see entries similar to:

    --> <?xml version="1.0" encoding="UTF-8"?>
    --> <Command xmlns="">
    --> <Name>discoverDevices</Name>
    --> <OutputFile>C:\Windows\TEMP\vmware-SYSTEM\sra-output-14-0</OutputFile>
    --> <StatusFile>C:\Windows\TEMP\vmware-SYSTEM\sra-status-15-0</StatusFile>
    --> <LogLevel>trivia</LogLevel>
    --> <LogDirectory>C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs\SRAs\EMC VNX SRA</LogDirectory>
    --> <Connections>
    --> <Connection id="EMC Storage">
    --> <Addresses>
    --> <Address id="emcstorage.address"> </Address>
    --> </Addresses>
    --> <Username>***</Username>
    --> <Password>***</Password>
    --> <Opaques>
    --> <Opaque id="replicator.include.storage_ports">Prod_NFS_Svr1</Opaque>
    --> </Opaques>
    --> </Connection>
    --> </Connections>
    --> <DiscoverDevicesParameters>
    --> <ArrayId>APM000999997280000-server_2</ArrayId>
    --> <PeerArrayId>APM000999991210000-server_2</PeerArrayId>
    --> </DiscoverDevicesParameters>
    --> </Command>

  3. In the SRA response XML file to the SRM discoverdevices command, you see entries similar to:

    --> **** Response ****
    --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    --> <Response xmlns="">
    --> <ReplicatedDevices>
    --> <StoragePorts>
    --> <StoragePort type="NFS" id="Prod_NFS_Svr1"/>
    --> </StoragePorts>

    Note: In the SRA response, the storage port reported is not an IP address as it was the case earlier. The storage port reported now is exactly the same as the one we specified in the opaque field in the array manager. For example, Prod_NFS_Svr1.

If the resolution is not successful, you can mount the NFS volumes on the ESX/ESXi hosts using the NFS server IP address(es) instead of the FQDN or short names. The NFS IP address(es) must match exactly the IP addresses reported in the StoragePorts section of the SRA response. For example,

See Also

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.


  • 1 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.

What can we do to improve this information? (4000 or fewer characters)

Please enter the Captcha code before clicking Submit.
  • 1 Ratings