Home › Resources › Field Guides › NetApp LUN Serial in VMware
Field Guide · Storage OperationsHow to Identify a NetApp LUN Serial Number in VMware vCenter and ESXi
When a VMware environment runs on NetApp ONTAP block storage, sooner or later somebody needs to point at a datastore and say, with certainty, which LUN that is — during a migration, a performance investigation, a DR planning exercise, or a reclamation sweep where guessing wrong deletes production. VMware never shows the NetApp serial number directly; it shows an NAA identifier. The good news that this guide is built on: the NAA identifier contains the serial number — hex-encoded, in plain sight — and once you can read it, every correlation question collapses into a one-line decode. The workflow this guide teaches runs storage-first: inventory the serials on the NetApp, then match VMware’s identifiers against that table.
!!Safety model — read-only, but the stakes are not
| Badge | Meaning |
|---|---|
| Read-only | Inspects and lists. Every command on this page. Safe in production, any time. |
| Disruptive | Not used in this guide — but the change orders this guide feeds (unmap, resize, move) are, which is why the correlation must be right. |
ENVReference environment
The worked example runs in the Boston environment used across this guide series: vCenter bos-vc-01 managing hosts esx-01 and esx-02, attached over dual FC fabrics to a NetApp AFF pair (aff-01a/aff-01b) running ONTAP 9.x. The SVM svm-vmware serves two LUNs: /vol/vmw_ds01/lun0 backing the VMFS datastore BOS-DS01 (serial 80NXq+ZvKmVf), and /vol/vmw_rdm01/lun0 presented to a database VM as an RDM (serial 80NXq+ZvKmVg) — deliberately one character apart, because that is exactly the near-miss the serial method has to distinguish and the size-and-name method cannot.
01Anatomy of a NetApp NAA identifier
ONTAP gives every LUN a 12-character ASCII serial number at creation. When VMware sees that LUN, it builds a Network Address Authority identifier from the SCSI Inquiry VPD page 83 data — and for NetApp ONTAP LUNs that identifier has a fixed, decodable structure:
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.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.
02Start on the NetApp: inventory the LUNs and their serials
The cleanest correlation workflow starts on the storage side, not in vCenter — ONTAP is the source of truth for what exists, and one command gives you every LUN with its serial already in the hex form the NAA uses. Build this table first; every VMware identifier you meet afterwards is a lookup against it.
Option 1 — every LUN with its serial hex (recommended) Read-only
The one command to run before anything else. The serial-hex column is, character for character, what follows the NetApp prefix in each LUN’s NAA identifier — no decoding required to match.
lun show -fields serial-hexvserver path serial-hex
---------- --------------------- ------------------------
svm-vmware /vol/vmw_ds01/lun0 38304e58712b5a764b6d5666
svm-vmware /vol/vmw_ds02/lun0 38304e58712b5a764b6d5668
svm-vmware /vol/vmw_rdm01/lun0 38304e58712b5a764b6d5667
3 entries were displayed.The extended inventory — path, size, type, mapping state Read-only
The same list with the columns that matter during a migration or reclamation: how big each LUN is, what OS type it was created for, and — critically — whether it is actually mapped to anything. An unmapped LUN with a familiar name is a reclamation candidate; a mapped one is somebody’s datastore.
lun show -fields path,serial-hex,size,ostype,mappedvserver path size ostype mapped serial-hex
---------- --------------------- ----- -------- ------- ------------------------
svm-vmware /vol/vmw_ds01/lun0 4TB vmware mapped 38304e58712b5a764b6d5666
svm-vmware /vol/vmw_ds02/lun0 4TB vmware mapped 38304e58712b5a764b6d5668
svm-vmware /vol/vmw_rdm01/lun0 2TB vmware mapped 38304e58712b5a764b6d5667
3 entries were displayed.One LUN, everything — the -instance record Read-only
When a single LUN is the subject of the investigation, -instance prints its full record — serial in both forms, state, size, and the attributes that explain surprises. This is the record to paste into a ticket.
lun show -vserver svm-vmware -path /vol/vmw_rdm01/lun0 -instance Vserver Name: svm-vmware
LUN Path: /vol/vmw_rdm01/lun0
Volume Name: vmw_rdm01
OS Type: vmware
LUN Size: 2TB
State: online
Serial Number: 80NXq+ZvKmVg
Serial Number (Hex): 38304e58712b5a764b6d5667
Mapped: mapped
Space Reserved: disabled
Space Allocation (SCSI UNMAP): enabledlun show -fields ? prints every available field name — the menu for building your own inventory views (note the field names are the compact forms: ostype, not the “OS Type” display label) — and lun show -instance with no path dumps the full record for every LUN, which piped to a file is a serviceable point-in-time export of the estate. Both are read-only, like everything else on this page.
03Finding the NAA in the vCenter UI
The direct method, step by step Read-only
If you learn one sequence from this page, learn this one — it needs nothing installed and works from any vSphere Client session:
- Log into the vSphere Client.
- Select the ESXi host and open the Configure tab.
- Under Storage, click Storage Devices.
- Locate the NetApp device and read its Identifier — e.g.
naa.60a9800057322d6a5a71437267307358on a 7-mode system, ornaa.600a098038304e58712b5a764b6d5666on clustered ONTAP. - Drop the NetApp prefix —
naa.60a98000ornaa.600a0980, whichever the device carries. - Convert the remaining 24 hex characters to ASCII. Use the decoder on this page — it runs entirely in your browser, transmits nothing, and works out the direction automatically — or the shell one-liners in section 06. Your storage identifiers do not belong in a random website's input box; this page never sends them anywhere. The result —
W2-jZqCrg0sXor80NXq+ZvKmVfin these examples — is the 12-character LUN serial exactly as ONTAP displays it.
For a VMFS datastore Read-only
Select the datastore → Configure → General, and read the Device Backing panel: the extent's device name is the NAA identifier. Equivalent path: Configure → Device Backing directly on older vSphere Client versions. For BOS-DS01 this shows naa.600a098038304e58712b5a764b6d5666.
For any storage device on a host Read-only
Select a host → Configure → Storage Devices. Every LUN the host sees is listed by NAA name with capacity, transport and multipathing detail — the column view where the two near-identical LUNs in this environment finally look different (…5666 vs …5667). The Paths tab under the same view also tells you which target ports serve it, which is your fabric-side cross-check.
For an RDM Read-only
Select the VM → Edit Settings → expand the RDM hard disk: the Physical LUN field shows the backing device's NAA identifier. RDMs are precisely where this guide earns its keep — they are invisible in datastore views, routinely undocumented, and the first surprise of every migration.
04Finding it from the ESXi CLI
Datastore → device Read-only
The extent list maps every VMFS datastore to its backing device in one table — the fastest bulk answer on a single host.
esxcli storage vmfs extent listVolume 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 1Device detail — vendor confirmation Read-only
Given an NAA, the device record confirms you are looking at a NetApp LUN before you decode anything — read the Vendor line.
esxcli storage core device list -d naa.600a098038304e58712b5a764b6d5666naa.600a098038304e58712b5a764b6d5666
Display Name: NETAPP Fibre Channel Disk (naa.600a098038304e58712b5a764b6d5666)
Size: 4194304
Device Type: Direct-Access
Vendor: NETAPP
Model: LUN C-Mode
Is Local: false
Is SSD: true
Other UIDs: vml.02000000006...The quick filter — NetApp devices and their identifiers Read-only
Grepping the full device list down to the lines that matter turns a wall of output into a scannable table of every device and its NAA — with the ONTAP inventory from section 02 beside it, the matching is visual.
esxcli storage core device list | grep -E "Display Name|Serial Number|naa"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)Serial Number pattern in that grep. Whether a distinct Serial Number: line appears in the device list varies by ESXi release and device type (NVMe devices print one; classic SCSI LUNs on many builds do not). Keeping it in the grep costs nothing and catches it where present — and where it is absent, nothing is lost: for an ONTAP LUN the NAA line is the serial, hex-encoded after the prefix.
Everything at once Read-only
The compact mapping of VMFS volumes to devices, one line each — the classic esxcfg form many operators still reach for first.
esxcfg-scsidevs -m05PowerCLI — the whole estate at once
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.
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 -AutoSizeName NAA NetAppSerial
---- --- ------------
BOS-DS01 naa.600a098038304e58712b5a764b6d5666 80NXq+ZvKmVf
BOS-DS02 naa.600a098038304e58712b5a764b6d5668 80NXq+ZvKmVhEvery RDM in the inventory Read-only
The RDM sweep migrations always forget — every raw mapping, its VM, and its backing NAA.
Get-VM | Get-HardDisk -DiskType "RawPhysical","RawVirtual" | Select-Object Parent, Name, DiskType, ScsiCanonicalName, CapacityGB | Format-Table -AutoSizeParent Name DiskType ScsiCanonicalName CapacityGB
------ ---- -------- ----------------- ----------
bos-sql-01 Hard disk 2 RawPhysical naa.600a098038304e58712b5a764b6d5667 2,04806Decoding NAA ↔ serial, both directions
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:
echo 38304e58712b5a764b6d5666 | xxd -r -p; echo-join (("38304e58712b5a764b6d5666" -split "(..)" | Where-Object {$_}) | ForEach-Object {[char][convert]::ToInt32($_,16)})python3 -c "print(bytes.fromhex('38304e58712b5a764b6d5666').decode())"80NXq+ZvKmVfSerial → NAA Read-only
The reverse direction — you hold an ONTAP serial and need the identifier to search for in vCenter:
python3 -c "print('naa.600a0980' + '80NXq+ZvKmVf'.encode().hex())""naa.600a0980" + -join ("80NXq+ZvKmVf".ToCharArray() | ForEach-Object {"{0:x2}" -f [int]$_})naa.600a098038304e58712b5a764b6d5666+, - 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.
07Closing the loop on ONTAP
ONTAP will meet you halfway — it can display each LUN's serial already hex-encoded, which turns the correlation into a literal string match against the NAA tail. This is the cleanest verification available and the reason no decoding is strictly required at all:
lun show -vserver svm-vmware -fields serial,serial-hexvserver 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.Reverse lookup — NAA tail in hand Read-only
Paste the 24 hex characters from the NAA straight into a filtered query — the answer is the LUN path, volume and SVM in one line:
lun show -serial-hex 38304e58712b5a764b6d5666Vserver Path State Mapped Type Size
--------- -------------------- ------- -------- -------- --------
svm-vmware /vol/vmw_ds01/lun0 online mapped vmware 4TBIn 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.
08Worked example, end to end
The reclamation scenario that motivates all of this: BOS-DS01 is being evacuated and its LUN unmapped, and the change order must name the LUN beyond any doubt.
# 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.RBRunbook · condensed correlation sequence
- Build the ONTAP inventory first —
lun show -fields serial-hex(addpath,size,ostype,mappedfor the working view). This is the table every VMware identifier gets matched against. - Get the NAA — datastore: Configure → Device Backing (or
esxcli storage vmfs extent list); RDM: VM → Edit Settings → Physical LUN (or the PowerCLI RDM sweep). - Confirm the vendor prefix —
naa.600a0980(clustered ONTAP) ornaa.60a98000(7-mode). Anything else: stop, different array. - Take the 24 hex characters after the prefix — that is the serial, hex-encoded.
- Match on ONTAP —
lun show -serial-hex <24-hex>→ path, volume, SVM. Or decode to ASCII and matchlun show -serial. - Confirm the mapping —
lun mapping show→ igroup → the hosts you expect. - 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
Q01Why doesn't vCenter just show the NetApp serial?
vCenter standardises on the SCSI NAA identifier from VPD page 83 rather than parsing each vendor's serial convention. NetApp's identifiers happen to embed the serial losslessly, so nothing is hidden — it is just wearing hex.
Q02My NAA starts with 60a98000, not 600a0980 — is the method different?
Same method, older array: 60a98000 is the 7-mode-era packing of the same NetApp OUI. Strip that prefix instead and hex-decode what follows. The two prefixes are also a quick visual cue for which generation of system a device came from.
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.
Q05Are ONTAP LUN serials globally unique?
Unique within the cluster, and in practice the 12-character space plus the NAA's embedded vendor OUI makes collisions across your estate a non-concern. If two clusters in your environment ever presented the same serial (a cloned config restored somewhere it should not be), the igroup mapping check in section 07 is what catches it.
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
- NetApp ONTAP CLI — lun show (serial and serial-hex fields)
- NetApp Knowledge Base — LUN serial to NAA/device identifier correlation articles
- VMware KB 1014953 — Identifying disks when working with VMware ESXi
- VMware PowerCLI — documentation and download
- vmninja — Matching NetApp LUN serials to VMware NAA identifiers (community walk-through of this method)
- Video walk-through — identifying a NetApp LUN serial from the vSphere Client (community)
→From the same practice
- Cisco MDS Zoning: A Field Guide for NetApp AFF Dual-Fabric Setups
- Cisco MDS NX-OS Upgrade Runbook
- PowerScale (Isilon) OneFS Command Reference
- Post-OEM storage maintenance
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
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.