Samsung 980 Pro NVMe SSD serial in ESXi is in different byte order than the sticker
Posted by jpluimers on 2022/02/03
I installed three Samsung 980 Pro NVMe SSD devices in various ESXi rigs.
This is the serial numbers that ESXi came up with:
- Local NVMe Disk (t10.NVMe____Samsung_SSD_980_PRO_1TB_________________E824B311B1382500)
- Local NVMe Disk (t10.NVMe____Samsung_SSD_980_PRO_1TB_________________782DB311B1382500)
- Local NVMe Disk (t10.NVMe____Samsung_SSD_980_PRO_1TB_________________6F2DB311B1382500)
ESXi presents the serial number (actually the EUI64) in reverse byte order of what is on the device labels.
I had to look up what EUI64 was, and it is a kind of UUID (see Universally unique identifier – Wikipedia), but for hardware devices:
- World Wide Name – WikipediaEach WWN is an 8- or 16-byte number, the length and format of which is determined by the most significant four bits, which are referred to as an NAA (Network Address Authority). The remainder of the value is derived from an IEEE OUI (or from Company Id (CID)) and vendor-supplied information. Each format defines a different way to arrange and/or interpret these components. OUIs are used with the U/L and multicast bits zeroed, or sometimes even omitted (and assumed zero). Though CID has U/L set to 1.The WWN formats include:…
- “Mapped EUI-64” formats manage to fit an EUI-64 address into an 8-byte WWN. Since the NAA is mandatory, and takes up a nibble, this represents a four-bit deficit. These four bits are recouped through the following tricks: First, two bits are stolen from the NAA by allocating NAAs 12, 13, 14, and 15 to all refer to the same format. Second, the remaining two bits are recouped by omitting the U/L and multicast bits from the EUI-64’s OUI. When reconstructing the embedded EUI-64 value, the U/L and multicast bits are assumed to have carried zero values.
…
- [Wayback] Base NVM Express – Part One – NVM Express
A namespace ID (NSID) is an identifier used by a controller to provide access to a namespace (handle to a namespace). An NVMe controller may support multiple namespaces that are referenced using NSID. EUI64 (8 bytes), NGUID (16 bytes) and UUID (128-bit) are globally unique namespace identifiers defined in the Base Specification.
- [Wayback] VMware Docs: NVMe Devices with NGUID Device Identifiers
For NVMe devices, ESXi generates device identifiers based on the information it retrieves from the devices. Generally, the NVMe devices support identifiers in EUI64 or NGUID formats, or use both formats. NGUID is a Namespace Globally Unique Identifier that uses the EUI64 16-byte designator format.
- [Wayback] ESXI6.7 nvme ssd issue – VMware Technology Network VMTN
Being a software engineer, I am disturbing by the way this software create the disk ID.
According to the following table from VMware Docs we have some case that the software will not recognize the disk or lost disks.
ID Formats Supported by Device Device Identifier Generated by Host EUI64 ID Format NGUID ID Format ESXi 6.7 and earlier ESXi 6.7 Update 2 yes yes t10.xxx_EUI64 t10.xxx_EUI64 yes no t10.xxx_EUI64 t10.xxx_EUI64 no yes t10.xxx_controller_serial_number eui.xxx (NGUID) as primary ID t10.xxx_controller_serial_number as alternative primary ID
so what if
- The NVMe SSD from the same company may use the same EUI64 for every NVMe SSD on the same interface (say using an ASUS Hyper M.2 X16 PCIe 3.0×4 Expansion card with 4 identical NVMe SSD). It is possible because of bad design from the SSD manufacturer, the EUI64 are all the same for the 4 NVMe SSD, under this case, the ESXI will only recognized one of the 4 disks (since the disk will be t10.xxx_EUI64, and EUI64 are the same for all 4 NVMe SSD, The “storage” “adapters” tab did show there are 4 interfaces (adapters), but the “stroage” “devices” will only show 1 disks.
- Why there is no “no, no” options?
I understand that the NVMe standard 1.3 (for ESXi 6.7) is the base of how the NVMe SSD should be designed, but I think the software should be smart enough to cover the mistakes the hardware company may make and so it can recognized most of the NVMe SSD that is available from the market.
…
I have the same issue in V7.0! Whatever happened to using something you know is unique like serial numbers or something based off the serial number!
My two identical NVMe drives show up as one! Very odd how this one got through testing!
…
Having same issue with the Asus hyper x16 m. 2 pcie card. I have 4 Intel 660p in it and it’s only showing 1. Even when I changed the bifurcation to x4x4x4x4 for that pcie slot. It actually show nothing. When in auto it shows 1. I’m using esxi 7 though. Trying to test out VMware horizon but esxi not detecting all the nvme in the Asus adapter.
- [Wayback/Archive.is] linux.kernel: [PATCH 0/7] Implement NVMe Namespace Descriptor Identification
This patchset implemets NVMe Namespace Descriptor Identification as of
NVMe 1.3. The Namespace Descriptor Identification allows a NVMe host
to query several Namespace Identification mechanisms, such as EUI-64,
NGUID and UUID from the target. If more than one value is set by the
target, it can transmit all set values to the host.- [Wayback] OS-6042: Need to handle NVMe devices with EUI64 values (SmartOS + ZFS)
NVMe devices with namespaces with an EUI64 value do not attach to the system. It’d be good if these did.
- [Wayback] ⚙ D19905 bhyve: Add EUI64 to NVMe device (FreeBSD)
Add the EUI64 field (part of the Identify Namespace data) to NVMe devices to support UEFI drivers.
The implementation will accept an IEEE Extended Unique Identifier (EUI-64) from the command line. If one isn’t provided, it will create one based on
- The IEEE OUI reported in the Identify Controller data
- The PCI bus, device/slot, function values
- The Namespace ID
- [Wayback] nvme-scsi: Use correct byte ordering for eui64 in Dev ID VPD – Patchwork
NVME specifies an EUI64/NGUID in little-endian format, while SCSI specifies that the Device Identification VPD use big-endian for EUI formats. The current code copies this bytestream directly from the Identification Namespace page, meaning we just need to reverse the bytestream when passing it on to the VPD.…
This seems to hold true for NGUID devices, but Keith just pointed out to me that it may not hold true for EUI64 devices. It seems like that case needs byte swiveling within each field. So I'll NAK for now until I can figure out if that's the case.…
This will break existing setups that rely on VPD 0x83 for device identification (which I think includes older SuSE distros). And once you change the setup anyway please stop using this buggy SCSI emulation.…
- [Wayback] A Quick Tour of NVM Express (NVMe)
…
- nguid, Namespace Globally Unique Identifier (NGUID) and, eui64, IEEE Extended Unique Identifier (EUI64) are assigned when the namespace is created and preserved across namespace and controller operations (e.g. reset, format).
…
These are pictures of the devices in the same order:
- .
Samsung 980 Pro NVMe SSD 002538B111B324E8
- .
Samsung 980 Pro NVMe SSD 002538B111B32D78
- .
Samsung 980 Pro NVMe SSD 002538B111B32D6F
–jeroen
The Wiert Corner - irregular stream of stuff 
Leave a Reply