At least once a week in my career as a storage engineer I have a conversation that involves a systems admin asking me to add space to a SAN (fiber channel attached) based storage object by referring to it how they see it. This could be the name of a data store in VMware, saying the “E-drive”, or any number of other descriptions of a storage object which are meaningless to me. When I ask for more detail I am often given the world wide name of the device, as to them it looks like a pretty unique identifier for the storage they are talking about. Before I long I log into the system myself and get it all sorted out but I wanted to see if there was a way I could make a quick and easy translation of the world wide name they give me so that it could be immediately useful.
For the purposes of this post, I will be focusing on World Wide Names (or WWN) as they pertain to the storage “naa id” which is commonly presented in VMware and other operating systems when referencing storage devices. In my experience this number is misunderstood by many systems admins without a storage background. Moreover, often times it can require a lot of additional digging to figure out exactly where a storage object resides on the SAN if it was not named/aliased in an intelligent manner.
Whether you are on a Linux command line, in Windows, VMware, etc. when working with storage you will come across references to the world wide name quite often. Much more often than you will see a more friendly descriptor of the disk that you can use to figure out exactly where that storage object is. One of the most common formats to see today is in a format which will look like this:
naa.600a098038303634495d475878384e61
This number is the NAA ID as is used by the T10 committee for the SCSI-3 protocol. I am not sure of the specific interaction but it looks like T10 governs the SCSI protocol but uses IEEE defined constructs such as the WWN/OUI references within the protocol. There is a bit more detail on the NAA and VPD breakdown in this document. The NAA id can be used to refer to a disk which is accessed using the SCSI protocol, this can be FC, iSCSI, or locally attached SCSI/RAID.
The first section of this can essentially be discarded, that is the “naa.6” (yes including the 6). The “naa” is the “page 0x83 identifier” (Device Identification VPD page) and the 6 tells us that the WWN contains an OUI in the IEEE “registered extended” network address authority format 6. The 6 is included in the 16-byte (32-characters (nibbles) of hexadecimal) address space but we do not need to use it for anything. The IEEE reference documentation on Fiber Channel WWN’s and OUI’s breaks down format 6 as follows:
So to further translate this means the WWN we provided above can be broken down. It starts with 0x6 which tells us it is IEEE format 6. The next 6 nibbles are the IEEE Organizationally Unique Identifier, or OUI, which is a unique identifier for a company/product. At this point we have broken down our original WWN as follows:
naa. <- Not Needed, required as part of the standard 6 <- Tells us this is IEEE registered extended format 6 00a098 <- Hexadecimal IEEE OUI 038303634 <- Vendor-specific Identifier 495d475878384e61 <- Vendor-specific Identifier (extension)
Translation of the OUI involves essentially just looking at the IEEE list of registered OUI’s or using a site which provides a lookup tool. This can be a bit confusing at times because sometimes storage is OEM branded one way but the actual OUI refers to the actual manufacturer of the storage.
So at this point we know what the number means and we can, at the very least, extract some vendor information from it. The next part is where it gets really murky because vendors can do whatever they want at this point and there is very little consistency. As I prematurely noted in the code snippet above, the rest of the WWN is reserved for “vendor-specific identifier” and “vendor-specific identifier extension”. This basically means that the vendor can do whatever they want at this point and EMC will use the address for something different than NetApp will.
NetApp Vendor Specific
For example, on the NetApp platform the two vendor specific sections get combined, the leading zero gets dropped and the rest is translated to the LUN serial number. As far as I am aware no other information is exposed here such as the controller serial number, model, etc. If we use the above example and combine the vendor specific sections we are left with:
38303634495d475878384e61
From this we can do two things, we can either display the LUN serial # on the NetApp in hex:
netapp> lun serial -x /path/to/lun
Serial (hex)#: 0x38303634495d475878384e61
Or we can convert the above from hex to ASCII and compare to the standard LUN output on a NetApp:
lun show -v /path/to/lun /path/to/lun 75g (80530636800) (r/w, online, mapped) Comment: "LUN" Serial#: 8064I]GXx8Na Share: none Space Reservation: disabled Multiprotocol Type: vmware Maps: Occupied Size: 75.3g (80843472896) Creation Time: Wed Nov 12 10:04:35 EST 2014 Cluster Shared Volume Information: 0x0 Read-Only: disabled
The annoying part about how NetApp handles this is that when you have a large environment with lots of controllers it can be a bit of a task to hunt down the specific LUN serial number, but at least you can make some use of the NAA ID/WWN.
In my environment we have a couple different storage platforms so I have been able to further translate the vendor specific sections for those which I have access to.
EMC – DGC / VNX / CX-n / CLARiiON
Some EMC platforms are still using the OUI for DGC/CLARiiON (OEM via Data General Corporation), if you see an OUI that refers to CLARiiON or DGC it is most likely an EMC VNX or CX series array.
On VNX the LUN properties actually show you the whole NAA number as both an naa ID and a matching string as the LUN “unique identifier”, but we are more interested in using the NAA ID to figure out where the LUN is, not the other way around.
naa. <- Not Needed, required as part of the standard 6 <- Tells us this is IEEE registered extended format 6 006016 <- OUI 084 <- Seems to refer to the array type/model e12d00 <- Stays consistent for all disks on any one array, not sure what it translates to 06bee94f252e <- Unique for every LUN e411 <- This can be in the format e411, e311 as far as I can tell, but I am not sure what it is tied to
Engenio (LSI) – IBM DS FAStT / NetApp E-Series
IBM’s FAStT / DS Series storage, and more recently NetApp E-Series were actually made by Engenio. As of today the OUI, even of the older storage arrays, seem to reference NetApp since they now own Engenio. In most cases (at least in my experience) when you see the OUI though, it will refer to an IBM DS / FAStT array and not a NetApp, unless you have NetApp E-series in your environment of course.
naa. <- Not Needed, required as part of the standard 6 <- Tells us this is IEEE registered extended format 6 00a0b8 <- OUI 000 6e23f4 <- Vendor specific 0000 e8304f199f02 <- Vendor specific
HDS – Hitachi Data Systems
Hitachi has perhaps the most clear use of the naa id. Thanks to this blog post for doing most of the detective work as I do not have any access to HDS storage at the moment.
naa. <- Not Needed, required as part of the standard 6 <- Tells us this is IEEE registered extended format 6 0060e8 <- OUI 0 <- Reserved 04 <- Array Type (I was unable to find a complete table of these but this byte refers to a specific HDS array model 2ae4 <- Serial number in hex 00002ae4 <- Serial number in hex (again) 0000 <- Always 0000 for enterprise, not sure what it would be if not enterprise 0b <- CU 20 <- LDEV
If you have any corrections for me, or can provide information about storage vendors I have not included here, please leave a comment!
RSS - Posts
Really appreciate buddy… it is not very easy to collect his much info and post it in a way server admins like me can understand. Good job.
Have been searching for it. Thanks.