Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Device discovery advanced options
The following three advanced options of the SRDF SRA control the behavior of device discovery:
The SRDF SRA allows for the discovery and failover to the Asynchronous site of a 3-site SRDF environment through the use of the FailoverToAsyncSite global advanced option.
By default, this option is disabled and when it is, the SRDF SRA will filter 3-site Asynchronous devices from discovery and instead look for Synchronous/Active devices to return to SRM. When this option is enabled, the SRDF SRA will permit the discovery of the 3-site Asynchronous target site devices and conversely exclude any Synchronous target site devices. Furthermore, in order to discover the proper devices the FailoverToAsyncSite option must be set identically for both the protection and recovery site SRDF SRAs.
Note: DO NOT change the FailoverToAsyncSite setting after protection groups and recovery plans have been configured. Doing so will invalidate all protection groups containing 3-site devices upon the next device discovery operation. This will prevent all failover or test failover operations until the setting has been restored and the devices rediscovered.
Prior to this parameter, the number of replicated devices returned by the SRDF SRA to SRM was not necessarily equal to the replicated devices actually in use by the target VMware environment. The discover LUNs process did not filter out devices according to masking information, so if the device met the SRDF configuration requirements of the SRA (regardless of whether or not it was part of the VMware environment) it would appear in the list. Importantly though this did not mean that the SRA or SRM could put them in a protection group and control these devices. The SRA returned all of the valid replicated devices that it had discovered to SRM and then SRM was responsible for deciding if it is a valid device from the VMware perspective (a RDM or a VMFS). If the device did not satisfy either of these two requirements it could not and would not be a candidate for a protection group.
This behavior introduced some complications though. In large SRDF environments the discovered devices list became very long at times and difficult for users to quickly parse. To simplify management, discovery behavior was enhanced with the option FilterNonVmwareDevices which has the capability to filter out non-VMware devices. The behavior of the SRDF SRA external RDF device discovery can now be controlled through the use of the global option.
FilterNonVmwareDevices is enabled by default in the SRDF SRA (but does require additional configuration to work which is described below). Enabling and configuring this option will cause the SRA to filter out devices not part of the VMware environment and they will no longer be listed in the discovered devices list in the SRM GUI and will not be exposed to SRM in any way.
Note: Enabling and using FilterNonVmwareDevices is optional. Configuring this option is not required for the functioning of the SRDF SRA. Although this option is enabled by default, if the configuration has not been completed, the SRA will simply ignore the parameter as if it were disabled, though it will record the error in the log file.
Note: When disabling or enabling the FilterNonVmwareDevices option, it must be disabled or enabled consistently for both SRAs. If these are set differently it could cause the discovery operation to encounter errors and fail.
As mentioned previously, there is a authorization configuration process that must be followed to provide the SRDF SRA access to the information it needs to filter out non-VMware devices. The SRDF SRA does not examine masking information on the VMAX/PowerMax to verify which devices are presented to the VMware environment. Instead it connects to its local vCenter and queries/compares the devices in vCenter inventory with the replicated devices that Solutions Enabler has returned to the SRDF SRA. Devices that are not present are then filtered out from the discovery list and therefore not output to SRM.
This authorization process is different for each SRM platform. They are both covered below.
Note: The user account(s) must have at least Read Only permissions (assigned to the user account within vCenter) to the vCenter server object and to the ESXi[1] server objects that host (or will host in the case of the recovery side) the virtual machines using the SRDF devices to be managed by SRM. The user must also have login access to the vCenter.
Note: Authorizations are not validated when created either with Windows or the Appliance, so failure to enter the correct credentials will result in failure during the rescan.
In order to enable filtering on Windows, an administrator must grant vCenter access for the Solutions Enabler install local to the SRM servers. It is important to note that this must be done on the local installations of Solutions Enabler on the SRM servers and not the remote Solutions Enabler server (if it exists). This is regardless of whether or not a remote Solutions Enabler server is configured for use by SRDF SRA control operations.
Authorizations are added using a Solutions Enabler CLI command shown below:
symcfg add authorization -host <FQDN of vCenter server[2]> -username <username[3]> - password <password> -vmware -namespace “vmware/vc”
In order to run Solutions Enabler commands from the Windows SRM server Windows Command Prompt, the user must either be issuing commands from the C:\Program Files\EMC\SYMCLI\bin\ directory or have the local Windows “Path” variable configured with this location. Furthermore, the environmental variable “SYMCLI_CONNECT_TYPE” on the SRM server must either be set to LOCAL or unset. If this variable is set globally to the host it can be temporarily overridden for only the duration of a single command prompt session by running the command:
set SYMCLI_CONNECT_TYPE=LOCAL
If a user is unsure of the current variables they can type set in the command prompt window and the variables will be listed. This will ensure that the authorization commands are issued to the local installation of Solutions Enabler and not to a remote Solutions Enabler host.
Once the variable has been set/verified the authorization can be added by executing similar to the following command:
symcfg add authorization -host ch-vcenter3.ebc.emc.local -username hostec -password password[4] -vmware -namespace “vmware/vc”
An authorization must also be added for the other site. An administrator must log in to the opposing site SRM server and execute similar to the following command:
symcfg add authorization -host ch-vcenter4.ebc.emc.local -username hostec -password password -vmware -namespace “vmware/vc”
Note: If there is more than one authorization present on a Windows server, the SRA will use the first in the list. Therefore be sure to check the authorizations using the command symcfg list authorization -vmware to ensure the correct one is listed first (or only).
To avoid running authorization commands on the container, credentials are added via the enableAutoSSLCertGen.sh in SRA 9.2.0.1 and higher. This script is run after the SRA is installed on the SRM Appliances. If the vCenter credentials were not supplied during the first run, the script can be run again at any time. This also holds true if the password changes.
Note: If multiple SRAs are in use on the SRM Appliance before installing the SRDF SRA version 9.2.0.1, the files it generates may be copied to the wrong docker container. Please follow this KB before running the script: https://www.dell.com/support/kbdoc/en-us/000196914. This issue is resolved in SRDF SRA version 10.0 and higher.
During a discovery operation the SRDF SRA will now log:
If non-VMware devices continue to show up there is usually an issue with one or both username/password provided during the script run on the SRM Appliance, or the Windows authorizations were not added. If the SRDF SRA is unable to connect, the SRA will log a series of messages in the EmcSrdfSra log as shown below:
[WARNING]: Failed to connect to Virtual Center. Please check if you have provided vCenter credentials in the Symmetrix Authorization DB.
[WARNING]: SRA will continue without filtering NON VMware devices.
The warning is generic so in this case the failure could be with authorizations on the array, or incorrect credentials or permissions of the user given in the script. Remember that the user provided during the script run must have login access to the vCenter.
For further information on any errors, users can consult the current viclient-<timestamp>.log created by the SRDF SRA. This log is located on the SRM server in the below locations, Windows and the Appliance respectively.
C:\Program Files\EMC\Solutions Enabler\log
/usr/emc/API/symapi/log
Common scenarios for errors can be seen in Table 13.
Table 13. Troubleshooting vCenter authorizations
Message logged in viclient.log | Common reason |
SymPwdDbEntryList2() Failed: No objects of the selected type were found | The -vmware option was missed in the command Or if using 9.2.0.1, it may indicate incorrect permissions on the .emcpwddb file. |
RetrieveCredentials Failed: No records were found in the authorization database. | The -namespace option is missing or incorrect |
ViClient::Connect: SOAP 1.1 fault: "":ServerFaultCode [no subcode] "Cannot complete login due to an incorrect user name or password." | Incorrect user name or password |
ViClient::Connect: SOAP 1.1 fault: SOAP-ENV:Client [no subcode] "Host not found" Detail: get host by name failed in tcp_connect() | Incorrect host name or the host name is not configured in DNS or the local hosts file |
ViClient::Connect: SOAP 1.1 fault: "":ServerFaultCode [no subcode] "Permission to perform this operation was denied." | The account supplied is valid but does not have permissions to access the vCenter server |
No error listed in viclient log but certain expected replicated devices are missing from device discovery list | User account entered has access to certain resources in vCenter but does not have access to the correct clusters |
Note that setting the SRA to filter devices could result in device errors during discovery as in Figure 40. This is expected and will not impact use.
Figure 40. Device error with FilterNonVmwareDevices
Note: For customers that wish to enable both FilterNonVmwareDevices and RdfDeviceMaskingControl (which allows for the R2 devices to not be presented), please refer to the section Masking requirements with Masking Control Enabled for configuration information.
The IgnoreDisconnectedStar option can be used to prevent the SRA from automatically connecting, protecting, and enabling a Star configuration when one of the legs is in a disconnected state. Before this option was made available, the SRA would perform the previously mentioned actions whether that environment was intended for SRM protection or not. Any other configuration that did not have a leg in the disconnected state would be skipped (e.g., protected, enabled, isolated, tripped). This option (disabled by default) will prevent this behavior when enabled. If one enables IgnoreDisconnectedStar, on both SRAs, it will no longer attempt these operations during discovery.
Note: Dell recommends setting IgnoreDisconnectedStar to ENABLED to prevent undesirable modification of the Star environment by the SRA.
[1] The configured account does not need login access to the ESXi servers—it only needs vCenter permissions for the ESXi object.
[2] The IP address of the vCenter server can be used in the case of a lack of a configured/available DNS server. Alternatively, the local hosts file on the Windows server can be configured with IP address/FQDN translations in place of a DNS server. Refer to Windows server documentation for information on editing the Windows hosts file.
[3] The user account does not have to be the account running the SRM service. It can be any local or domain account with sufficient access to vCenter.
[4] Optionally the password can be omitted and once the command has been executed a prompt will appear asking for a password in which the input password will be masked from view.