Home › Resources › Field Guides › NetApp LUN Serial in VMware

Field Guide · Storage Operations

How to Identify a NetApp LUN Serial Number in VMware vCenter and ESXi

VMware never shows you a NetApp LUN’s serial number — it shows an NAA identifier. The whole trick of this guide: the NAA contains the serial, hex-encoded, in plain sight. Learn to read it once and every “which LUN is that datastore?” question — migration, performance triage, reclamation, DR — collapses into a one-line lookup, in either direction, with nothing installed anywhere.

Who this is for: VMware administrators · storage administrators · SAN engineers · anyone reconciling datastores against ONTAP LUNs

Applies to: ONTAP 9.x (and 7-mode, noted where it differs) · vSphere 7.x/8.x · FC, iSCSI and FCoE LUNs · Reviewed by WUC Storage Infrastructure Engineering · Last validated: 2026-07-21

FocusDatastore/RDM ↔ ONTAP LUN correlation
Key factNAA = 600a0980 + hex(serial)
ToolsvCenter UI · esxcli · PowerCLI · ONTAP CLI
RiskEverything here is read-only
Read time8 min

01The one fact: the NAA contains the serial

ONTAP stamps every LUN with a 12-character serial at creation. VMware, seeing that LUN, builds its NAA identifier from the SCSI inquiry data — and for NetApp the result is simply a vendor prefix followed by that serial, hex-encoded. Nothing is hidden; it is just wearing hex:

One identifier, two names — the NAA decodes to the serial naa. 6 00a098 0 38304e58712b5a764b6d5666 NAA type 6: IEEE Registered Extended 00a098 = NetApp OUI (vendor fingerprint) 24 hex chars = ASCII hex of the 12-char serial: 38 30 4e 58 71 2b 5a 76 4b 6d 56 66 8 0 N X q + Z v K m V f → serial 80NXq+ZvKmVf All serials and identifiers on this page are synthetic reference values.
The full identifier for datastore BOS-DS01's LUN: naa.600a098038304e58712b5a764b6d5666. Strip naa.600a0980, read the remaining 24 hex characters as ASCII, and the ONTAP serial falls out. The encoding is exact and lossless in both directions — no lookup table, no vendor plugin required.
Which prefix you will see. Modern clustered ONTAP LUNs carry naa.600a0980…. Older 7-mode systems present naa.60a98000… — same NetApp OUI (00a098) packed differently, and the hex-encoded serial follows the prefix in exactly the same way. A 7-mode worked example: naa.60a9800057322d6a5a71437267307358 → drop naa.60a98000 → 57322d6a5a71437267307358 → decodes to serial W2-jZqCrg0sX. Anything that does not start with one of these prefixes is not an ONTAP LUN: NetApp E-Series presents naa.60080e5… (a different acquired-product OUI), and other vendors have their own — the prefix is your fastest "is this even the right array?" check.

02Pick your direction

Every correlation task starts on one side of the stack and needs the answer from the other. There are only two cases — identify which one you are in, then follow that section alone:

Two directions, one identifier vCenter / ESXi NETAPP Fibre Channel Disk naa.600a0980|38304e58712b5a764b6d5666 datastore BOS-DS01 · 4 TB ONTAP · svm-vmware /vol/vmw_ds01/lun0 serial 80NXq+ZvKmVf serial-hex 38304e58712b5a764b6d5666 A · lun show -serial-hex *tail* B · search naa.600a0980 + serial-hex Same 24 hex characters on both sides. Start from whichever side you have, cross once, verify on the other.
The whole guide in one picture: the 24-hex tail of the NAA and the ONTAP serial-hex are the same string. Direction A crosses left-to-right (you have a device, want the LUN); Direction B crosses right-to-left (you have a LUN, want the device).

03Direction A — VMware → NetApp Read-only

You have: a device or datastore in vCenter. You want: the ONTAP volume, SVM, and LUN path behind it. Three steps.

Step 1 — grab the NAA in vCenter

ESXi host Configure StorageAdapters vmhba… Devices sort, copynaa.… Also on the datastore itself: Datastore → Configure → General → Device Backing shows the same naa.
Where the NAA lives in vCenter. The Devices tab lists every device the host sees with LUN ID, capacity and type — keep those in view, they are your sanity check after the lookup.

No vCenter handy? The same list from any ESXi shell:

Command
esxcli storage core device list | grep -E "Display Name|Serial Number|naa"
Output
naa.600a098038304e58712b5a764b6d5666
   Display Name: NETAPP Fibre Channel Disk (naa.600a098038304e58712b5a764b6d5666)
naa.600a098038304e58712b5a764b6d5668
   Display Name: NETAPP Fibre Channel Disk (naa.600a098038304e58712b5a764b6d5668)
naa.600a098038304e58712b5a764b6d5667
   Display Name: NETAPP Fibre Channel Disk (naa.600a098038304e58712b5a764b6d5667)

Step 2 — take the 24-hex tail, ask ONTAP

Copy the last 24 hex characters of the NAA — that is the serial, hex-encoded (section 01). You do not even need all of it: lun show -serial-hex accepts wildcards, so any unambiguous fragment finds the LUN. On some ONTAP releases wildcard matching behaves best at advanced privilege; setting it costs nothing and the last line returns you home:

Command — ONTAP CLI, wildcard reverse lookup
set -privilege advanced

lun show -serial-hex *712b5a764b6d5666*
lun show -serial-hex *712b5a764b6d5667*

set -privilege admin
Output
Vserver    Path                          State    Mapped   Type     Size
---------- ----------------------------- -------- -------- -------- --------
svm-vmware /vol/vmw_data04/vmw_data04    online   mapped   vmware   10TB

Vserver    Path                          State    Mapped   Type     Size
---------- ----------------------------- -------- -------- -------- --------
svm-vmware /vol/vmw_rdm01/lun0           online   mapped   vmware   4TB

Step 3 — sanity-check the match: the size in the output (4 TB / 10 TB) must agree with the vCenter device row you started from. If it does not, stop — re-count the hex characters before touching anything.

Nothing comes back? Check the prefix before doubting the method. Clustered ONTAP devices start naa.600a0980, 7-mode naa.60a98000. NetApp E-Series arrays present different vendor codes entirely (naa.60080e5…, or naa.600a0b8… on LSI-era systems) — those LUNs resolve in SANtricity System Manager, not in ONTAP’s lun show. An unfamiliar prefix is the fastest possible “wrong array” signal.

04Direction B — NetApp → VMware Read-only

You have: a LUN on the cluster. You want: the datastore or RDM it backs. ONTAP will hand you the search string ready-made — the serial-hex field is exactly the NAA tail:

Command — ONTAP CLI (cluster shell)
lun show -vserver svm-vmware -fields serial,serial-hex
Output
vserver    path                  serial       serial-hex
---------- --------------------- ------------ ------------------------
svm-vmware /vol/vmw_ds01/lun0    80NXq+ZvKmVf 38304e58712b5a764b6d5666
svm-vmware /vol/vmw_rdm01/lun0   80NXq+ZvKmVg 38304e58712b5a764b6d5667
2 entries were displayed.

Prepend naa.600a0980 to the serial-hex value and that is the device name, verbatim. Paste it into vCenter’s search box, or match it from the shell:

Command
esxcli storage vmfs extent list
Output
Volume Name  VMFS UUID                            Extent Number  Device Name                           Partition
-----------  -----------------------------------  -------------  ------------------------------------  ---------
BOS-DS01     681f2c4e-8a31d970-55aa-3cecef1a2b30              0  naa.600a098038304e58712b5a764b6d5666          1
BOS-DS02     681f2d11-42b8ee01-9c02-3cecef1a2b30              0  naa.600a098038304e58712b5a764b6d5668          1

The whole estate at once — PowerCLI

Every datastore, with its NAA and decoded serial Read-only

One pipeline against vCenter answers the question for every VMFS datastore in the inventory — and decodes the serial inline, so the output is already in NetApp's language.

Command — PowerCLI, connected to bos-vc-01
Get-Datastore | Where-Object {$_.Type -eq "VMFS"} | Select-Object Name, @{N="NAA";E={$_.ExtensionData.Info.Vmfs.Extent[0].DiskName}}, @{N="NetAppSerial";E={$naa=$_.ExtensionData.Info.Vmfs.Extent[0].DiskName; if($naa -match "^naa\.600a0980(.+)$"){ -join (($Matches[1] -split "(..)" | Where-Object {$_}) | ForEach-Object {[char][convert]::ToInt32($_,16)}) } else {"(not ONTAP c-mode)"}}} | Format-Table -AutoSize
Output
Name      NAA                                   NetAppSerial
----      ---                                   ------------
BOS-DS01  naa.600a098038304e58712b5a764b6d5666  80NXq+ZvKmVf
BOS-DS02  naa.600a098038304e58712b5a764b6d5668  80NXq+ZvKmVh

Every RDM in the inventory Read-only

The RDM sweep migrations always forget — every raw mapping, its VM, and its backing NAA.

Command
Get-VM | Get-HardDisk -DiskType "RawPhysical","RawVirtual" | Select-Object Parent, Name, DiskType, ScsiCanonicalName, CapacityGB | Format-Table -AutoSize
Output
Parent      Name         DiskType     ScsiCanonicalName                     CapacityGB
------      ----         --------     -----------------                     ----------
bos-sql-01  Hard disk 2  RawPhysical  naa.600a098038304e58712b5a764b6d5667       2,048

05The on-page decoder — and doing it by hand

Decode it right here Read-only

Paste anything below — a full NAA identifier, the bare 24 hex characters, or a 12-character serial — and the decoder works out the direction. It runs entirely in your browser: nothing you type is transmitted, logged, or stored anywhere.

Client-side only — this page makes no network request with your input. Try the worked example: naa.600a098038304e58712b5a764b6d5666

NAA → serial Read-only

Strip naa.600a0980, hex-decode the remainder. Three one-liners, pick your shell:

Command — bash (ESXi shell or any Linux)
echo 38304e58712b5a764b6d5666 | xxd -r -p; echo
Command — PowerShell
-join (("38304e58712b5a764b6d5666" -split "(..)" | Where-Object {$_}) | ForEach-Object {[char][convert]::ToInt32($_,16)})
Command — python
python3 -c "print(bytes.fromhex('38304e58712b5a764b6d5666').decode())"
Output — all three
80NXq+ZvKmVf

Serial → NAA Read-only

The reverse direction — you hold an ONTAP serial and need the identifier to search for in vCenter:

Command — python
python3 -c "print('naa.600a0980' + '80NXq+ZvKmVf'.encode().hex())"
Command — PowerShell
"naa.600a0980" + -join ("80NXq+ZvKmVf".ToCharArray() | ForEach-Object {"{0:x2}" -f [int]$_})
Output — both
naa.600a098038304e58712b5a764b6d5666
Serials are case-sensitive and character-exact. ONTAP serials mix cases and use characters like +, - and /; the hex encoding preserves them exactly (2b is the + above). When comparing by eye, one character is the difference between two LUNs — which is why the decode belongs in a command, not in your head.

06Verify before you act

Every command in this guide is read-only. The danger is what happens after a wrong answer. Two LUNs of the same size with similar names are indistinguishable in most views — and "unmap the old datastore's LUN" executed against the wrong one is an instant, cluster-wide outage. The serial number is the only identifier that is unique, stable across reboots and rescans, and identical on both the VMware and NetApp sides. Correlate by serial, never by size, never by name, never by LUN ID — and confirm the match in both directions before any destructive change order is written against it.

Two closing checks turn a lookup into evidence. First, confirm presentation — which hosts actually see this LUN:

In System Manager: Storage → LUNs → select the LUN — the serial number is on the details pane. And for the mapping sanity check, lun mapping show -vserver svm-vmware confirms which igroup (and therefore which ESXi initiators) the LUN is presented to — the final "this LUN, these hosts" confirmation before any change order.

Second, write the finding down so anyone can re-verify it from either side of the stack — the worked change-order sequence:

# 1. vCenter: BOS-DS01 > Configure > General > Device Backing
#    naa.600a098038304e58712b5a764b6d5666

# 2. ESXi cross-check (either host):
[root@esx-01:~] esxcli storage vmfs extent list | grep BOS-DS01
BOS-DS01  681f2c4e-...  0  naa.600a098038304e58712b5a764b6d5666  1

# 3. ONTAP: match the NAA tail directly
aff-01::> lun show -serial-hex 38304e58712b5a764b6d5666
svm-vmware /vol/vmw_ds01/lun0  online  mapped  vmware  4TB

# 4. Confirm presentation (which hosts see it)
aff-01::> lun mapping show -vserver svm-vmware -path /vol/vmw_ds01/lun0
svm-vmware /vol/vmw_ds01/lun0  ig-bos-esx  LUN-ID 0

# 5. The change order now reads:
#    "Unmap /vol/vmw_ds01/lun0 (serial 80NXq+ZvKmVf,
#     naa.600a098038304e58712b5a764b6d5666) from igroup ig-bos-esx"
#    -- three independent identifiers, one LUN, zero ambiguity.
Note what step 5 did. The change order carries the LUN path, the serial, and the NAA — so whoever executes it can re-verify on whichever side of the stack they stand. That redundancy costs one line of writing and eliminates the entire class of wrong-LUN incidents.

RBRunbook · both directions, condensed

  1. Build the ONTAP inventory first — lun show -fields serial-hex (add path,size,ostype,mapped for the working view). This is the table every VMware identifier gets matched against.
  2. Get the NAA — datastore: Configure → Device Backing (or esxcli storage vmfs extent list); RDM: VM → Edit Settings → Physical LUN (or the PowerCLI RDM sweep).
  3. Confirm the vendor prefix — naa.600a0980 (clustered ONTAP) or naa.60a98000 (7-mode). Anything else: stop, different array.
  4. Take the 24 hex characters after the prefix — that is the serial, hex-encoded.
  5. Match on ONTAP — lun show -serial-hex <24-hex> → path, volume, SVM. Or decode to ASCII and match lun show -serial.
  6. Confirm the mapping — lun mapping show → igroup → the hosts you expect.
  7. Write all three identifiers into the change order — path, serial, NAA.

Reconciling a VMware estate against its storage?

WUC engineers deliver datastore-to-LUN reconciliation as part of storage migrations, reclamation sweeps, and DR validation on NetApp estates inside and outside OEM support.

Talk to engineering →

FAQFrequently asked questions

Q03Does this work for iSCSI LUNs, or only FC?

Both, and FCoE too — the NAA identifier comes from the SCSI inquiry data, not the transport. An ONTAP LUN presents the same NAA over any block protocol it is mapped through.

Q04What about NVMe namespaces (NVMe/FC, NVMe/TCP)?

Different identity scheme: NVMe namespaces are identified by NGUID/UUID, not NAA, and ESXi shows them as eui. or uuid. devices. The correlation is done with vserver nvme namespace show against the namespace UUID instead — the serial-in-hex trick on this page is a SCSI LUN behaviour.

Q06Does a vVols environment need this?

Mostly no — vVols does away with the one-datastore-one-LUN model, and correlation runs through the VASA provider (ONTAP tools) instead. Where you will still meet NAA correlation in a vVols shop: the protocol endpoints themselves, and any remaining classic VMFS or RDM devices — of which migrations always find a few.

Q07The serial decodes to gibberish — what went wrong?

Almost always one of three things: you decoded a non-NetApp device (check the prefix); you included the 0 pad or dropped a hex digit when stripping the prefix (the tail must be exactly 24 hex characters); or the device is an NVMe namespace wearing a different identity format entirely. Re-check the prefix, re-count the characters.

Q08Can ONTAP tools for VMware do this for me?

Yes — NetApp's ONTAP tools vCenter plugin surfaces LUN and volume detail directly in the vSphere Client, and in an estate with it deployed, that is the convenient path. This guide exists because the plugin is frequently absent, broken, or version-stranded exactly when you need the answer — the NAA method needs nothing installed anywhere.

RFReferences

  1. NetApp ONTAP CLI — lun show (serial and serial-hex fields)
  2. NetApp Knowledge Base — LUN serial to NAA/device identifier correlation articles
  3. VMware KB 1014953 — Identifying disks when working with VMware ESXi
  4. VMware PowerCLI — documentation and download
  5. vmninja — Matching NetApp LUN serials to VMware NAA identifiers (community walk-through of this method)
  6. Video walk-through — identifying a NetApp LUN serial from the vSphere Client (community)

→From the same practice

WE

About WUC Engineering

Storage engineers at WUC Technologies operate NetApp ONTAP estates alongside VMware infrastructure — FAS, AFF and legacy 7-mode systems — under post-OEM storage maintenance engagements across enterprise data centers.

How many of your datastores could you name the LUN for, right now?

Most VMware estates we assess cannot produce a current datastore-to-LUN map — and discover their undocumented RDMs mid-migration. WUC engineers deliver storage reconciliation as a deliverable: the full correlation table, the orphaned-LUN list, and the RDM inventory nobody knew they had.

  • Datastore / RDM to LUN correlation across the estate
  • Orphaned and unmapped LUN identification before reclamation
  • Migration and DR planning built on verified identifiers
  • NetApp estates inside and outside OEM support
e.g. Cisco, Dell, NetApp - and when your next contract renews.

Prefer to talk it through first? Book a technical consultation → · View managed services

All hostnames, domains, users, paths, serial numbers and IP addresses in this guide are synthetic reference values. No customer environment is depicted. NetApp and ONTAP are trademarks of NetApp, Inc.; VMware, vSphere and vCenter are trademarks of Broadcom. WUC Technologies is not affiliated with these vendors.

Get a Custom Solution

Ready to Transform Your IT Infrastructure?

Get enterprise-grade support backed by seasoned infrastructure engineering.

Request a Quote Email Support

We respond within 1 business day. No spam, ever. • 15+ years • 99.9% uptime guaranteed