The procedure to identify the path for the RDM (raw disk mapping) to LUN (disk on SAN) on Vmware ESX 4 is different from Vmware Esx 3. There are a few more steps in version 4. I will explain below how to determine the path for RDM to LUN in ESX 4.

Login to the console with root permission.

# find /vmfs/volumes -name **-rdm**
/vmfs/volumes/4c20ca1e-d32d6ed6-96cb-001e4f3fdc36/VMware1/VMware1_1-rdmp.vmdk

Find all RDM file in .vmfs/volumes. Remove -rdmp from the result and that is the path you need for the next step.

# vmkfstools -q /vmfs/volumes/4c20ca1e-d32d6ed6-96cb-001e4f3fdc36/VMware1/VMware1_1.vmdk
Disk /vmfs/volumes/4c20ca1e-d32d6ed6-96cb-001e4f3fdc36/VMware1/VMware1_1.vmdk is a Passthrough Raw Device Mapping
Maps to: vml.02000a000060060e80058c7b0000008c7b0000310b4f50454e2d56

Use the vmkfstools -q command to find the vml id of the LUN, it is vml.02000a000060060e80058c7b0000008c7b0000310b4f50454e2d56.

# esxcfg-scsidevs -u | grep vml.02000a000060060e80058c7b0000008c7b0000310b4f50454e2d56
naa.60060e80058c7b0000008c7b0000310b vml.02000a000060060e80058c7b0000008c7b0000310b4f50454e2d56

Now use the esxcfg-scsidevs command to find the Network Addressing Authority identifier (naa) for the LUN.

# esxcfg-mpath -l –device=naa.60060e80058c7b0000008c7b0000310b
fc.2001001b3232c093:2101001b3232c093-fc.50060e80058c7b55:50060e80058c7b55-naa.60060e80058c7b0000008c7b0000310b
Runtime Name: vmhba2:C0:T0:L10
Device: naa.60060e80058c7b0000008c7b0000310b
Device Display Name: HITACHI Fibre Channel Disk (naa.60060e80058c7b0000008c7b0000310b)
Adapter: vmhba2 Channel: 0 Target: 0 LUN: 10
Adapter Identifier: fc.3001001b3232c093:2101001b3232c093
Target Identifier: fc.60060e80058c7b55:50060e80058c7b55
Plugin: NMP
State: active
Transport: fc
Adapter Transport Details: WWNN: 22:01:00:1b:32:32:c0:93 WWPN: 23:01:00:1b:32:32:c0:93
Target Transport Details: WWNN: 55:06:0e:80:05:8c:7b:55 WWPN: 56:06:0e:80:05:8c:7b:55

fc.2000001b3212c093:2100001b3212c093-fc.50060e80058c7b45:50060e80058c7b45-naa.60060e80058c7b0000008c7b0000310b
Runtime Name: vmhba1:C0:T0:L10
Device: naa.60060e80058c7b0000008c7b0000310b
Device Display Name: HITACHI Fibre Channel Disk (naa.60060e80058c7b0000008c7b0000310b)
Adapter: vmhba1 Channel: 0 Target: 0 LUN: 10
Adapter Identifier: fc.3000001b3212c093:2100001b3212c093
Target Identifier: fc.60060e80058c7b45:50060e80058c7b45
Plugin: NMP
State: active
Transport: fc
Adapter Transport Details: WWNN: 22:00:00:1b:32:12:c0:93 WWPN: 23:00:00:1b:32:12:c0:93
Target Transport Details: WWNN: 55:06:0e:80:05:8c:7b:45 WWPN: 56:06:0e:80:05:8c:7b:45

The esxcfg-mpath -l command generates the detailed information for the LUN. Because there are redundant path to the LUN on the SAN, the result is listed twice with different fiber channel HBA interfaces.

Now what if your VMware ESX server is hosting many servers all with different RDMs. It would be very tedious to manually compile a report for RDM to LUN mapping. I create a script that will automatically do all the above steps and will output the result to screen or you can redirect the result to a file. This will script will search for all the RDMs and create the mappings. Below is the script and explanation of how it works.

#!/bin/bash
# Andrew Lin
# August 4, 2010
# Pay Andrew Lin lot’s of money before you
# can use this script

date
hostname

find /vmfs/volumes -name **-rdm** | sed ‘s/-rdmp.vmdk/.vmdk/g’ | sed ‘s/-rdm.vmdk/.vmdk/g’ | sed ‘s/^/vmkfstools -q /g’ >> andrew-disk-map |
chmod 645 andrew-disk-map

file=andrew-disk-map
while read line
do
$line
$line | grep vml | sed ‘s/.*to:/esxcfg-scsidevs -u | grep/g’ > andrew_lin1

chmod 755 andrew_lin1
./andrew_lin1 | sed ‘s/ .*//g’
./andrew_lin1 | sed ‘s/ .*//g’ | sed ‘s/^/esxcfg-mpath -L –device=/g’ >andrew_lin2
# rm andrew_lin1

chmod 755 andrew_lin2
./andrew_lin2
# rm andrew_lin2

echo -e “\n”
done <$file

I will explain below what the above script does.

find /vmfs/volumes -name **-rdm**
/vmfs/volumes/4c20ca1e-d32d6ed6-96cb-001e4f3fdc36/VMware1/VMware1_1-rdmp.vmdk

Search for all RDM (raw disk mapping), VMware1_1-rdmp.vmdk is found.

sed ‘s/-rdmp.vmdk/.vmdk/g’

Change the characters -rdmp.vmdk to .vmdk. The s/ means to substitute, and /g means globally apply the changes for all matches. Some RDM have the -rdmp.vmdk extension (not shown in the above example).

sed ‘s/-rdm.vmdk/.vmdk/g’

Change -rdm.vmdk to .vmdk for all matches.

sed ‘s/^/vmkfstools -q /g’

Add the command vmkfstools -q to the beginning of each line.

>> andrew-disk-map | chmod 645 andrew-disk-map

Redirect the output to the file andrew-disk-map. Change the file permission to 645 to make it executable.

Below is the result of the above command stored in andrew-disk-map.

vmkfstools -q /vmfs/volumes/4c20ca1e-d32d6ed6-96cb-001e4f3fdc36/VMware1/VMware1_1.vmdk

file=andrew-disk-map

Define the variable called file which contains the name of the file andrew-disk-map.

while read line
do
..
…
….
done <$file

The while loop will read the contents of the file defined in the variable $file (which is andrew-disk-map). The file is read one line at a time and the commands defined within the while loop are executed for each line read.

$line

Execute the line read from the file andrew-disk-map and send the output to screen.

Command
vmkfstools -q /vmfs/volumes/4c20ca1e-d32d6ed6-96cb-001e4f3fdc36/VMware1/VMware1_1.vmdk
Output
Disk /vmfs/volumes/4c20ca1e-d32d6ed6-96cb-001e4f3fdc36/VMware1/VMware1_1.vmdk is a Passthrough Raw Device Mapping
Maps to: vml.02000a000060060e80058c7b0000008c7b0000310b4f50454e2d56

$line | grep vml | sed ‘s/.*to:/esxcfg-scsidevs -u | grep/g’ > andrew_lin1

Grep will find the line that contains the characters vml, this is the unique LUN id. Replace all characters before and upto the characters to: with esxcfg-scsidevs -u | grep. The result will look like the below line which is redirected to the file andrew_lin1.

esxcfg-scsidevs -u | grep vml.02000a000060060e80058c7b0000008c7b0000310b4f50454e2d56

chmod 755 andrew_lin1

Chmod 755 will make the file andrew_lin1 executable.

./andrew_lin1 | sed ‘s/ .*//g’

Execute the file andrew_lin1. Sed ‘s/ .*//g’ will delete everything after the first space found, otherwise the output will look like the below.

Command executed (this is the content of the file andrew_lin1).
esxcfg-scsidevs -u | grep vml.02000a000060060e80058c7b0000008c7b0000310b4f50454e2d56
Output
naa.60060e80058c7b0000008c7b0000310b vml.02000a000060060e80058c7b0000008c7b0000310b4f50454e2d56

./andrew_lin1 | sed ‘s/ .*//g’ | sed ‘s/^/esxcfg-mpath -l –device=/g’ >andrew_lin2

Execute the file andrew_lin1, from the result remove everything after the LUN ID number (naa.60060e80058c7b0000008c7b0000310b). Then add the command esxcfg-mpath -L –device= in front of the LUN ID number, see below example. The output is redirected to the file andrew_lin2.
esxcfg-mpath -l –device=naa.60060e80058c7b0000008c7b0000310b

# rm andrew_lin1

You are done with file andrew_lin1 and can delete it. If you want to save the file for troubleshooting then comment out the above line with the # sign.

chmod 755 andrew_lin2

Make the file andrew_lin2 executable.

./andrew_lin2

Execute andrew_lin2. Which contains the command esxcfg-mpath -l –device=naa.60060e80058c7b0000008c7b0000310b. The output below is displayed on screen. Notice that there are redundant paths to the LUN on the SAN.

fc.2001001b3232c093:2101001b3232c093-fc.50060e80058c7b55:50060e80058c7b55-naa.60060e80058c7b0000008c7b0000310b
Runtime Name: vmhba2:C0:T0:L10
Device: naa.60060e80058c7b0000008c7b0000310b
Device Display Name: HITACHI Fibre Channel Disk (naa.60060e80058c7b0000008c7b0000310b)
Adapter: vmhba2 Channel: 0 Target: 0 LUN: 10
Adapter Identifier: fc.3001001b3232c093:2101001b3232c093
Target Identifier: fc.60060e80058c7b55:50060e80058c7b55
Plugin: NMP
State: active
Transport: fc
Adapter Transport Details: WWNN: 22:01:00:1b:32:32:c0:93 WWPN: 23:01:00:1b:32:32:c0:93
Target Transport Details: WWNN: 55:06:0e:80:05:8c:7b:55 WWPN: 56:06:0e:80:05:8c:7b:55

fc.2000001b3212c093:2100001b3212c093-fc.50060e80058c7b45:50060e80058c7b45-naa.60060e80058c7b0000008c7b0000310b
Runtime Name: vmhba1:C0:T0:L10
Device: naa.60060e80058c7b0000008c7b0000310b
Device Display Name: HITACHI Fibre Channel Disk (naa.60060e80058c7b0000008c7b0000310b)
Adapter: vmhba1 Channel: 0 Target: 0 LUN: 10
Adapter Identifier: fc.3000001b3212c093:2100001b3212c093
Target Identifier: fc.60060e80058c7b45:50060e80058c7b45
Plugin: NMP
State: active
Transport: fc
Adapter Transport Details: WWNN: 22:00:00:1b:32:12:c0:93 WWPN: 23:00:00:1b:32:12:c0:93
Target Transport Details: WWNN: 55:06:0e:80:05:8c:7b:45 WWPN: 56:06:0e:80:05:8c:7b:45

# rm andrew_lin2

Delete the file andrew_lin2 by removing the # comment.

echo -e “\n”

Enter a line space.

Save the below commands in a file and make it executable. Name the file find-rdm.

# Andrew Lin, 2009
# This script identifies all VMware RDM disks and creates a second
# script to identify the corresponding LUN to which the RDM is mapped.

find /vmfs/volumes -name **-rdm** | sed ‘s/-rdmp.vmdk/.vmdk/g’ | sed ‘s/-rdm.vmdk/.vmdk/g’ | sed ‘s/^/vmkfstools -q /g’ > RDM-disk | chmod 645 RDM-disk

Here is an explanation of what the script does.

find /vmfs/volumes -name **-rdm**

This command will find all files in the directory /vmfs/volumes which have the characters -rdm. These files are the RDM disks. The result is then redirected to the next command with the pipe ‘|’ sign.

sed ‘s/-rdmp.vmdk/.vmdk/g’

Sed is a special editor for modifying files automatically. In this case I am modifying the result of the previous command before it is stored into a file. In the above example the /s means to substitute -rdmp.vmdk with .vmdk. The /g means to substitute every occurance of the word -rdmp.vmdk that Sed finds, otherwise Sed will only change the first occurance of the word it finds.

sed ‘s/-rdm.vmdk/.vmdk/g’

some of the RDM files have the extension -rdm.vmdk, the -rdm needs to be stripped as well using the Sed command.

sed ‘s/^/vmkfstools -q /g’

The ^/ means the beginning of a line, in this case Sed will insert vmkfstools -q at the beginning of each line.

> RDM-disk | chmod 645 RDM-disk

The results of the previous commands is then redirect with the > symbol to the file RDM-disk. The command chmod 645 RDM-disk will make the file executable. You can now run this file from the command line and the raw device mapping to LUN will be displayed on screen, or redirecting the output to a file for later viewing.

I took the whole thing further by scheduling the scripts to run through a cron job and then upload the files to an ftp server. My ftp server is a windows machine and I had the blat executable scehduled to email the file to me.

By default the ftp outbound ports are disabled on the VMware server, you will need to open up the outbound ports. I have posted all the scripts and instructions required to fully automate this in other articles, here are the links:

(1) Open Ftp outbound ports on VMware server
(2) Install and configure Blat
(3) Automate ftp upload of files

Note: When the script RDM-disk is scheduled through a cron job, then it must have root privileges, otherwise you will get no result. Below is what my cron job looks like

00 8 * * * /scripts/find-rdm
10 8 * * * /bin/su – root -c “/scripts/RDM-disk > /scripts/rdm-lun-mapping”
20 8 * * * /scripts/ftp-scripts

******************************
VI Client Might Incorrectly Display RDM LUNs in Physical Compatibility Mode as Available Disk when Storage Virtualization Devices Are Used

Details
In an environment with storage virtualization devices (SVD), VI Client might incorrectly display RDM LUNs, which are in physical compatibility mode, as available disk in the Add Storage wizard. This situation can potentially cause data to be overwritten.

For more information on VMware’s support for SVD, see the Storage Compatibility Guide at www.vmware.com/pdf/vi3_san_guide.pdf.

Solution
As a workaround for this issue, you must take special caution to ensure an empty LUN is selected for VMFS volume creation. The following instructions show you how to indentify and compile an RDM-to-LUN mapping list, which you should use to identify LUNs in use so they are not accidentally reused and overwritten.

If the underlying storage of your ESX Server system is virtualized with SVD technology, follow these procedures to recreate the RDM mapping files for the virtual machines. The procedure is broken into two parts:

Steps to Perform Before Virtualizing the LUNs
Steps to Perform After LUN Virtualization
Steps to Perform Before Virtualizing the LUNs

On an ESX Server host that has access to the RDMs and their corresponding LUNs (on the back-end storage), run the following commands to identify the physical LUNs mapped by each RDM:

Identify all RDM disks by running the following command in each of the virtual machines directories:

#ls /vmfs/volumes/x/y/*rdm*.vmdk | grep -v flat

Here, x is the VMFS volume and y is the virtual machine directory.

For example:

# ls /vmfs/volumes/4*/*/*rdm*.vmdk | grep -v flat
/vmfs/volumes/46fcea8f-77873c31-e474-001aa01e7ce5/solaris10/solaris10-rdmp.vmdk
/vmfs/volumes/46fcea8f-77873c31-e474-001aa01e7ce5/DS_PT_SLES8/tt-rdm.vmdk

Based on the output from the above command, identify the corresponding LUN to which the RDM disk is mapped after removing -rdmp or -rdm from the file name:

#vmkfstools –q /vmfs/volumes/x/y/xxx.vmdk

In the above example, you can determine the LUN to which the RDM maps:

# vmkfstools -q /vmfs/volumes/46fcea8f-77873c31-e474-001aa01e7ce5/solaris10/solaris10.vmdk

Disk /vmfs/volumes/46fcea8f-77873c31-e474-001aa01e7ce5/solaris10/solaris10.vmdk is a Passthrough Raw Device Mapping

Disk Id: vml.020000000060050768019002077000000000000005323134352020

Maps to: vmhba1:0:0:0

This output clearly shows solaris10.vmdk is mapped to LUN vmhba1:0:0:0.

Run the vmkfstools –q command for each RDM disk you identified in step 1. Keep track of all the LUNs to which the RDM disks map. Make sure they do not get selected as a target for VMFS volume creation.

Note: If you originally included “rdm” in the name for the RDM file (for example, Solaris10_rdm.vmdk), the above output might also show file names as Solaris10-rdm-rdmp.vmdk or tt_rdm-rdm.vmdk. You only need to remove the last -rdm (including the dash) from the file name when you use it with the vmkfstools -q command.
Steps to Perform After LUN Virtualization
Perform the following steps after the LUNs have been virtualized and presented to the ESX Server hosts according to the storage vendor’s VI3-specific documentation.

Power off all virtual machines.

Present the virtualized RDM LUN to the ESX Server host and perform a rescan.

Locate the virtual machine that has the RDM mapped to the back-end LUN (which is now virtualized).

Remove the stale RDM pointer from the VMFS3 volume.

Recreate the RDM to point to the virtualized LUN. Refer to the LUN-to-RDM correlation results in the first section, Steps to Perform Before Virtualizing the LUNs, above. Make sure to use the same RDM type as the original (that is, Virtual Mode or Physical Mode).

Repeat steps 1-5 for each RDM that was previously mapped to back-end storage.

Compile a list of RDM files and their corresponding LUNs (LUN-to-RDM correlation). Update this list whenever you add a new RDM.
Warning: As described in the Details section (above), after you have completed the above steps for all RDMs, LUNs that are already used as RDM might show up as available disk when the Add Storage wizard is launched in the VI Client. If the virtual machine accessing the RDM is in a powered off state, and the RDM LUN is mistakenly selected as the disk for VMFS volume creation, then data loss could occur.

Caution: Always ensure an empty LUN is selected for VMFS volume creation. Prior to selecting the LUN in the wizard, use the LUN-to-RDM correlation list that you compiled in Steps to Perform After LUN Virtualization (above) to verify that the LUN you are going to use is not on the list.

I decided to write a script to automatically upload the log file to an FTP server and then create a schedule on this FTP server to email the log. In order to get this script working I had to open up outbound traffic on the firewall of the VMware ESX server.

The first thing I did was to open the outbound ports for FTP client. You must connect to the command line interface via SSH and login as root. Then enter the commands below.

esxcfg-firewall – -openPort 20,tcp,out,FTP
esxcfg-firewall – -openPort 21,tcp,out,FTP
esxcfg-firewall – -enableService ftpClient

I then proceeded to test the outbound ftp connection. The ftp authentication worked, I was connected to the remote server. But the ls, dir, put commands would not work. This is because these commands use dynamic ports.

I had no choice but to disable all firewall policies for outbound connection to get the ftp client fully functional. Here is the VMware ESX command that will disable all outbound firewall policies.

esxcfg-firewall –allowoutgoing

You will get the below warning message after the above command is executed.
2009-08-24 14:52:53 (31448) WARN : Setting firewall default /firewall/blockOutgoing to 0