Home > Storage > PowerMax and VMAX > Storage Admin > Dell PowerMax and VMware vSphere Configuration Guide > Detaching the remote volume
For this example, both an R2 and a linked target of that R2 are presented to the remote cluster. Both devices are present, as shown in the Reviewing the Storage Devices screen in Figure 164. These devices are using the mobility ID, rather than the compatibility ID, yet it makes no difference.
Checking the ESXi host, the snapshot linked target cannot be resignatured because the R2 is also presented, as shown in Figure 165.
Before resignaturing, the R2 device must now be detached using the vSphere functionality. In step 1 select the R2 device in the devices window in the vSphere Client as in Figure 166. Select Detach in step 2 and confirm in step 3 all hosts in the cluster.
Note: Detaching the device is a VMware function and has no impact on the array mapping or masking of the device to the ESXi host.
The device is detached once confirmed. The device does not disappear from the devices screen, but lists as Detached, as shown in Figure 167.
Now that the device has been detached, when esxcfg-volume -l is run, only the BCV is shown. It is available for resignaturing and mounting as seen in Figure 168.
Afterward when using the vSphere Client, the R2 no longer appears. Only the linked target device appears, as shown in the New Datastore wizard in Figure 169.
The user can now choose among all three options that are shown in Figure 170: keeping the signature (default), assigning a new signature, or formatting the disk.
The best practice is to always assign a new signature to the volume to prevent any problems when the R2 is reattached.
Note: If the user chooses NOT to resignature the volume and mounts it with the same signature, the R2 cannot be re-attached. The user receives an error that states the operation is not allowed in the current state. This denial is because ESXi recognizes the volumes have the same signature. Since one volume is already mounted, a second volume cannot, in a sense, occupy the same space. The resolution is to unmount the datastore and detach the underlying device copy before attempting to reattach the R2.
When a new signature is created, VMware automatically assigns a prefix to the datastore that is “snap-xxxxxxxx-.” The “xxxxxxxx” part of the name is system-generated. In this example, once the datastore is mounted, it appears as snap-76b6f9ee-R1_883_3A_DS as in Figure 171. Any VMs in the datastore can now be registered.
With the completion of the resignature and mount, the R2 can now be re-attached. Doing so is a best practice to ensure that should the production site fail, it would be available immediately.
Note: If the signature is kept, it may be necessary to use esxcfg-volume to mount the datastore on the other hosts. Similarly, unmounting requires the CLI as the “Unmount Datastore” is grayed-out.
To perform this task, return to the devices screen and locate the grayed-out R2 device. Right-click the device and select Attach from the menu as shown in Figure 172. If there are multiple detached devices, use VSI to correlate the runtime names with the correct devices.
Unlike detaching, the device must be attached on each ESXi host. When the task completes the device returns to “Attached” as in Figure 173.
Note: It is possible to unmask the R2 from the remote ESXi hosts instead of detaching the device. You can then remask it when the resignature and mounting are complete, rescanning the HBAs each time. This procedure is not a recommended best practice, and can lead to complications.