VMware ESXi and vSphere Cluster Management
Add a Raw LUN to a VMware ESXi Virtual Machine with Raw Device Mapping
Learn how to attach an existing SAN LUN to a VMware vSphere VM with an RDM, choose physical or virtual compatibility mode, and validate the guest disk safely.
What a Raw Device Mapping is
A Logical Unit Number (LUN) is a storage unit exposed by a SAN to a host. A Raw Device Mapping (RDM) is a vSphere mapping that connects a virtual machine disk device to an underlying SAN LUN.
An RDM does not place the application data inside an ordinary virtual disk file. Instead, vSphere stores a small mapping file on a VMFS datastore. This file normally uses the .vmdk filename extension and contains mapping metadata that identifies the raw device. The actual application data remains on the presented SAN LUN, and data I/O is directed to that LUN rather than stored inside a standard VMDK.
| Component | Purpose |
|---|---|
| Raw SAN LUN | Stores the guest or application data. |
| RDM mapping file | A small VMFS-hosted pointer file containing mapping information. |
| Virtual SCSI controller | Provides the virtual hardware connection between the VM and the RDM disk. |
When an RDM is appropriate
Use an RDM when a SAN-aware application needs visibility into storage-device characteristics or requires storage behavior that is not adequately represented by an ordinary virtual disk. Examples can include certain enterprise applications, clustered designs, and workloads that need direct interaction with SAN storage behavior.
A SAN-aware application is software that requires or benefits from knowledge of SAN storage characteristics. Before selecting an RDM, confirm that the application vendor and storage design support it.
An ordinary VMDK is usually the simpler choice when the workload only needs block storage. Standard virtual disks generally provide easier provisioning, cloning, snapshots, migration, backup integration, and lifecycle management. Avoid an RDM when a VMDK meets the workload and operational requirements.
Prerequisites and planning
- Present the LUN correctly. Create or identify the LUN on the SAN and present it to every ESXi host that may run the VM. Confirm SAN zoning, masking, and host access.
- Verify discovery and paths. Confirm that each relevant ESXi host has discovered the device and that its expected storage paths and multipathing configuration are healthy. Rescan ESXi storage when necessary.
- Confirm ownership. Make sure the intended LUN is not already being used by an incompatible host, VM, datastore, filesystem, or application. Do not assume that a familiar capacity alone identifies the correct LUN.
- Plan virtual SCSI placement. Confirm that the VM has an available SCSI controller and unit-number position. Plan an additional virtual SCSI controller if the existing controller has no suitable capacity or if the workload requires separate controller placement.
- Choose the mapping-file datastore. Identify a VMFS datastore that is visible to all candidate ESXi hosts and has room for the RDM mapping file.
- Check permissions. Ensure that the administrator can edit VM hardware and access the required VMFS datastore and storage inventory.
- Plan guest configuration. Decide how the guest will detect, initialize, partition, format, and assign the disk. Do not initialize or format a LUN that contains required existing data.
- Review operations. Before choosing a compatibility mode, review backup, snapshot, clustering, migration, restart, and disaster-recovery requirements.
RDM deployment checklist
| Checkpoint | What to verify | Why it matters |
|---|---|---|
| LUN presentation to ESXi hosts | The LUN is presented and discovered by every host that may run the VM; paths are healthy. | Without consistent visibility, the VM may fail to move, power on, or access its disk on another host. |
| LUN uniqueness and ownership | The LUN is the intended device and is not in unsafe use elsewhere. | Attaching the wrong or concurrently used LUN can expose data or corrupt a filesystem. |
| VMFS datastore for mapping file | A shared, accessible VMFS datastore has been selected. | The mapping file must be available along with the VM configuration. |
| SCSI controller capacity | An appropriate controller and unit number are available. | The RDM needs a valid virtual hardware address. |
| Compatibility-mode decision | Application behavior and snapshot requirements have been reviewed. | Physical and virtual modes have different capabilities and limitations. |
| Guest OS detection | The guest can use the selected virtual controller and can identify the new disk. | Guest drivers and storage rescans may be required. |
| Backup and recovery plan | Protection covers both the mapping relationship and the data-bearing LUN. | The pointer file alone is not a backup of the raw device data. |
Choose an RDM compatibility mode
Compatibility mode controls how the RDM exposes the raw LUN to the guest and which vSphere features can operate on the disk.
Physical compatibility mode
Physical compatibility mode passes nearly all SCSI commands through to the raw device. REPORT LUNs, a SCSI command used to report logical units, is treated as an exception.
Physical mode is commonly selected for SAN-aware workloads that need direct physical-device behavior. However, a physical-mode RDM cannot be included in vSphere snapshots. Use application-consistent or storage-based protection methods when snapshots are not available for the disk.
Virtual compatibility mode
Virtual compatibility mode presents more virtual-disk-like behavior to the guest while still mapping the virtual disk to a raw SAN LUN. Virtual-mode RDMs can participate in vSphere snapshots.
Choose virtual mode when the workload can use virtualized disk semantics and VM-level snapshot inclusion is an operational requirement. Confirm that the application does not require the lower-level SCSI behavior available in physical mode.
| Characteristic | Physical compatibility mode | Virtual compatibility mode | Operational consequence |
|---|---|---|---|
| SCSI command behavior | Passes nearly all SCSI commands to the raw device, except REPORT LUNs. | Provides more virtual-disk-like behavior. | Physical mode exposes more direct device behavior; virtual mode offers greater virtualization compatibility. |
| SAN-aware application suitability | Often appropriate when direct physical-device behavior is required. | Appropriate when the application works with virtualized disk semantics. | Base the choice on documented application requirements, not preference alone. |
| vSphere snapshot support | The RDM cannot be included in vSphere snapshots. | The RDM can participate in vSphere snapshots. | Snapshot-based workflows must account for the selected mode. |
| Guest disk behavior | More direct access to device behavior. | More closely resembles a virtual disk. | Guest and application expectations may differ by mode. |
| Typical selection criteria | Choose when direct SAN or SCSI behavior is required and snapshots are not required for the disk. | Choose when snapshot participation is required and the workload accepts virtualized behavior. | Validate backup, clustering, migration, and recovery consequences before deployment. |
Add the RDM disk in the vSphere client
- Select the target virtual machine in the vSphere inventory.
- Open the virtual machine hardware editing workflow, such as the VM hardware settings or edit-settings view.
- Choose to add a new device and select an RDM disk from the device-selection menu.
- Select the intended raw LUN from the list of eligible discovered LUNs. Compare its identifier and capacity with the storage plan.
- Choose the VMFS datastore location for the RDM mapping file.
- Expand or review the new disk's advanced settings.
- Select either physical or virtual compatibility mode according to the application and snapshot decision.
- Review the virtual SCSI controller and unit-number assignment. Confirm that the disk is not assigned to an unintended controller or conflicting unit number.
- Save or apply the hardware configuration and wait for the vSphere task to complete successfully.
vSphere client workflow:
1. Select the VM.
2. Edit virtual hardware.
3. Add device: RDM disk.
4. Select the discovered SAN LUN.
5. Select the VMFS datastore for the mapping file.
6. Set compatibility mode.
7. Confirm SCSI controller and unit number.
8. Apply the configuration.Validate the attachment
- In the VM hardware configuration, verify that the RDM device appears with the expected capacity, controller, unit number, and mapping information.
- Power on or otherwise access the guest according to the change plan, then verify that the guest operating system detects an additional disk.
- If the disk is not immediately visible, rescan or refresh storage devices in the guest operating system.
- Compare the guest disk's capacity and identity with the storage team's LUN assignment. Use stable identifiers where available rather than relying only on disk numbering.
- Initialize, partition, and format the disk only when that is part of the deployment plan and there is no existing required data on the LUN.
- Mount or assign the filesystem as appropriate and validate application access.
- For a SAN-aware application, verify the expected storage-device behavior and confirm that monitoring, backup, and recovery procedures recognize the RDM correctly.
Operational constraints and safety
- Do not attach one LUN to multiple systems unless the operating system, filesystem, and application are explicitly designed for shared-disk access.
- Uncoordinated access by multiple hosts or VMs can cause filesystem corruption, metadata conflicts, and data loss. A shared-disk cluster must use a supported coordination design.
- Distinguish the RDM pointer file from the data-bearing raw LUN in backup and recovery documentation.
- Account for snapshot differences: physical-mode RDMs cannot be included in vSphere snapshots, while virtual-mode RDMs can participate.
- For VM mobility, ensure consistent LUN visibility, VMFS datastore access, multipathing, and device configuration on all candidate ESXi hosts.
- Document the LUN identifier, capacity, mapping-file location, compatibility mode, SCSI controller and unit number, guest ownership, application owner, and protection method.
Troubleshooting
The desired LUN does not appear during RDM selection
Likely causes include missing SAN presentation, incomplete ESXi discovery, an ESXi storage rescan that has not been performed, existing device ownership or formatting, or insufficient storage and VM configuration permissions.
Verify SAN zoning and masking, rescan ESXi storage, inspect device ownership and formatting, confirm that the LUN is not already assigned to an incompatible consumer, and check permissions.
The VM cannot be moved or restarted on another host
The target host may not see the raw LUN, may not access the VMFS datastore containing the mapping file, or may have different multipathing or SAN presentation.
Make storage presentation, path configuration, device discovery, and VMFS access consistent across all hosts expected to run the VM.
The guest OS does not show the new disk
Confirm that the VM hardware change completed. Then rescan guest storage and verify the disk's SCSI controller and unit number. Also confirm that the guest has the required driver and supports the selected virtual SCSI controller.
A snapshot cannot include the RDM disk
This is expected when the RDM uses physical compatibility mode. Use an application- or storage-based protection method, or evaluate virtual compatibility mode if it satisfies the workload's requirements.
The guest sees an unexpected disk or existing filesystem
The wrong LUN may have been selected, or the LUN may contain preexisting data. Stop before formatting or writing data, verify identifiers and capacity with the storage administrator, and detach the incorrect mapping if necessary.
Data corruption occurs after sharing the raw LUN
Multiple systems may have accessed the same filesystem without cluster-aware coordination, or the LUN may have been mistakenly attached to more than one VM. Remove unsafe concurrent access and use only a supported shared-storage clustering design.
Exam-relevant notes
- An RDM mapping file is a small VMFS-hosted pointer; it is not the data-bearing disk.
- Physical compatibility mode passes nearly all SCSI commands through, with REPORT LUNs as an exception.
- Physical-mode RDMs cannot participate in vSphere snapshots.
- Virtual-mode RDMs provide more virtual-disk-like behavior and can participate in vSphere snapshots.
- Every ESXi host that may run the VM needs access to both the mapping-file datastore and the raw LUN.
- Never initialize or format an attached LUN until its identity and intended ownership are confirmed.
Summary
Adding an RDM connects a VM's virtual SCSI disk device to an existing SAN LUN while keeping a small mapping file on VMFS. The key decisions are whether the workload truly needs RDM behavior, whether the LUN is safely presented and exclusively owned, and whether physical or virtual compatibility mode fits the application's SCSI, snapshot, mobility, and recovery requirements. Validate the disk identity in both vSphere and the guest before allowing the application to use it.