Home > Storage > PowerMax and VMAX > Storage Admin > Dell PowerMax and VMware vSphere Configuration Guide > ESXi and duplicate extents
In vSphere, mounting a copy of a remote production volume requires some thought and planning. The issue that one encounters 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 will, therefore, require the R2 device to be resignatured when mounting.[1]
The same problem also exists when cloning the R2 to another device using TimeFinder software. The linked target device has a different WWN (just like the R2) and therefore putting the R1 signature on that volume will also result in ESXi requiring a resignature. What complicates the situation, however, is now ESXi sees not just the R2 but also the copy of the R2 and recognizes that they have the same signature. When ESXi is presented with duplicates, by default it will not allow the user to mount either of the VMFS volumes.
Using the CLI, one can see if duplicates exist. Figure 174 shows an example of what ESXi will report when only the R2, which is identified in the figure by the last three digits of the network address authority number (naa), or 841:1, is masked to the host.
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. Note that if the VMFS is VMFS-6 format, the volume scan will be preceded by “Scanning for VMFS-6 host activity.” A VMFS-5 volume will simply begin with “VMFS UUID...”
Figure 174. An R2 device on the remote ESXi host which can be resignatured
Now if a linked target device, with the naa ending 430 as seen in Figure 175, of the R2 in the previous Figure 174 is masked to the host, and the same command is run on the ESXi host, the results are much different, as seen in Figure 175. ESXi recognizes that the devices have the same VMFS volume signature. When presented with this situation, ESXi will not allow either device to be mounted or resignatured.
Figure 175. An R2 device and its copy on the remote ESXi host that cannot be resignatured
If an attempt is made in the vSphere Client to resignature and mount this datastore, it will be prevented. In the vSphere Client, both the R2 and linked target are seen in Figure 176.
Figure 176. Duplicate extents in the vSphere Client
Running the add storage wizard, the user is presented with a list of devices to use for mounting or creating a new datastore. In Figure 177 both the R2 and linked target are displayed along with the VMFS label, which is the same for both, SRM_ASYNC_1.
Figure 177. Attempt to mount duplicate extents
If the user proceeds, the only option presented will be to format the disk and thus the user would lose the datastore on the linked target. This is shown in Figure 178.
Note: If the R2 device is chosen by accident during this process, the format will fail as the R2 is a write disabled device.
Figure 178. Attempt to mount duplicate extents permits format only
Fortunately, this situation can be avoided. There are a few methodologies that can be employed, but only two are recommended and presented. These will be addressed in the following sections.
[1] The user can force mount the volume with the same signature if desired. The only exception to this is when using VMware SRM.