DELL/EMC NDM migration may result in vxdmpadm listenclosure displaying both arrays requiring DMP clean-up

Description

The DELL/EMC NDM solution leverages VMAX SRDF replication technologies to move the application data from the source EMC storage array to the new target EMC storage array.

This can result in the vxdmpadm listenclosure command displaying both the source and target NDM paired arrays.

Once the NDM migration is complete, the spoofing details for the NDM migrated LUNs may require a LUN identity reset to avoid conflicts with other vendor Volume Management & Multi-pathing solutions, such as Veritas Volume Manager (VxVM) and Veritas Dynamic Mulit-pathing (DMP).
Once the EMC LUN identity has been reset, the DMP in-core database may require a clean-up.



How to reset spoofing information for EMC NDM migrated SYMDEVs

The following EMC Solutions Enabler (SYMCLI) command will remove any historical reference to the source EMC storage array:


Path:  /opt/emc/SYMCLI/bin

# symdev -sid SID reset -identity SYMDEV

Note: The NDM migrated devices must be closed at the VxVM layer prior to updating the EMC SYMDEV attributes.

Related article available on DELL/EMC support site
:
Note: Devices Previously Used in NDM Have Two WWNs

https://www.dell.com/support/kbdoc/en-uk/000010796

Unique Disk Identifier (UDID)

Veritas Volume Manager (VxVM) refers to two UDID values, the UDID value returned by the DDL (Device Discovery Layer) which is the correct (true) UDID value of the LUN, whereas the UDID written on-disk can be from a different source.

The UDID structure consists of the Vendor ID (VID), Product ID (PID), Cabinet Serial Number (Cab_Serial_No) and Lun Serial Number (Lun_Serial_No - LSN) :

"VID , '_', PID , '_', CAB _Serial_No , '_', Lun_Serial_No "

As a result of clearing/resetting the spoofing information, this leads to the expected VxVM udid_mismatch flag being set, as the true UUID in the kernel differs to what is written on-disk.
 

The UDID information can be updated to make it appear as a STANDARD (STD) disk once again, using the command:

# vxdisk -c updateudid veritas-disk-access-name

The related VxVM disk groups can then be safely imported.