Home > Storage > PowerMax and VMAX > Storage Admin > Dell PowerMax and VMware vSphere Configuration Guide > Cloning at disaster protection site with vSphere
Creating copies of volumes with TimeFinder software is covered in Copying virtual machines with TimeFinder, and is not repeated here. In particular, as this section is concerned with production environments, Using TimeFinder/SnapVX with hot virtual machines should be consulted. That section details the use of Dell Consistency technology. That technology ensures that the point-in-time copy of the volumes is in a dependent-write consistent data state and the virtual machine in the datastore are restartable.
The assumption is made that the system administrator has mapped and masked all devices to one or more ESXi hosts that are involved in this process. The ESXi host sees the R2 remote devices and any SnapVX targets. For more information about this procedure, see Adding and removing Dell PowerMax devices to VMware ESXi hosts.
In vSphere, mounting a copy of a remote production volume requires some thought and planning. The issue that you encounter is that when the R2 is cloned, the VMFS volume signature is copied over.
The signature is generated in part from the WWN of the device. Since the R2 has a different WWN than the R1 device, ESXi sees the signature as invalid. It requires the R2 device to be resignatured when mounting.
Note: The user can force mount the volume with the same signature if wanted. The only exception is when using VMware SRM.
The same problem also exists when cloning the R2 to another device using TimeFinder software. The linked target device has a different WWN (like the R2). Putting the R1 signature on that volume also results in ESXi requiring a resignature. What complicates the situation is that now ESXi sees not just the R2 but also the copy of the R2. It recognizes that they have the same signature. When ESXi is presented with duplicates, by default it does not allow the user to mount either of the VMFS volumes.
Using the CLI, you can see if duplicates exist. Figure 159 shows an example of what ESXi reports when only the R2 is masked to the host. R2 is identified in the figure by the last three digits of the network address authority number (naa), or 841:1.
Using the command esxcfg-volume -l, ESXi displays only the R2 that is masked to the host and reports that it can both be mounted and resignatured. ESXi has recognized that the signature is not valid for the device because the WWN is different than the R1. If the VMFS is VMFS-6 format, “Scanning for VMFS-6 host activity” precedes the volume scan. A VMFS-5 volume begins with “VMFS UUID....”
Suppose a linked target device with the naa ending in 430 (Figure 160) of the R2 (Figure 159) is masked to the host. If the same command is run on the ESXi host, the results are different (Figure 160). ESXi recognizes that the devices have the same VMFS volume signature. When presented with this situation, ESXi does not allow either device to be mounted or resignatured.
If an attempt is made to resignature and mount this datastore using the vSphere Client, it is prevented. In the vSphere Client, both the R2 and linked target are seen in Figure 161.
The add storage wizard presents the user with a list of devices to use for mounting or creating a datastore. In Figure 162 both the R2 and linked target are displayed along with the VMFS label, which is the same for both, SRM_ASYNC_1.
If the user proceeds, the only option that is presented is to format the disk. The user would lose the datastore on the linked target. This option is shown in Figure 163.
Note: If the user accidentally chooses the R2 device during this process, the format fails as the R2 is a write disabled device.
Fortunately, this situation can be avoided. There are a few methodologies that can be employed, but only two are recommended and presented. These methodologies are addressed in the following sections.