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.
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 LUNsOn 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.
# ls /vmfs/volumes/4*/*/*rdm*.vmdk | grep -v flat
- 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.