As virtual infrastructures become more common in information technology, there are opportunities to expand the reach of the overtaxed administrator to more succinctly document and troubleshoot your SAN (Storage Area Network) storage configuration. For the VMware implementation that consolidates Windows servers to a VMware ESX environment, the SAN storage competency requirements are increased.
In this tip, I'll provide some points that you can use within VMware infrastructure to get your SAN information correct for better documentation and troubleshooting. In the examples given, I'm using the IBM SAN Volume Controller (SVC) with VMware ESX 3, but the best practices I suggest apply to SAN management in general.
Making the transition to enterprise storage
Many administrators, including myself, have gone through the arduous task of adjusting the thought process to revolve around enterprise storage. Quite simply, SAN storage is a superior solution for the virtualized environment when administered correctly. In most successful implementations, roles are clearly defined for storage, networking, and server administrators and engineers. However, the VMware server administrator should be able to retrieve detailed information about many aspects of the ESX environment.
Networking, operating system (OS), and server hardware inventories require little learning curve for the standard administrator, however the storage space incurs the most learning curve. Storage also happens to be the single most important element of virtualization planning. Being able to retrieve the LUN (Logical Unit Number) serial number can lend your SAN administrator a hand in situations where systems are migrated, changed, repurposed, or you are moving LUN allocations around from one server to another.
LUN serial numbers
In IBM SVC environments, many Windows and UNIX administrators are familiar with the datapath query device command as part of the IBM subsystem device driver (SDD) toolkit. VMware ESX provides a native driver for most host bus adaptor (HBA) interfaces to present themselves to the SAN, so the familiar IBM driver commands are not available as we have come to know them in the SAN world for most Windows and UNIX installations. For this situation, we will present some new ways to determine the drive serial number in the same fashion as the SDD (subsystem device driver) command in VMware ESX 3.
One way to obtain the drive serial number is to read the device file. The first step in this method is to get to the path of the LUN's visible within ESX, this is the /proc/VMware/scsi/vmhba0 path. There will be seven directories in the /scsi path going from vmhba0 to vmhba6. Inside of the paths, are files in the format of x:y, where x is the SCSI ID and y is the LUN number. There is no extension on the file. Note these files actually contain the colon character, so if you copy them off to a Windows file system, you will need to use to a different file name. If you only have one LUN, one file would be present in the path in the x:y format. If you have multiple LUN's, the files will be located as individual file for each LUN.
To view the files, the easiest way is to use the Linux more command in the format: more 0:1 to view one file named 0:1. It goes without saying that this file should only be read, and not written to outside of ESX writing to the file. As a safe process, only use more and never use vi to view these files. The output of the file will contain all of the information relevant to the LUN. This includes size of the LUN, information on adapter type and model, and the serial number. Below is a sample output of running this command with only the top of file shown:
[root@corpesxvm005 vmhba1]# more 0:0 Vendor: IBM Model: 2145 Rev: 0000 Type: Direct-Access ANSI SCSI revision: 05 Id: 60 1 2 28 2 73 0 3 10 0 0 0 0 0 0 e3 32 31 31 34 21 20 Size: 327680 Mbytes Queue Depth: 32 Block size: 512 Num Blocks: 671088640
In this example, the
Another powerful tool is the esxcfg-mpath command. The esxcfg-mpath has many options to quickly display all information about the LUNs and HBA available to the ESX host. Among the command sequences are:
- esxcfg-mpath –a displays all HBA interfaces available to the ESX host and the WWPN associated with each host. For QLogic interfaces, this will match the ordering in the BIOS of the HBA controller.
- esxcfg-mpath –l displays a list of LUNs and their paths. This display output will also specify which is the active preferred path in the SAN connectivity for each LUN available to the host.
- esxcfg-mpath –l –v displays the verbose configuration of the LUN inventory. This display will contain the serial number, but it is harder to discern than simply viewing the ID section of the x:y file described earlier.
The LUN serial number will be located on the first line for each section for each LUN. Take the following example that has the first two lines of a verbose iteration:
[root@ corpesxvm005 root]# esxcfg-mpath -l -v Disk vmhba1:0:0 vml.0200000000600102280273000310000000000000e3323131342120 /dev/sda (327680MB) has 8 paths and policy of Most Recently Used
The LUN serial number is the section highlighted in italics from the string. Note the same six fields are present here but are not part of the serial number. The esxcfg-mpath command will deliver more information about the LUN configuration, whereas the x:y file will have some additional information about LUN contents and basic I/O statistics. The esxcfg-mpath command can also make configuration changes for the LUN inventory and preferred path. A best practice would be to do this in the VMware Infrastructure Client for any changes to the LUN configuration.
Sharpening the ESX sword
Most administrators can figure out the VMware infrastructure easy enough for information such as WWPN number, basic disk geometry, and the number of paths for the connectivity. However, when information -- such as the LUN serial number -- cannot be obtained directly through the interface, it is worth taking the time to learn some commands available through the console through some of the commands highlighted in this SearchVMware.com tip.
About the author
Rick Vanover is a MCSA-certified system administrator for Belron p in Columbus, Ohio. Previous roles included software engineering roles with Siemens and Dematic in Grand Rapids, Michigan, working with complex supply chain execution systems. Rick has been working information technology for over 10 years and virtualization technologies for over seven years. He has been publishing articles online for over six years.