Decoding WWIDs (or how to tell what's what)

The difficulty of determining exactly which storage is presented is a common refrain in organizations where the storage and server teams are separate. At best this is an inconvenience (which LUN are you talking about?) while at worst it can be catastrophic (you put a file system on what!?).
While it is possible to correlate LUN numbers to devices by talking to the storage administrator, it is also possible to identify devices using server-side tools that use the wwid. This post will be HDS-specific, although I suspect that most vendors do something similar. If you have a different vendor feel free to share in the comments.

The key is that most operating systems use the NAA IEEE Registered Extended Identifier format to identify devices. This format, documented in Table 7 of http://standards.ieee.org/develop/regauth/tut/fibre.pdf, specifies that the identifier begins with 0x6, followed by the IEE OUI (Organizationally Unique Identifier). If you're curious you can search OUIs at http://standards.ieee.org/develop/regauth/oui/public.html.

After the OUI there is a vendor specific identifier and a vendor specific identifier extension.

Enough theory - what does this mean in practice?

Let's start with finding the number that we're talking about.

For VMware you can find the wwid by looking in vSphere at Storage under the Configuration tab for a physical server. Under the "Device" column there will be "naa.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" where the X's represent the WWID.

For Linux, you can consult the ouput from "multipath -ll" (if you're using native multipathing), or use "/sbin/scsi_id -g -u -s /block/sd#". In this instance the string will begin with "3" followed by 32 characters.

Finally if you're using Solaris with MPIO then the target ("Y" in cXtYdZ) will be the wwid.

Once you have this 32 character* identifier, it's possible to identify the make, serial number, and device. The following table shows a breakdown of wwids and their translation:

6  0060e8  0042ae400  00002ae4  00000b20  USP S/N 10980
6  0060e8  005bd3600  0000bd36  000015fd  USP-V S/N 48438
6  0060e8  006d2ad00  0000d2ad  00000502  VSP S/N 53933
6  0060e8  0104b6690  04f32571  00000000  AMS2100 S/N 83043697
6  0060e8  0102b1e00  0511a568  00000003  AMS2300 S/N 85042536
6  0060e8  0100afee0  053027f6  0000002f  AMS2500 S/N 87042038

The first column, 6, means that we're using the NAA IEE Registered Extended Identifier field format.

The next 6 columns are the OUI. 0060e8 is registered to HITACHI COMPUTER PRODUCTS (AMERICA), INC.

The next 3 columns, highlighted in yellow, identify the type of array, as follows:

004 - USP
005 - USP-V
006 - VSP
010 - AMS 2000 family

I'm not sure about the next 6 columns. For the enterprise arrays you have the serial number (in hexadecimal), while the AMS2000 line identifies the model number by the first character, with 0 = AMS2500, 2=AMS2300, and 4 = AMS2100.

The next 8 columns, highlighted in green, are the serial number of the array in hexadecimal.

The last 4 columns, highlighted in blue, are the LDEV (or CU:LDEV for enterprise). I suspect that the last 6 are LDKC:CU:LDEV, and that really all 8 are reserved for identifying the specific device, but have not been able to verify.

* If it seems like I'm being cagey here, it's because these are hexadecimal numbers and should technically be called nibbles. They're not really characters, since those are bytes (unless you're using unicode). Ok, enough digression...

Decoding WWIDs (or how to tell what's what)