How to translate Windows disk ids to storage array’s LUNs

Converting disk information in a VM into the actual LUN information

We’ve all been there: you have a certain Windows virtual machine with several disks of the same size and you don’t know which Windows-disk is in fact which storage LUN.

The VMware settings for this VM might look like this:

VM-config

In Windows a disk might show this information:

Windows disk information

It turns out converting the Windows information can be converted into VMware settings quite easily. How?

VMware SCSI controller conversion table (into Windows locations)

First of all disks coming from SCSI controller 0 show as coming from “location 160” in Windows disk management.

Disks connected to SCSI controller 1 appear as coming from “location 161”. And so on. After that each controller increments by 32.

  • controller 0 = location 160
  • controller 1 = location 161
  • controller 2 = location 193
  • controller 3 = location 225
  • controller 4 = location 257

Furthermore, when a 2nd SCSI controller is added and vdisks are added from a data store, the bus number will increment, as seen in Windows.

When RDMs are used, in Windows the bus will always be 0.When you add a SCSI id to an RDM in Virtual Center, you add an x:y number as identifier to that disk. “x” Represents the SCSI controller and “y” is the LUN id. In Windows this translates to a “location” and “target”. The LUN id as seen by Windows disk manager is not used.

So in my screenshot from disk manager as shown above “disk9” has the information “Location 193, bus 0, target 3, LUN 0”. So translating this into the VCenter settings for this VM:

SCSI id 2:3 (2 is the controller and 3 is the LUN on that controller).

So now you look up disk 2:3 in this VM’s settings and find:

naa number in VCenter settings

Note that the disk numbering in the VM settings are different from the Windows disk numbers. Windows starts at 0 and in VCenter a disk number starts at 1 and I’ve seen Windows environments where the disk numbers changed after reboots, so don’t use disk numbers as reference!

In the top right red encircled number you’ll find the naa number. This usually starts with “6006”, at least for EMC storage it does.

By using the command line tool “naviseccli” you can now check the naa-number with the LUNs presented to the ESX host where the VM resides. It’s a lot of work, but you might want to consider adding this information to your documentation and update it every time disk changes are performed.

CLI finding naa numbers

As you can see the naa number I found using the CLI command matches the RDM I found in the VM settings. Note that in VMware some “lead-in numbers” appear (in this case “vml.02001d0000”) as well as some lead-out numbers (anything after “e311”).

This is how I’d track a Windows disk all the way back to its storage array LUN.

Conclusion

Documentation! Make sure you add the naa numbers of RDMs in your sheet (or whatever you use to document all the settings and configurations). Even better: for every disk you add in the VM’s settings, write down which LUN that represents.

External sources:

VMware knowledge base website kb2051606.

  1. Unfortunately the “controller-to-location” calculation works not always. We have VMs where Windows does show location 160 and 225 but not 193. The VM has 2 controllers 0:0 and 1:0.
    Even a complete swap of numbers are possible.
    It seems there will be a missmatch when controllers where added, removed, added etc.
    Up to now I found no reliable way to match VM SCSI-IDs to Windows-IDs (but where interested in…)

  2. I’ve gone through the biggest file server we have.
    In my case I have these numbers as the SCSI Controller and location:
    Location 160 – SCSI 0 (meaning SCSI(0:X) in Vmware)
    Location 256 – SCSI 1 (meaning SCSI(1:X) in Vmware)
    Location 161 – SCSI 2 (meaning SCSI(2:X) in Vmware)
    Location 224 – SCSI 3 (meaning SCSI(3:X) in Vmware)
    The location numbers have even switched place on my server.

Would you like to comment on this post?

Trackbacks and Pingbacks: