Error Message

The following Device Discover Layer (DDL)  CLI command can be used to report any excluded devices:

# vxddladm list devices

DEVICE               TARGET-ID    STATE   DDL-STATUS (ASL)
===============================================================
sda                  -            Online  CLAIMED (Disk)
sdacg                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdacf                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdace                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdacd                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdacc                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdacb                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdaca                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdabz                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdaby                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdabx                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdabw                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdabv                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdabu                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdabt                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdabs                c16_p2_t0    Online  CLAIMED (libvxemc.so)
sdabr                c16_p2_t0    Online  CLAIMED (libvxemc.so)
.
.
sdzf                 c16_p2_t0    Online  EXCLUDED
sdzd                 c16_p2_t0    Online  EXCLUDED
sdzb                 c16_p2_t0    Online  EXCLUDED
sdyz                 c16_p2_t0    Online  EXCLUDED
sdyx                 c16_p2_t0    Online  EXCLUDED
sdyv                 c16_p2_t0    Online  EXCLUDED
sdyt                 c16_p2_t0    Online  EXCLUDED
sdyr                 c16_p2_t0    Online  EXCLUDED
sdyp                 c16_p2_t0    Online  EXCLUDED
sdyn                 c16_p2_t0    Online  EXCLUDED
sdyl                 c16_p2_t0    Online  EXCLUDED


Instructions

External identity will survive a device delete and recreation. This is expected behavior.

Additional Information

Below is an excerpt from the "VMAX NON-DISRUPTIVE MIGRATION Configuration and Best Practices Technical Notes."
-----------------------------------------------------------------------------------------------------------------------------------------------------
COMPARE THE PRE AND POST DEVICE IDENTITIES FOLLOWING A COMMIT
Following the commit operation, each device presents the opposite device ID. The source device now presents the target device ID as its external identity and the target presents the source device ID as its external identity. These changes are permanent and will persist across system power cycles and even the deletion and recreation of the devices.
 -----------------------------------------------------------------------------------------------------------------------------------------------------

1. Any given device should only be presenting one device WWN. That is shown in the external identity in a 'symdev show ' command. We should never be presenting two separate device wwns to hosts (as seen via inq), be they RecoverPoint or any other host. Note that in a symdev show you will see two different device WWNs. One is the native WWN, and one is the external identity. If the device was the source or target of a NDM session, then the External Identity will be different than the native one, unless cleared by the customer.  This is by design.  

2. The customer can clear the spoofing of the device if they wish through SE, by clearing/resetting the identity of the device. DO NOT DO THIS WHILE THE DEVICE IS STILL BEING ACCESSED/MOUNTED. Clearing the spoofed identity while live means the server will suddenly see the disk as a different disk (think your server is mounted to the C drive, then suddenly it changes to the E drive without warning). There is no workaround for this at the array level, as the changes are made at a scsi layer level. 

If you wish to remove this identity, this is a disruptive process. You can do the following to reset the identity:

• Take devices offline to the host and then remove them from their current storage group
• Issue the command:  symdev set -no_identity   against each device
• Add the devices back to the storage group and rescan on the host
• Confirm that the correct identity is now seen in syminq

3. As far as the spoofed identity, the expectation is that it is left on indefinitely in order to prevent having multiple LUNs with the same WWN on the fabric. This "second wwn" will not cause issues with any host or replication, however it can sometimes lead to confusion while managing or troubleshooting the device.  The customer will need to be aware that the devices seen by the servers are not the "real" devices. They need to use INQ with the -native option, or use powerpath at the latest versions. Either option will see "through" the spoofing, allowing the customer to easily identify the real devices they are using while maintaining the spoofed identity.

 

 

Once the NDM migration is complete, it is vital the spoofing details for the NDM migrated LUNs are reset to avoid conflicts with other vendor Volume Management & Multi-pathing solutions, such as Veritas Volume Manager and Veritas Dynamic Mulit-pathing (DMP).

The purpose of NDM is to be transparent to the host. The user will need to be aware that the devices seen by the servers are not the "real" devices.

This "second wwn" will not cause issues with any host or replication, however it can sometimes lead to confusion while managing or troubleshooting the device.  


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

 

Reset spoofing information for EMC NDM migrated SYMDEVs.

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

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

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.


 

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.

The Veritas Volume Manager (VxVM) Device Discover Layer (DDL) may exclude DELL/EMC NDM related devices following EMC NDM array migration, when the spoofing details have not been reset.

The DDL device exclusion can also be seen when upgrading to InfoScale 7.4.2 when NDM migrated devices are presented to the upgraded host.