Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Test failover with non-VMware devices
In most environments, not all applications have been virtualized. Consequently, there are environments that have a mixture of virtual and physical servers, many of which have dependencies across their hosted applications regardless of the fact that they have different underlying server architectures. During a disaster recovery test, enterprise consistent copies of application data across physical servers and virtual machines may be required in order for the test to be a true success. SRM does not have a built-in mechanism for including replicated devices that are not presented to the VMware environments. SRM will exclude them in datastore groups if they do not host VMFS volumes or are in use as Raw Device Mappings.
Nevertheless, there is a way to bypass SRM to have the SRA control devices that are not presented to or in use by the VMware environment. This way, during test failover, the SRA can create and split TimeFinder copies of R2 devices that are not specified explicitly in the protection group. In order for this to work there are a few requirements:
Note: Dell does not recommend enabling TestReplicaMaskingControl when the SRA is configured to manage non-VMware devices. The SRDF SRA requires that all devices be configured in the masking control file and since the SRA cannot distinguish between VMware and non-VMware devices, the SRA will then attempt to present the non-VMware devices to the recovery cluster. Consequently, users should disable automated masking control and manually present devices prior to test recovery.
Note: If the option TestFailoverWithoutLocalSnapshots is enabled the test failover configuration file does not need to be populated with the VMware or non-VMware devices. Nevertheless, the R2 devices do need to be in the remote device/composite group.
Non-VMware devices must be manually entered into the test failover configuration file through the use of an XML or text editor. For this example, an external SRDF device pair is required for proper functioning of the VMware environment during production (e.g., a physical database that has not yet been virtualized) and therefore a consistent copy must be present during the test as well. The R2 device of this pair is device 28D. Using the details of this device the user must manually find a valid TimeFinder target device or create a new one. Once the device has been identified or created, that device number must be added along with the non-VMware R2 to the test failover configuration file. In this example, device 223 is a valid and available TimeFinder/SnapVX target and will be paired with the R2 device 28D. Using a text editor this pair will be added within the <DeviceList> stanza into a new <DevicePair> stanza.
Figure 89 shows the test failover options file after the non-VMware pair has been added manually.
For every non-VMware device, a new <DevicePair> line should be created and populated. Once the configuration file is complete it should be saved. At this point, the test recovery can be executed normally. The SRA will add the TimeFinder target devices in configuration file to the device/composite group and perform the necessary TimeFinder operations to allow the targets to become usable to the host. Do not add the targets to the device/composite groups manually.
Note: If devices are present in the R2 device/composite group and the user does not wish for the SRA to create TimeFinder copies of them, the devices must be removed from the group. If they remain in the group and they are not listed in the options file, the test failover operation will fail.
It is important to note that the non-VMware devices will not be controlled in any way by the SRA once they are read/write enabled. Since they are not in the VMware environment, the SRA has no method of presenting them to a host. Therefore, the user must perform whatever functions are necessary for the non-VMware hosts to be able to use the TimeFinder copies that the SRA created. If the virtual machines depend on the non-VMware applications to be running before they can power on, it would be advisable to add a pause into the recovery plan before SRM powers on the virtual machines so steps can be taken by the administrator to prepare the applications external to the VMware environment.