Saturday, August 18, 2012

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, specifies that the identifier begins with 0x6, followed by the IEE OUI (Organizationally Unique Identifier). If you're curious you can search OUIs at

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...


  1. This is very cool! Thanks for sharing.

  2. Comparing this to a string that I found in my configuration: naa.60060e801532ae00000132ae0000010c -
    this document don't fit. This string is taken from esxi 5 using a LUN from a HDS USP-V serial number 78510

    1. Martin,

      Thanks for the information - I'm trying to understand which part(s) don't fit. If I break your string down I've got:

      6 0060e8 01532ae00 000132ae 0000010c

      I'm expecting 015 to be 005 instead - so that doesn't fit, but 0x132ae is decimal 78510. Is the LDEV 01:0c, or is that wrong?

      With regards to the 015 - would you mind sharing what microcode you're running? It may have been changed in later versions.


    2. From my own investigations I believe that the 015 is due to the first batch of serial number for enterprise has to be stored in a 16 bit sequence (the 32ae after the 015). Therefore the 1 is a carry on the high bits from converting 78510 to Hex.

      Part of this is covered for NAA 5 format WWNs in HDS Knowledge Base article KB15062.

      The “ssss” portion of the Port WWN IHHHHHHTOMSssssP  can be calculated by the following: Add 70000 (Dec) to the last 6 digits of the DF850 Serial Number.
      -    Translate the above value to Hex.
      -    Remove the upper 1 digit (which is the “S”).

      Having only Serial numbers lower than 0xFFFF I have no way of testing this though.

      Thanks, Chris.

  3. To expand on your "6 digits" that you aren't sure how it is generated on the AMS. I have analysed the serial numbers you have provided, cross referenced with information from, and come up with this formula:

    Serial Number minus the 3 leading numbers (8x0 in your instances) leaving the following serials: 43697, 42536, 42038

    Then add 3000 to these numbers and get the hex value.

    Convert these to hex and we get:

    Which appears to match what you have in your WWIDs

    If you feed this in you have a leading nibble which is the AMS level as you speculated, followed by the above 4 nibbles, followed by a 0. That is the 6 as far as I can tell. Also interesting that the AMS model can be determined from the first 3 digits of the serial number (from the EMC link above):

    730 AMS 200
    750 AMS 500
    770 AMS 1000
    830 AMS 2100
    850 AMS 2300
    870 AMS 2500

  4. Items starting with a 6 are NAA format 6, the IEEE registered extended format. This is what you see in a disk GUID.
    The breakdown is:
    6 | 24 bit OUI | 36 bit vendor sequence/serial number \ 64 bit vendor extension
    This is what you get from SCSI mode page 83.