How to get the WWID of the disk within a RHEL guest on VMware ESX host?
Environment
- Red Hat Enterprise Linux (RHEL) 5, 6, 7, 8, 9
- VMware ESX 4.1
Issue
- Why
scsi_id
command is not returning disk WWID when run against VMware virtual disks? [ANS] - Running
scsi_id
command on a VMware virtual disk returns no output. [ANS] - I need a WWID for a VMware guest disk for udev rules, how do I find it? [ANS]
- How do I find the sdX name of a disk in the RHEL guest when I have the allocated disk resource information from the hypervisor? [ANS]
- How do I identify the allocated resource within the VMware hypervisor when I know the sdX name within the RHEL guest? [ANS]
- How to obtain a WWID from a VMware guest? [ANS]
- How to find WWID of the
sd
devices to create UDEV rules for VMware exported disk. [ANS] - How to find WWID of the disk in a RHEL guest on ESX host. [ANS]
- How to match sd device to vmdk on the VMware host side using WWID? [ANS]
- Does this work on vmdk based virtual disks exported from VMware to a RHEL guest? [ANS]
-
Facing issue in finding the mapping of SCSI ID on VMware to SCSI ID on linux [ANS]
-
multipath fails to create multipath device with the error : "cannot get the the wwid for sdX" on VMware guest, multipath -v4 shows the following errors :
multipath -v4 -----snip---- /lib/udev/scsi_id exitted with 1 cannot get the the wwid for sda
Resolution
- How to identify the same disk in the hypervisor and guest
- How to use WWIDs inside udev rules to identify a disk
- VMware Hypervisor Steps to Enable Disk Identification Export to Guest
- Post Change Verification
- Common Questions
- Related:
VMware Hypervisor Steps to Enable Disk Identification Export to Guest
Disclaimer: The following information has been provided by Red Hat, but is outside the scope of the posted Service Level Agreements and support procedures. The information is provided as-is and any configuration settings or installed applications made from the information in this article could make the Operating System unsupported by Red Hat Global Support Services. The intent of this article is to provide information to accomplish the system's needs. Use of the information in this article at the user's own risk.Cautions!
- Contact VMware technical support if these steps do not work as expected or for additional guidance..
- For more detailed instructions on how to change VMware settings, in this or later versions of the hypervisor, contact VMware technical support.
- The ability and methods used by VMware to export WWIDs for vmdk based, and other virtual device types exported to the RHEL guest, may be changed by VMware. If the verification method do not show the expected values after applying the steps shown below, then contact VMware for further support.
- The
scsi_id
location changed starting in RHEL7 release: it is no longer in a place where the standard PATH search will locate it. Starting in RHEL7 the location is `/usr/lib/udev/scsi_id`. This document references this path when referencing the commands within generic discussions. You will need to use version appropriate `scsi_id` syntax for other releases.
-
Below steps apply on VMware ESX 4.1 version.
- Method #1:
- Shut down your virtual machine
- Right-click the VM’s entry in the left-hand panel and select Edit Settings
- Click the Options tab
- Select the Advanced -> General item on the left and click the Configuration Parameters… button you then see displayed on the right
- Click the Add Row button
- Add
disk.EnableUUID
as the name of the new row, and the wordTRUE
as its value (don’t use quotation marks around either of these entries). - Click OK to make the new parameter addition ‘stick’.
-
Method #2: Edit guest vmx file
- Alternatively, you may be able to achieve the same thing by editing the guest vmx file within the VMware hypervisor and adding the following line:
disk.EnableUUID = "TRUE"
-
Power on or reboot the VMware guest so changes are applied
- Method #1:
Verification
- The steps to enable
disk.UUID
attribute within ESX have been applied - The VM guest was powered on or rebooted after
disk.UUID
enabled within ESX -
Verify WWID (disk.UUID) is being provided to RHEL guest from VMware hypervisor by using the scsi_id command. To get the WWID of say,
/dev/sda
, run this command:Ifscsi_id
produces no output, contact VMware for additional ESXi configuration support.-
# /lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/sda 36000c2931a129f3c880b8d06ccea1b01
-
For RHEL6
# scsi_id --whitelisted --replace-whitespace --device=/dev/sda 36000c2931a129f3c880b8d06ccea1b01
-
For RHEL5
#scsi_id -g -u -s /block/sdb 36000c2931a129f3c880b8d06ccea1b01
-
How to use WWIDs within udev rules
-
Using WWIDs is within udev rules is the preferred method of identifying the disk to apply an action to. Kernel assigned names such as 'sda', are not persistent across boots. A common action for a udev rule is to setup up a permanent user specified disk name for use within your system. For example the following sets up
/dev/mydeviceX
links to the specified device, where X is the partition number.-
RHEL8 udev rule syntax
KERNEL=="sd*", ENV{ID_SERIAL}=="36000c2931a129f3c880b8d06ccea1b01", SYMLINK+="mydevice%n"
-
RHEL7 udev rule syntax
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/lib/udev/scsi_id --whitelisted --replace-whitespace --device=%N", \ RESULT=="36000c2931a129f3c880b8d06ccea1b01", SYMLINK+="mydevice%n"
-
RHEL6 udev rule syntax
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=%N", \ RESULT=="36000c2931a129f3c880b8d06ccea1b01", SYMLINK+="mydevice%n"
-
RHEL5 udev rule syntax
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="36000c2931a129f3c880b8d06ccea1b01", \ SYMLINK+="mydevice%n"
-
How to identify the same disk in the hypervisor and guest
A common issue can arise where you need to have a unique, common, and persistent disk identifier so that you can:
- use the same identifier from a guest sdX disk within the VMware hypervisor to locate a vmdk resource that is generating media errors on the guest side,
- use the same identifier from a guest sdX disk for udev rules as sdX names are not guaranteed to be consistent across boots,
- use the same identifier from a vmdk within VMware hypervisor to locate the newly added sdX disk name on the guest side.
- Adding and removing disks from a guest can result in changing kernel assigned sdX name. In addition, the scsi address can change also.
This might be described via something like:
We are seeing SCSI controller ID sequence differences when new SAN disks are added or removed from guest. On VMwark side the scsi id for /dev/sdn is SCSI[0:11], but on the guest is was [21:0:0:0] but changed to [22:0:0:0] and back again as the SAN disks were added/removed. How we can find exact SCSI ID in this way on server to match it with vmware disk?
The solution is, instead of using a kernel assigned identifier such as scsi address or sdX name which are non-persistent across boots, use a self-identifier that is provided from the disk itself which is persistent across reboots. In that way, no matter the order or movement of the disk physically or virtually as seen at discovery time, or as disks are added and removed, the same identifier can always be used to positively identify the device. This allows udev rules, device mounting, and other system administration tasks to always correctly specify the disk that is the target of that current admin action.
In summary:
- non-persistent: sdX and [21:0:0:0] scsi addresses are associated with the kernel's discovery order and is kernel assigned based upon that discovery order
- with parallel discovery order, assigned sdX names, scsi addresses and the like are not guaranteed to be consistent across reboots
- with the addition or removal of luns assigned to a guest, the discovery order and thus sdX naming assignment, can change
- RHEL kernel assigned designations, from scsi address to sdX names are for devices only on the guest will not be the same values as seen in the hypervisor
- persistent: an identifer that is associated with a disk (including vmdk disks), the same persistent identifier for a disk will be returned no matter what the kernel assigned sdX name or scsi address is
- a device's persistent identifier is the same within the hypervisor or guest so can be used at the search key to find the same device under both
- a device's persistent identifier is the same across boots, so udev rules and other commands can use this persistent identifer to support applying actions to the same device each time
A disk's WWID can be used to locate the same device in either ESX or Guest.
A device's WWID (World Wide IDentifier) is the technical solution to the above problem. WWIDs are persistent. Within the VMware hypervisor control of whether a WWID is available to the guest is controlled by the disk.UUID
feature. Follow the steps outlined above to enable disk.UUID
within the hypervisor.
See additional information on non-persistent and persistent device names within the kernel documentation:
RHEL 8
: "Managing Storage Devices: Chapter 4. Overview of persistent naming attributes" and this may be referenced forRHEL 9
as wellRHEL 7
: "Storage Administration Guide: 25.8. Persistent Naming"RHEL 6
: "Storage Administration Guide: Chapter 28. Persistent Naming"
Commonly Asked Questions
- Why
scsi_id
command is not returning disk WWID when run against VMware virtual disks? - Running
scsi_id
command on a VMware virtual disk returns no output.
The
disk.UUID
VMware feature needs to be enabled within the hypervisor. Follow steps outlined above. This is valid for vmdk provisioned devices and other other such virtual devices supplied by VMware to the guest.When the
disk.UUID
VMware feature is not enabled, thenscsi_id
generates no output.# /usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/sda #
The kernel depends on information returned from the device in order to provide a WWID or other unique identifier. In the cases of virtual disks, this information must be supplied by the VMware hypervisor.
The nominal method used within
scsi_id
command to obtain this information is to use the output from scsi INQUIRY command to fetch VPD (vital product data) information from either page 83 (device identification) or, if that is not available, page 80 (unit serial number). In the case of vmdk based virtual disks provided to the RHEL guest, these pages are not be available until the `disk.UUID` feature is enabled within the hypervisor. So the root cause when blank output is generated from `scsi_id` for virtual disks is the lack of appropriate VPD information being provided from the hypervisor. To correct this, enable the disk.UUID feature within the VMware hypervisor by following the [steps outlined above](#STEPS).You can use the following commands from the `sg3_utils` package to see whether the hypervisor is providing a WWID or not.
disk.UUID
disabled:# sg_inq -p 0x83 /dev/sda VPD INQUIRY: Device Identification page inquiry: field in cdb illegal (page not supported)
disk.UUID
enabled:
# sg_inq -p 0x83 /dev/sda VPD INQUIRY: Device Identification page Designation descriptor number 1, descriptor length: 20 designator_type: NAA, code_set: Binary associated with the Addressed logical unit NAA 6, IEEE Company_id: 0x0c29 Vendor Specific Identifier: 0x31a129f3c Vendor Specific Identifier Extension: 0x880b8d06ccea1b01 [0x600.0c293.1a129f3c880b8d06ccea1b01]
- Does this work on vmdk based virtual disks exported from VMware to a RHEL guest?
Yes. Enabling the
disk.UUID
works with vmdk devices so that the guest can obtain a WWID for sdX virtual disks.
- I need a WWID for a VMware guest disk for udev rules, how do I find it on the RHEL guest?
- How to obtain a WWID from a VMware guest (RHEL sdX disk)?
Use the
scsi_id
command to obtain the WWID for a sdX device:# /usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/sda 36000c2931a129f3c880b8d06ccea1b01
If blank, verify disk.UUID is enabled within the VMware hypervisor. If problems still exist, contact VMware for assistance.
- How do I find the sdX name of a disk in the RHEL guest when I know have the allocated disk resource information from the hypervisor?
- How to find WWID of the
sd
devices to create UDEV rules for VMware exported disk. - How to find WWID of the disk in a RHEL guest on the ESX host.
Using the disk.UUID from the VMware hypervisor, search each RHEL guest sdX for a match. For example:
# ls -1cv /dev/sd* | grep -v [0-9] | while read disk; do \ echo -n "$disk " ; /usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=$disk ; done | grep 36000c2931a129f3c880b8d06ccea1b01 /dev/sda 36000c2931a129f3c880b8d06ccea1b01
If blank output for
scsi_id
, then verify disk.UUID feature within the VMware hypervisor is enabled. If problems still exist, contact VMware for assistance.
- How do I identify the allocated resource within the VMware hypervisor when I know the sdX name within the RHEL guest?
- How to match sd device to vmdk on the VMware host side using WWID
Get the WWID from the RHEL guest side for the sdX in question:
# /usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/sda 36000c2931a129f3c880b8d06ccea1b01
Find the matching WWID on the VMWare hypervisor side
- From the ESX(i) console
# vmkfstools -J getuuid /vmfs/volumes/datastore/rhel/rhel.vmdk 60 00 c2 93 1a 12 9f 3c 88 0b 8d 06 cc ea 1b 01
Root Cause
- VMware by default does not report the WWID (export UUID) of the virtual disks to Linux guests.
- The default for pass through devices (non-vmdk devices) is different and should report the WWID to Linux unless there are further limitations of the actual storage hardware that does not provide that information.
Diagnostic Steps
Without disk.EnableUUID
set to TRUE
executing
# /sbin/scsi_id -g -u -s /block/sdb
#
Will not return anything and it will not be possible to identify disk WWID.
Example output after enabling export of UUID from within the VMWare hypervisor:
# cat /sys/block/sda/device/model
VMware Virtual S
# scsi_id --whitelisted /dev/sda
36000c2937ec2f4b3e090f5b8f4b2bef2
# ls -l /dev/disk/by-id | grep sda
lrwxrwxrwx. 1 root root 10 Jul 30 17:23 wwn-0x6000c2937ec2f4b3e090f5b8f4b2bef2 -> ../../sda
Example where one device returns a scsi identfier but another one does not
Configuration has two disks, sda and sdb. Device sdb appears to be a pass-thru device.
# echo " " ; echo "#scsi_addr Type Vendor Model Rev sdN" ; \
echo "#----------- ------- ------- ----------------- ------ ------------- " ; \
lsscsi
#scsi_addr Type Vendor Model Rev sdN
#----------- ------- ------- ----------------- ------ -------------
[0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[2:0:2:0] disk DGC VRAID 0532 /dev/sdb
The following command should list all scsi identifiers for all /dev/sd* within the configuration:
# ls -v -1c /dev/sd*[!0-9] | xargs -I {} sh -c 'echo -n "{} : " ; /lib/udev/scsi_id --whitelisted --device={}' sda : sdb : 360060160dfc02c00ce7fabaf69999999
However, scsi_id did not return any information for device sda. Repeat the two scsi_id commands with strace in order to gather additional debugging information. First the "good" device whereby scsi_id outputs a device identifier:
# strace /lib/udev/scsi_id --whitelisted --device=/dev/sdb
:
123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.
open("/dev/sdb", O_RDONLY|O_NONBLOCK) = 3
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 32), ...}) = 0
ioctl(3, SG_IO, {'Q', 0 /* SG_DXFER_??? */, cmd[0]=[], mx_sb_len=0,
iovec_count=0, dxfer_len=6, timeout=0, flags=0x20}) = -1 EINVAL (Invalid argument)
A ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 00, 00, 00, fe, 00],
mx_sb_len=32, iovec_count=0, dxfer_len=254, timeout=5000, flags=0,
data[254]=["\0j\0042\2748\20\2DGC VRAID "...], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0
close(3) = 0
open("/etc/scsi_id.config", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/dev/sdb", O_RDONLY|O_NONBLOCK) = 3
B ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 01, 00, 00, fe, 00],
mx_sb_len=32, iovec_count=0, dxfer_len=254, timeout=5000, flags=0,
data[254]=["\0\0\0\10\0\200\203\205\260\261\262\300 VRAID "...], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0
C ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 01, 80, 00, fe, 00],
mx_sb_len=32, iovec_count=0, dxfer_len=254, timeout=5000, flags=0,
data[254]=["\0\200\0\16APM00131904965AID "...], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0
D ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 01, 83, 00, fe, 00],
mx_sb_len=32, iovec_count=0, dxfer_len=254, timeout=5000, flags=0,
data[254]=["\0\203\0008\1\3\0\20`\6\1`\337\300,\0\316\177\253\257c5\345\21\1\0\0\20\0\2\0\0"...], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0
close(3) = 0
fstat(1, {st_mode=S_IFREG|0644, st_size=4576, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff6e97d4000
E write(1, "360060160dfc02c00ce7fabaf69999999"..., 34360060160dfc02c00ce7fabaf699999991
) = 34
exit_group(0) = ?
The scsi_id code does a standard INQUIRY (A) command. This is followed by an INQUIRY of page 00 (B) which returns all available pages supported by this device. The returned list of pages includes page 80, where the serial number is located as well as page 83 where the WWID is located. Then and INQUIRY of page 80 (C) is performed, and finally INQUIRY of page 83 (D). All those complete successfully, and the WWID retrieved from the device is displayed (E) and scsi_id exits with status of 0. The WWID itself is "60060160dfc02c00ce7fabaf69999999", the "3" take leads that string is added by scsi_id to identify the source and type of scsi identifier being output. See "How are SCSI ID generated?" for more information on prefix characters and how SCSI identifiers are created.
Now for device sda which did not return back any identifier:
# strace /lib/udev/scsi_id --whitelisted --device=/dev/sda
:
open("/dev/sda", O_RDONLY|O_NONBLOCK) = 3
fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 0), ...}) = 0
ioctl(3, SG_IO, {'Q', 0 /* SG_DXFER_??? */, cmd[0]=[], mx_sb_len=0, iovec_count=0, dxfer_len=6, timeout=0, flags=0x20}) = -1 EINVAL (Invalid argument)
A ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 00, 00, 00, fe, 00],
mx_sb_len=32, iovec_count=0, dxfer_len=254, timeout=5000, flags=0,
data[254]=["\0\0\2\2\37\0\0sVMware Virtual disk "...], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0
close(3) = 0
open("/etc/scsi_id.config", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/dev/sda", O_RDONLY|O_NONBLOCK) = 3
B ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 01, 00, 00, fe, 00],
mx_sb_len=32, iovec_count=0, dxfer_len=254, timeout=5000, flags=0,
data[254]=["\0\0\2\2\37\0\0sVMware Virtual disk "...], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=1, info=0}) = 0
close(3) = 0
exit_group(1) = ?
Here the INQUIRY of page 00 (B) response as seen in data[254]=
is the same standard inquiry data as seen in the output of (A) instead of the list of pages happened with device sdb. This means this device does not support any inquiry pages at all and therefore scsi_id cannot retrieve a serial number or a WWID from the device -- the required inquiry pages that scsi_id needs are not supported by the hypervisor for these devices. No identifier is output and scsi_id exists with a status of 1. The storage configuration for this vm guest within the hypervisor needs to changed to correct this behavior such that it provides the data upon an INQUIRY IO sent to the device to retrieve pages 00, 80, and 83 is completed successfully with the expected and required data.
The same three commands can be performed manually if the sg3_utils package is installed on the guest.
# sg_inq /dev/sda
# sg_inq -p 0x00 /dev/sda ; needs to return list of pages and must include at least page 80
# sg_inq -p 0x80 /dev/sda
# sg_inq -p 0x83 /dev/sda
Example 1: no page list supported
# sg_inq /dev/sda
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 BQue=0
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: VMware,
Product identification: VMware Virtual S
Product revision level: 1.0
# sg_inq -p 0x00 /dev/sda
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 BQue=0
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: VMware,
Product identification: VMware Virtual S
Product revision level: 1.0
# sg_inq -p 0x80 /dev/sda
VPD INQUIRY: Unit serial number page
inquiry: field in cdb illegal (page not supported)
# sg_inq -p 0x83 /dev/sda
VPD INQUIRY: Device Identification page
inquiry: field in cdb illegal (page not supported)
Returning the same standard inquiry data for a page 00 request indicates that the storage does not support any inquiry pages.
Example 2: page list supported, but neither page 80 or 83 present
# sg_inq /dev/sda
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 BQue=0
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: VMware,
Product identification: VMware Virtual S
Product revision level: 1.0
# sg_inq -p 0x00 /dev/sda
VPD INQUIRY, page code=0x00:
[PQual=0 Peripheral device type: disk]
Supported VPD pages:
0x0 Supported VPD pages
0xb1 Block device characteristics (sbc3)
# sg_inq -p 0x80 /dev/sda
VPD INQUIRY: Unit serial number page
inquiry: field in cdb illegal (page not supported)
# sg_inq -p 0x83 /dev/sda
VPD INQUIRY: Device Identification page
inquiry: field in cdb illegal (page not supported)
In this case the inquiry pages is supported, but neigher page 80 or 83 is present so again scsi_id will be unable to obtain an identifier from the storage device and there will be no output from scsi_id command.
Example 3: page list supported, both page 80 or 83 present
# sg_inq /dev/sda
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 BQue=0
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: VMware,
Product identification: VMware Virtual S
Product revision level: 1.0
# sg_inq -p 0x00 /dev/sda
VPD INQUIRY, page code=0x00:
[PQual=0 Peripheral device type: disk]
Supported VPD pages:
0x0 Supported VPD pages
0x80 Unit serial number
0x83 Device identification
0xb1 Block device characteristics (sbc3)
# sg_inq -p 0x80 /dev/sda
VPD INQUIRY: Unit serial number page
Unit serial number: 9999999999999999
# sg_inq -p 0x83 /dev/sda
VPD INQUIRY: Device Identification page
Designation descriptor number 1, descriptor length: 20
designator_type: NAA, code_set: Binary
associated with the addressed logical unit
NAA 6, IEEE Company_id: 0x569
Vendor Specific Identifier: 0x1001c678d
Vendor Specific Identifier Extension: 0xf7382d030c57d0d2
[0x60005691001c678df7382d030c57d0d2]
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments