Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > SRDF SRA command detail
This section presents the syntactical form with argument and option descriptions for the EmcSrdfSra command. The use of the syntax is only for the Windows platform.
SYNTAX
EmcSrdfSra [-env | -version]
DESCRIPTION
This command provides the application interface to Dell SRDF Adapter. Its compound actions perform the necessary commands, in the proper order, to allow Site Recovery Manager to manage the recovery environment for VMAX and PowerMax arrays.
This command is normally invoked directly by VMware SRM.
ARGUMENTS
STDIN
The normal command options passing method scheme used by VMware SRM.
OPTIONS
-env
Displays the option settings from the options files. If the options are not specified in the options files, the adapter displays the default options.
-version
Returns the installed EmcSrdfSra version.
OPTIONS FILE
Dell SRDF Adapter provides the following options files under the folder ProgramData\EMC\EmcSrdfSra\Config in SRM Windows or through the SRM Appliance interface:
The options files are XML based. The options can be set to control some of the adapter features. A Document Type Definition (DTD) is a set of instructions that states which tags are usable and which (re)actions are created.
The following DTDs provide the definitions of all options files.
EmcSrdfSraGlobalOptions.xml comes pre-filled with default values. In most cases, these values do not need to be changed. However, if you need to change any of the default values, it is recommended that you understand the consequence of those changes before proceeding.
The following DTD describes EmcSrdfSraGlobalOptions.xml:
<!ELEMENT EmcSrdfSraGlobalOptions (Version?, SymapiDebug,
TestFailoverForce, TestFailoverWithoutLocalSnapshots, TerminateCopySessions,FailoverIfGoldCopyFails,
IgnoreActivatedSnapshots,FilterNonVmwareDevices,
CheckForVirtualDisks,FailoverToAsyncSite, SetReplicaTargetToReady,TestReplicaMaskingControl, RdfDeviceMaskingControl, ReverseReplicationDuringRecovery,IgnoreDisconnectedStar, AutoTargetDevice,AutoTargetDeviceReuse,
AutoTargetDeviceFreeTracks, ViClientIgnoreSecurityException)>
<!ELEMENT Version (#PCDATA)>
<!ELEMENT SymapiDebug (#PCDATA)>
<!ELEMENT TestFailoverForce (#PCDATA)>
<!ELEMENT TestFailoverWithoutLocalSnapshots (#PCDATA)>
<!ELEMENT TerminateCopySessions (#PCDATA)>
<!ELEMENT FailoverIfGoldCopyFails (#PCDATA)>
<!ELEMENT IgnoreActivatedSnapshots (#PCDATA)>
<!ELEMENT FilterNonVmwareDevices (#PCDATA)>
<!ELEMENT CheckForVirtualDisks (#PCDATA)>
<!ELEMENT SetReplicaTargetToReady (#PCDATA)>
<!ELEMENT TestReplicaMaskingControl (#PCDATA)>
<!ELEMENT RdfDeviceMaskingControl (#PCDATA)>
<!ELEMENT ReverseReplicationDuringRecovery (#PCDATA)>
<!ELEMENT FailoverToAsyncSite (#PCDATA)>
<!ELEMENT AutoTargetDevice (#PCDATA)>
<!ELEMENT AutoTargetDeviceReuse (#PCDATA)>
<!ELEMENT AutoTargetDeviceFreeTracks (#PCDATA)>
<!ELEMENT ViClientIgnoreSecurityException (#PCDATA)>
<!ELEMENT FailoverWithTargetlessGoldCopy (#PCDATA)>
The following is an example of EmcSrdfSraGlobalOptions.xml:
<?xml version="1.0" encoding="UTF-8"?>
<EmcSrdfSraGlobalOptions>
<Version>10.0</Version>
<SymapiDebug>0</SymapiDebug>
<TestFailoverForce>No</TestFailoverForce>
<TerminateCopySessions>Yes</TerminateCopySessions>
<TestFailoverWithoutLocalSnapshots>No</TestFailoverWitho utLocalSnapshots>
<FailoverIfGoldCopyFails>Yes</FailoverIfGoldCopyFails>
<IgnoreActivatedSnapshots>No</IgnoreActivatedSnapshots>
<FilterNonVmwareDevices>No</FilterNonVmwareDevices>
<CheckForVirtualDisks>No</CheckForVirtualDisks>
<FailoverToAsyncSite>No</FailoverToAsyncSite>
<SetReplicaTargetToReady>No</SetReplicaTargetToReady>
<TestReplicaMaskingControl>No</TestReplicaMaskingControl
>
<RdfDeviceMaskingControl>No</RdfDeviceMaskingControl>
<ReverseReplicationDuringRecovery>No</ReverseReplication DuringRecovery>
<IgnoreDisconnectedStar>No</IgnoreDisconnectedStar>
<AutoTargetDevice>No</AutoTargetDevice>
<AutoTargetDeviceReuse>No</AutoTargetDeviceReuse>
<AutoTargetDeviceFreeTracks>No</AutoTargetDeviceFreeTrac ks>
<ViClientIgnoreSecurityException>Yes</ViClientIgnoreSecu rityException>
<FailoverWithTargetlessGoldCopy>Yes</FailoverWithTargetl essGoldCopy>
</EmcSrdfSraGlobalOptions>
The following section describes the options in EmcSrdfSraGlobalOptions.xml.
Specifies whether SYMAPI debug logging is enabled. This option can be set either to 1 or 0. When set to 1, SYMAPI debug logging is enabled. By default this option is disabled. The name of the SYMAPI debug log file is SYMAPI_debug_<YYYYMMDD>.log.
For example:
<SymapiDebug>1</SymapiDebug>
Forces the test failover operation to proceed regardless of the state of the SRDF link (the lone exception is transmit idle). This parameter permits failover testing when the protection site is unavailable. The possible values for this option are YES and NO. By default, the value is set to NO.
For example:
<TestFailoverForce>No</TestFailoverForce>
Performs a test failover operation directly off of R2 devices without a need to use local TimeFinder replica devices. In case of SRDF/Star, the target site is Isolated when this option is enabled. During Cleanup, the Isolated site is connected back. The possible values are YES and NO. By default, the value is set to NO.
For example:
<TestFailoverWithoutLocalSnapshots>No</TestFailoverWithoutLocalSnapshots>
Forces the test failover operation to terminate the clone snap and VP Snap sessions when the test failover operation resets storage. When this option is enabled, SRA removes the devices from the device group or composite group during cleanup. The possible values are YES and NO. By default, the value is set to NO.
For example:
<TerminateCopySessions>No</TerminateCopySessions>
When the goldcopy backup operation fails prior to failover, this option can be set or unset if failover of the LUNs is desired. The possible values for this option are YES and NO. By default, the value is set to YES.
For example:
<FailoverIfGoldCopyFails>Yes</FailoverIfGoldCopyFails>
Ignores activated TimeFinder Snap snapshot, TimeFinder clone, or TimeFinder VP snap sessions and allows the test failover operation to complete successfully. In the case of SRDF/Star, Isolated target site is ignored when this option is enabled. The possible values are YES and NO. By default, the value is NO.
For example:
<IgnoreActivatedSnapshots>No</IgnoreActivatedSnapshots>
Filters out all the SRDF devices that are not visible to VMware environment. This must be set to the same value at both sites. The possible values are YES and NO. By default, the value is set to Yes.
For example:
<FilterNonVmwareDevices>Yes</FilterNonVmwareDevices>
Checks if the target TimeFinder devices for test failover or goldcopy are already used VMware environment as virtual disks (Raw device mappings or Flat virtual disks). The possible values are YES and NO. By default, the value is set to No.
For example:
<CheckForVirtualDisks>No</CheckForVirtualDisks>
Note: FilterNonVmwareDevices and CheckForVirtualDisks options require VMware vCenter user credentials configured in the local Solutions Enabler authorization table. Make sure you have the right credentials configured using SYMCLI.
Performs recovery operations between the sites connected with SRDF/A link. This option is applicable only when SRDF/Star and 3 site configurations are used in the Site Recovery Manager environment. The possible values are YES and NO. By default, the value is set to No. This option requires the same value set at both sites.
For example:
<FailoverToAsyncSite>No</FailoverToAsyncSite>
Tries to set the target SRDF device to Ready state. For TestFailoverWithoutLocalSnapshots, the target SRDF device is set back to Not Ready during cleanup. For the Recovery operation, the source device will be set to Not Ready after the Reprotect. The possible values are YES and NO. By default, the value is set to No.
For example:
<SetReplicaTargetToReady>No</SetReplicaTargetToReady>
When enabled SRA tries to reverse the replication direction at the end of the recovery operation. This is supported only in planned migration recovery. This option should be disabled for Disaster recovery. Also this is not supported in Star configurations. The possible values are YES and NO. By default, the value is set to NO.
For example:
<ReverseReplicationDuringRecovery>Yes</ReverseReplicationDuringRecovery>
When enabled:
This option uses the masking view information provided in EmcSrdfSraDeviceMaskingControl.xml file. Possible values are YES and NO. By default, the value is set to No.
For example:
<RdfDeviceMaskingControl>No</RdfDeviceMaskingControl>
When enabled, SRA tries to mask or unmask the TimeFinder devices and RDF2 devices (if TestFailoverWithoutLocalSnapshots is enabled) to the recovery site. This option is only applicable to test recovery operations. Possible values are YES and NO. By default, the value is set to No.
For example:
<TestReplicaMaskingControl>No</TestReplicaMaskingControl>
When enabled (set to YES), SRA does not try to bring up any Star configuration (even the ones protected by Site Recovery Manager) irrespective of the state of the Star.
By default, this option is set to NO, which means that SRA tries to bring up the Star during discover devices.
For example:
<IgnoreDisconnectedStar>No</IgnoreDisconnectedStar>
When this option is enabled, SRA creates target devices dynamically to link snapshots during a Test operation. By default, these devices present to the same hosts to which corresponding R2 devices are visible. To present these dynamically created target devices to a different host, set the corresponding R2 device as a placeholder in EmcSrdfSraMaskingControl.xml file under SrcDeviceList tag.
For example:
<MaskView>
<ArrayId> ArrayID </ArrayId>
<StorageGroup> Storage Group</StorageGroup>
<SrcDeviceList>
<Device>R2 devices set as placeholder for dynamically created target device</Device>
</SrcDeviceList>
</MaskView>
Also when this option is enabled, these target devices would be unpresented from hosts as well as deleted during a Cleanup operation (if the AutoTargetDeviceReuse global option is not set).
This release supports ONLY SnapVX copy type for the dynamic target devices. By default copy mode is NOCOPY when no valid CopyInfoBlock is found in the EmcSrdfSraTestFailoverConfig.xml file. To use copy mode as COPY, EmcSrdfSraTestFailoverConfig.xml should be filled with valid CopyInfoBlock, leaving Target tags empty in DevicePairs.
When enabled along with AutoTargetDevice, SRA retains dynamically created target devices and adds the source to target mapping in the EmcSrdfSraTestFailoverConfig.xml file. SRA will reuse these devices in subsequent operations until a Cleanup operation is called with disabled AutoTargetDeviceReuse which also removes mapping from the EmcSrdfSraTestFailoverConfig.xml file. Whenever SRA modifies EMCSrdfSraTestFailoverConfig.xml content, the original file content will be preserved by adding the suffix ".EMCSRDFSRA.bak_YYMMDDhhmmssuuu" to the original file where year is YY, month is MM, date is DD, hour is hh, minutes are mm, seconds are ss and microseconds are uuu.
For example:
<AutoTargetDeviceReuse>Yes</AutoTargetDeviceReuse>
When enabled along with AutoTargetDevice and AutoTargetDeviceReuse flags, SRA will free all tracks possible of the re-used auto target device in a Cleanup operation.
Notes on using AutoTargetDeviceFreeTracks:
While operating with this flag, all prerequisite of using the flag AutoTargetDeviceReuse must to be met.
While the free tracks operation is in progress as part of Cleanup operation, the re-used auto TDEV(s) will not be present in the applicable storage groups. However, once the Cleanup operation completes, the device(s) will be present in the applicable storage groups.
For example:
<AutoTargetDeviceFreeTracks>Yes</AutoTargetDeviceFreeTracks>
SRA uses ViClient to connect with vCenter Server. This flag is used to Ignore Security Exceptions while establishing a secure connection.
Enable this flag to establish a secure connection by using existing user verified truststore certificates, the value options are YES and NO. By default, the value is set to Yes.
For example:
<ViClientIgnoreSecurityException>Yes<\ViClientIgnoreSecurityException>
When this option is enabled, SRA supports targetless gold copy for a failover or failback operation. This avoids having additional devices as TimeFinder targets when linking it to snapshots.
For example:
<FailoverWithTargetlessGoldCopy>No</FailoverWithTargetlessGoldCopy>
The required XML configuration file <Target> XML tag would be empty with respective protection.
This file is used to specify device pairs for test failover operations. The following DTD describes EmcSrdfSraTestFailoverConfig.xml:
<!ELEMENT TestFailoverInfo (Version?, CopyInfo+)>
<!ELEMENT Version (#PCDATA)>
<!ELEMENT CopyInfo (ArrayId?, CopyType?, DeviceList?, CopyMode?)>
<!ELEMENT ArrayId (#PCDATA)>
<!ELEMENT CopyType (#PCDATA)>
<!ELEMENT CopyMode (#PCDATA)>
<!ELEMENT DeviceList (DevicePair+)>
<!ELEMENT DevicePair (Source, Target)>
<!ELEMENT Source (#PCDATA)>
<!ELEMENT Target (#PCDATA)>
The following is an example of EmcSrdfSraTestFailoverConfig.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<TestFailoverInfo>
<Version>10.0</Version>
<CopyInfo>
<ArrayId>000190300186</ArrayId>
<CopyType>SNAPVX</CopyType>
<CopyMode>NOCOPY</CopyMode>
<DeviceList>
<DevicePair>
<Source>4D8</Source>
<Target>4DE</Target>
</DevicePair>
<DevicePair>
<Source>4D9</Source>
<Target>4DF</Target>
</DevicePair>
</DeviceList>
</CopyInfo>
</TestFailoverInfo>
The following section describes the options in EmcSrdfSraTestFailoverConfig.xml.
Contains all of the elements for the test failover operations.
The CopyInfo element defines device pairs for a specific copy type on a VMAX/PowerMax array.
You can specify multiple CopyInfo blocks within TestFailoverInfo or GoldCopyInfo with different array IDs.
For example:
<ArrayId>000190300186</ArrayId>
Specifies the type of replication technology for the test failover or goldcopy operation. The possible values are VSE (TimeFinder/VP Snap), clone, snap (only for VMAX 20K, and 40K arrays) and SnapVX (only for VMAX 100K, 200K, and 400K arrays).
For example:
<CopyType>CLONE</CopyType>
Specifies the type of the data copy used in the TimeFinder/SnapVX replication. This is applicable only to the TimeFinder/SnapVX replication technologies. The possible values are COPY and NOCOPY.
For example:
<CopyMode>COPY</CopyMode>
Specifies the device pair information. This is necessary to perform the test failover operation. Each device pair represents source and target device pairs. For all copy types, the source device is the R2 device on the recovery site. For VSE type, the targets are TDEV devices. For clone types, the target devices are the clone targets, and for snap types, the target devices are the VDEVs. For SnapVX types, the target devices are TDEV devices.
For example:
<DeviceList>
<DevicePair>
<Source>4D8</Source>
<Target>4DC</Target>
</DevicePair>
<DevicePair>
<Source>4D9</Source>
<Target>4DD</Target>
</DevicePair>
</DeviceList>
This file is used to specify device pairs for protection site goldcopy backup operations.
The following DTD describes EmcSrdfSraProtectionSiteGoldcopyConfig.xml:
<!ELEMENT ProtectionSiteGoldcopyInfo (Version?, CopyInfo+)>
<!ELEMENT Version (#PCDATA)>
<!ELEMENT CopyInfo (ArrayId?, CopyType?, DeviceList?, CopyMode?)>
<!ELEMENT ArrayId (#PCDATA)>
<!ELEMENT CopyType (#PCDATA)>
<!ELEMENT CopyMode (#PCDATA)>
<!ELEMENT DeviceList (DevicePair+)>
<!ELEMENT DevicePair (Source, Target)>
<!ELEMENT Source (#PCDATA)>
<!ELEMENT Target (#PCDATA)>
The following is an example of EmcSrdfSraProtectionSiteGoldcopyConfig.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<ProtectionSiteGoldcopyInfo>
<Version>10.0</Version>
<CopyInfo>
<ArrayId>000190300186</ArrayId>
<CopyType>CLONE</CopyType>
<CopyMode>NOCOPY</CopyMode>
<DeviceList>
<DevicePair>
<Source>4D8</Source>
<Target>4DC</Target>
</DevicePair>
<DevicePair>
<Source>4D9</Source>
<Target>4DD</Target>
</DevicePair>
</DeviceList>
</CopyInfo>
</ProtectionSiteGoldCopyInfo>
The options in EmcSrdfSraProtectionSiteGoldCopyConfig.xml are the same as those for EmcSrdfSraTestFailoverConfig.xml.
This file is used to specify device pairs for recovery site goldcopy backup operations.
The following DTD describes EmcSrdfSraRecoverySiteGoldcopyConfig.xml:
<!ELEMENT RecoverySiteGoldcopyInfo (Version?, CopyInfo+)>
<!ELEMENT Version (#PCDATA)>
<!ELEMENT CopyInfo (ArrayId?, CopyType?, DeviceList?, CopyMode?)>
<!ELEMENT ArrayId (#PCDATA)>
<!ELEMENT CopyType (#PCDATA)>
<!ELEMENT CopyMode (#PCDATA)>
<!ELEMENT DeviceList (DevicePair+)>
<!ELEMENT DevicePair (Source, Target)>
<!ELEMENT Source (#PCDATA)>
<!ELEMENT Target (#PCDATA)>
The following is an example of EmcSrdfSraRecoverySiteGoldcopyConfig.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<RecoverySiteGoldcopyInfo>
<Version>10.0</Version>
<CopyInfo>
<ArrayId>000190300186</ArrayId>
<CopyType>CLONE</CopyType>
<CopyMode>NOCOPY</CopyMode>
<DeviceList>
<DevicePair>
<Source>4D8</Source>
<Target>4DC</Target>
</DevicePair>
<DevicePair>
<Source>4D9</Source>
<Target>4DD</Target>
</DevicePair>
</DeviceList>
</CopyInfo>
</RecoverySiteGoldCopyInfo>
The options in EmcSrdfSraRecoverySiteGoldCopyConfig.xml are the same as those for EmcSrdfSraTestFailoverConfig.xml.
This file is used to specify VMAX device masking details for SRDF and TimeFinder devices.
The following DTD describes EmcSrdfSraDeviceMaskingControl.xml:
<!ELEMENT DeviceMaskingInfo (Version?, MaskViewList?)>
<!ELEMENT Version (#PCDATA)>
<!ELEMENT MaskViewList (MaskView+)>
<!ELEMENT MaskView (ArrayId?, StorageGroup?, DeviceList?)>
<!ELEMENT ArrayId (#PCDATA)>
<!ELEMENT StorageGroup (#PCDATA)>
<!ELEMENT DeviceList (Device+)>
<!ELEMENT DevicePair (#PCDATA)>
The following is an example of EmcSrdfSraDeviceMaskingControl.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<DeviceMaskingInfo>
<Version>10.0</Version>
<MaskViewList>
<MaskView>
<ArrayId>000194900390</ArrayId>
<StorageGroup>spea219_390</StorageGroup>
<DeviceList>
<Device>0422c</Device>
<Device>044b6</Device>
</DeviceList>
</MaskView>
</MaskViewList>
</DeviceMaskingInfo>
The following section describes the options in EmcSrdfSraDeviceMaskingControl.xml:
A list of MaskViews. Multiple MaskView blocks can be used for different array IDs.
The MaskView information for a specific array ID.
The array ID for which device masking information is provided.
A container of a storage devices. A masking view includes a storage group, a port group, and an initiator group. When a masking view is created, the devices in the storage group become visible to the host. This option takes the name of the storage group to which a set of devices should be added or removed.
A list of devices to be added or removed from storage group.
The ID of a VMAX/PowerMax device that needs to be added or removed from a storage group. A device can be either an SRDF device or a TimeFinder device.
SRA does not check for duplicate Device IDs. The first MaskView under which a Device ID is found is used in the device masking operation.