Home > Storage > PowerMax and VMAX > Storage Admin > Dell PowerMax and VMware vSphere Configuration Guide > Detaching the remote volume
One of the benefits that comes with vSphere is that the user is able to “detach” a device from the ESXi host. This was discussed in All Paths Down (APD) and Permanent Device Loss (PDL) in relation to the All Paths Down condition. In a situation where duplicate extents exist, if one device is detached from the ESXi host, ESXi will then see a single snapshot VMFS volume and revert to the behavior of being able to resignature and mount the device. The next section will walk through an example of this using the vSphere Client.
For this example, both an R2 and a linked target of that R2 are presented to the remote cluster. Reviewing the Storage Devices screen in Figure 179, both devices are present. Note that these devices are using the mobility ID, rather than the compatibility ID, yet it makes no difference.
Checking the ESXi host, currently the snapshot linked target cannot be resignatured because the R2 is also presented. This is shown in Figure 180.
Before resignaturing, the R2 device now must be detached using the vSphere functionality. In step 1 select the R2 device in the devices window in the vSphere Client as in Figure 181. 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.
Once confirmed, the device is detached. The device does not disappear from the devices screen, but simply lists as Detached. This is shown in Figure 182.
Now that the device has been detached, when esxcfg-volume -l is run, only the BCV is shown, and it is available for resignaturing and mounting as seen in Figure 183.
Subsequently when using the vSphere Client, the R2 no longer appears, just the linked target device as in the add storage wizard in Figure 184.
Proceeding through the wizard, the user can now choose among all three options presented in Figure 185: 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 re-attached.
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 will receive an error that states the operation is not allowed in the current state. This is because ESXi recognizes the volumes have the same signature and since one is already mounted, a second volume cannot, in a sense, occupy the same space. The resolution to this is to unmount the datastore and detach the underlying device copy before attempting to re-attach 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 186. Any VMs in the datastore can now be registered.
With the completion of the resignature and mount, the R2 can now be re-attached. This is a best practice to ensure in the event of the production site failure 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 will require CLI as the “Unmount Datastore” will be grayed-out.
To do this, return to the devices screen and locate the grayed-out R2 device. Right-click on the device and select “Attach” from the menu as in Figure 187. 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. Once the task completes the device will return to “Attached” as in Figure 188.
Note: It is possible to unmask the R2 from the remote ESXi hosts instead of detaching the device, and then re-masking it once the resignature and mounting is complete, rescanning the HBAs each time. This is not a recommended best practice, however, and can lead to complications.