VMware ESXi and vSphere Cluster Management
Add a Raw LUN to a VMware ESXi Virtual Machine Using Raw Device Mapping
Learn how to attach a SAN LUN to a VMware virtual machine with RDM, choose physical or virtual compatibility mode, validate the guest disk, and avoid data loss.
A Raw Device Mapping (RDM) lets vSphere present a SAN logical unit number (LUN) directly to a virtual machine. The guest operating system uses the LUN for its application data, while vSphere maintains a small mapping file on a VMFS datastore.
This design differs from a standard VMDK. A standard virtual disk stores its data inside a virtual disk file on a datastore. An RDM stores only device-mapping metadata in its .vmdk mapping file; the actual data remains on the SAN LUN.
How RDM Storage Works
A LUN is an addressable logical storage device presented by a SAN. A SAN, or Storage Area Network, provides block storage to ESXi hosts through storage adapters and one or more paths.
When you add an RDM disk, vSphere creates a small descriptor, or mapping, file with a .vmdk extension on a VMFS datastore. The file records information needed to associate the virtual disk with the raw SAN device. It does not contain the application data stored on that device.
| Component | Location | Purpose |
|---|---|---|
| RDM mapping file | Selected VMFS datastore | Stores device-mapping metadata and presents the SAN device to the VM |
| Raw SAN LUN | SAN storage system | Holds the guest or application data |
| Virtual SCSI controller | VM virtual hardware | Presents the RDM disk to the guest |
| Guest operating system disk | Inside the VM's device inventory | Provides the disk for partitions, file systems, volume groups, or application-managed storage |
The relationship is therefore: guest application, virtual SCSI controller, RDM mapping file, ESXi storage stack, and SAN LUN. The mapping file is required for the VM configuration, but it is not a replacement for the underlying LUN.
When to Use an RDM
- Use an RDM when a guest application requires awareness of SAN device characteristics.
- Consider it for SAN-aware applications that issue specialized SCSI commands or perform storage management operations.
- Consider RDM for shared-disk or guest-clustering designs when the application and vSphere support requirements explicitly permit it.
- Use a standard VMDK for ordinary application data when direct SAN access is not required.
RDM is not automatically faster or better than a VMDK. The compatibility mode, guest behavior, storage policy, backup method, mobility requirements, and application support matrix should determine the design.
Physical and Virtual Compatibility Modes
Compatibility mode controls how vSphere presents the mapped device and how much SCSI command handling is intercepted by virtualization.
| Characteristic | Physical compatibility mode | Virtual compatibility mode |
|---|---|---|
| SCSI command behavior | Provides the most direct handling of SCSI commands to the raw device, with limited virtualization interception. REPORT LUNS remains an exception to complete pass-through. | Makes the mapped device behave more like a virtual disk from the guest and vSphere perspective. |
| Typical workload fit | SAN-aware applications or workloads requiring direct physical-device behavior. | Workloads that need an RDM but do not require full physical-mode behavior. |
| VMware snapshot eligibility | Cannot be included in VMware virtual machine snapshots. | Can participate in VMware virtual machine snapshots. |
| SAN-aware application suitability | Often appropriate when the application requires specialized SCSI or SAN behavior, subject to support documentation. | Suitable only when the application supports the more virtualized device behavior. |
| Operational trade-offs | Requires backup and recovery methods that do not depend on VM snapshots for this disk. Mobility and protection workflows must be tested. | Provides better snapshot integration, but snapshot use still requires capacity, performance, retention, and recovery planning. |
Prerequisites and Planning
Complete the following checks before editing the VM:
| Check | Why it matters | How to verify |
|---|---|---|
| LUN is provisioned and visible to ESXi | The RDM wizard can select only devices discovered by the host. | Confirm the device, capacity, identifier, and path state after an ESXi storage rescan. |
| LUN is presented to all required hosts | The VM may migrate or restart on another host. | Verify SAN zoning, masking, host mapping, and device visibility on every applicable ESXi host. |
| Correct LUN identity and capacity are known | Prevents attaching or formatting the wrong device. | Record the unique device identifier, expected capacity, and storage-system ownership. |
| LUN is not an active VMFS datastore | Attaching a datastore device as an RDM can cause an incorrect or destructive configuration. | Confirm that the device is not being used as a VMFS datastore or by another workload. |
| Mapping-file datastore is selected | The RDM descriptor must be stored somewhere accessible to the VM. | Choose a suitable VMFS datastore with sufficient space and appropriate availability. |
| Compatibility mode is selected | Mode affects SCSI behavior, snapshots, backup, and mobility. | Match the mode to application and vSphere support requirements. |
| Guest operating system handling is planned | The guest must discover and prepare the disk correctly. | Plan rescanning, identity verification, initialization, partitioning, formatting, multipathing, and application configuration. |
| Backup and snapshot implications are accepted | Physical-mode RDMs cannot be included in VM snapshots. | Document disk-specific backup, restore, and disaster-recovery procedures. |
Also verify that the VM has enough virtual SCSI controller capacity. Select an unused controller and device node, such as an available controller/unit assignment, rather than changing an existing disk's address.
Add an RDM Disk in the vSphere Client
- Open the vSphere inventory and select the target virtual machine.
- Open Edit Settings or the VM's virtual hardware configuration.
- In the New device menu, select RDM Disk, then choose Add.
- From the discovered-device list, select the intended SAN LUN. Compare its identifier and capacity with your storage records.
- Select the VMFS datastore and folder location for the RDM mapping file.
- Expand the new hard disk settings and select the required compatibility mode: Physical or Virtual.
- Assign the disk to the appropriate virtual SCSI controller.
- Assign an unused virtual SCSI device node. The address is commonly displayed in a form such as
SCSI 1:0. - Review the device, datastore, mode, controller, and node settings.
- Save the virtual machine hardware changes.
Client labels can vary between vSphere releases, but the workflow remains the same: edit virtual hardware, add an RDM disk, select the discovered LUN, place the mapping file, choose compatibility mode, assign SCSI hardware, and save.
Example: SAN-Aware Database Workload
- Present the newly provisioned LUN to every ESXi host that can run the database VM.
- Rescan ESXi storage adapters and verify the device identifier, capacity, and healthy paths.
- Add the device as an RDM and store its mapping file on a VMFS datastore.
- Choose physical compatibility mode because the database application requires direct SAN device behavior.
- Assign an unused virtual SCSI controller slot and save the VM configuration.
- Verify the disk in the guest before initializing it for database use.
In this example, the mapping file resides on VMFS, but database data is written to the SAN LUN.
Example: Retain VM Snapshot Capability
- Add the RDM through Edit Settings.
- Choose virtual compatibility mode after confirming that the application does not require physical-mode behavior.
- Use snapshots only within an approved capacity, backup, and recovery design.
Compatibility mode is a functional design choice, not merely a selection of storage location.
Prepare the Disk in the Guest Operating System
- Rescan disks in the guest if the new device is not immediately visible.
- Confirm the disk's capacity, identifiers, pathing, online state, and health.
- Compare those properties with the planned SAN LUN and storage records.
- Initialize the disk only after confirming that it is new and intended for this guest.
- Create the required partition, file system, volume group, logical volume, or application-managed storage structure.
- Configure guest multipathing when the operating system and application require it, and verify that paths are healthy.
- Test application access and any required shared-storage or failover behavior.
Validate the Attachment
- In vSphere, confirm that the RDM disk is present in the VM hardware configuration.
- Confirm the selected compatibility mode, virtual SCSI controller, and device node.
- Confirm that the mapping file exists on the selected VMFS datastore.
- Confirm that the underlying device remains on the SAN and that its expected paths are available.
- In the guest, confirm disk visibility, capacity, identity, pathing, and status.
- Test the intended application access, including failover or shared-storage behavior where applicable.
- Document the LUN identifier, mapping-file datastore and path, virtual SCSI address, compatibility mode, and owning VM.
- Review snapshot, backup, restore, Storage vMotion, vMotion, and disaster-recovery behavior against the selected mode and the support matrix for your environment.
Troubleshooting
The LUN Does Not Appear in the RDM List
- Verify that the LUN is provisioned and presented to the ESXi host.
- Check SAN zoning, masking, and host mapping.
- Perform a storage-adapter rescan and verify the expected identifier, capacity, and path status.
- Confirm that the device is not already claimed as a VMFS datastore or used by another workload.
The Guest Does Not Detect the RDM
- Confirm that the VM hardware change was saved.
- Verify the RDM's virtual SCSI controller and device node.
- Rescan storage from the guest operating system.
- Check guest storage drivers, virtual controller support, and operating-system logs or device-management tools.
A VMware Snapshot Cannot Be Created
The RDM may use physical compatibility mode. Confirm the mode in the VM hardware settings. Use an application-appropriate backup method for physical-mode disks. Change to virtual mode only after validating application behavior and operational requirements.
The Wrong Disk Is About to Be Initialized
Stop before writing to the device. Disk number or ordering alone is not a safe identity. Match capacity and unique identifiers with the planned LUN, then confirm ownership and data status with storage administration records.
The VM Works on One Host but Not After a Host Change
The LUN may not be presented consistently to all potential hosts, or multipathing and SAN configuration may differ. Compare device visibility, zoning, masking, path health, and storage configuration across the affected hosts.
Remove an RDM Safely
- Follow the application-safe shutdown or disk-detachment procedure. For shared disks, coordinate with every participating guest and application owner.
- Confirm which VM hardware entry and mapping file represent the disk.
- Remove the RDM virtual hardware from the VM using the appropriate removal option.
- Do not delete or alter the underlying SAN LUN unless data retirement has been separately approved and verified.
- Update storage, VM, backup, and disaster-recovery documentation.
Removing the RDM mapping from a VM is not the same as deleting the SAN data. Virtual hardware removal can disconnect the VM while leaving the LUN and its contents intact. Treat destruction, reuse, or alteration of the LUN as a separate controlled storage operation.
Operational Checklist
- Identify the LUN by unique identifier and capacity.
- Present it consistently to every ESXi host that may run the VM.
- Rescan ESXi storage and verify paths.
- Confirm that the device is not a VMFS datastore or another workload's disk.
- Choose a VMFS datastore for the small RDM mapping file.
- Select physical or virtual compatibility mode according to application requirements.
- Assign an unused virtual SCSI controller and device node.
- Validate the disk in the guest before initialization or formatting.
- Document ownership, mapping location, mode, address, backup method, and recovery behavior.
For related virtual hardware procedures, see Add Virtual Hardware to a VM. For datastore context, see Browse VMFS Datastores, and for broader platform guidance, see VMware ESXi.