VMware ESXi and vSphere Cluster Management
VMware Raw Device Mapping (RDM): Concepts, Modes, Use Cases, and Limitations
Learn how VMware vSphere RDM connects VMs to SAN LUNs, compare physical and virtual compatibility modes, and plan deployment, troubleshooting, backup, and lifecycle management.
VMware Raw Device Mapping (RDM) connects a virtual machine directly to a raw block-storage device, usually a SAN LUN. Unlike a conventional virtual disk, the guest workload data is stored on the mapped LUN rather than inside a normal VMDK on a VMFS datastore.
RDM is a specialized storage design. Standard VMDKs are usually the preferred choice because they are simpler to manage and work with more vSphere features. Choose RDM when a documented application, clustering, or storage-integration requirement justifies direct LUN-oriented behavior.
What Is Raw Device Mapping?
An RDM is a VMware mapping mechanism that gives a VM access to a raw storage device. The raw device is commonly a Logical Unit Number (LUN), which is a block-storage device presented by a SAN to hosts.
The RDM is represented by a small mapping file stored on a VMFS datastore. The file has a .vmdk extension, but the extension can be misleading: an RDM mapping file is not a conventional virtual disk containing the guest's files and application data. It records the association between the VM and the underlying raw device.
The application and guest data reside directly on the mapped LUN. The VMFS datastore stores the mapping object and the VM configuration, while the SAN provides the storage capacity used by the guest workload.
How RDM Storage Access Works
The access path contains several cooperating components:
- The guest operating system issues storage requests to a virtual SCSI controller.
- The VM's virtual hardware refers to the RDM mapping file.
- The mapping file resides on a VMFS datastore and identifies the intended raw device.
- The ESXi host and its VMkernel storage stack process the request according to the selected RDM compatibility mode.
- ESXi uses its configured Fibre Channel or iSCSI paths to reach the physical SAN LUN.
- The guest's actual blocks are read from or written to the raw LUN, not to a normal data-bearing VMDK on VMFS.
The mapping file therefore acts as a VMFS-resident reference and proxy. Its small size does not represent the capacity of the workload disk. A large LUN can be mapped by a relatively small file.
Every ESXi host that might run the VM must be able to see and consistently access the mapped LUN. This requires correct SAN zoning or iSCSI network access, LUN masking, permissions, path configuration, and multipathing on all candidate hosts.
RDM Compatibility Modes
When an RDM is attached, the administrator selects either physical compatibility mode or virtual compatibility mode. The choice affects SCSI behavior and supported vSphere features.
| Characteristic | Physical compatibility mode | Virtual compatibility mode |
|---|---|---|
| Primary purpose | Near-direct access for SAN-aware or specialized workloads. | Mapped storage with behavior closer to a virtual disk. |
| SCSI command behavior | Provides the most direct SCSI command pass-through behavior; ESXi still handles limited commands. | ESXi applies more virtualization of the device behavior. |
| REPORT LUNs handling | REPORT LUNs is an exception to the physical-mode pass-through behavior. | Handled through the virtualized device presentation. |
| vSphere snapshots | Not supported for the physical-mode RDM. | Can participate in vSphere snapshots, subject to the overall VM and platform configuration. |
| Typical workload types | Applications requiring specific physical SAN characteristics or specialized SCSI semantics. | Workloads that need an RDM but also require selected virtual-disk features. |
| Management trade-offs | More restrictive and operationally complex; fewer virtualization features. | More compatible with common VM operations, but still has raw-LUN lifecycle and support considerations. |
| Vendor support validation | Essential before deployment, especially for clustering and SAN-aware applications. | Still required for snapshots, backup, migration, clustering, and other feature-sensitive designs. |
Physical Compatibility Mode
Physical mode is intended for workloads that need near-direct SCSI behavior or visibility into physical SAN device characteristics. ESXi passes most SCSI commands through to the device, while retaining limited control. The SCSI REPORT LUNs command is an important exception.
Physical-mode RDMs cannot participate in vSphere snapshots. Use an application-consistent backup or another supported protection method instead of assuming that a normal VM snapshot protects the mapped data.
Virtual Compatibility Mode
Virtual mode presents the mapped device with behavior more similar to a virtual disk. It supports selected virtualization features, including participation in vSphere snapshots. That does not automatically make every snapshot, backup, replication, or migration workflow safe for the application. Confirm the design with the current vSphere and application support matrices.
When Is RDM Appropriate?
RDM can be appropriate when a workload has a specific technical dependency on a raw LUN. Examples include:
- A SAN-aware application that must inspect or depend on physical SAN device behavior.
- A supported clustered configuration requiring shared-disk access between VMs.
- A workload requiring direct LUN-oriented storage behavior or specialized SCSI semantics.
- A vendor-certified design that explicitly requires physical or virtual compatibility mode.
Microsoft Cluster Service (MSCS) is older Microsoft clustering terminology. Current Windows Server Failover Clustering designs may have their own supported shared-disk, controller, reservation, and fencing requirements. Do not infer support merely because two VMs can be given access to the same LUN.
Shared-LUN workloads require cluster-aware disk ownership and fencing. The cluster must control which node owns a disk, and unintended access by another VM, host, or application can corrupt data.
RDM Versus a Standard VMDK
| Area | RDM | Standard VMDK |
|---|---|---|
| Where guest data resides | On a separately provisioned raw SAN LUN. | Inside a virtual disk file stored on a datastore. |
| Role of VMFS | Stores the small mapping file and VM files; it does not normally contain the mapped guest data. | Stores the virtual disk file and usually the guest data. |
| Use of raw SAN LUN | Required as the backing device. | Not directly exposed to the guest; the datastore consumes the storage. |
| Typical use cases | Specific clustering, SAN-awareness, or SCSI-semantics requirements. | General-purpose operating systems and applications. |
| Snapshot behavior | Virtual mode can participate; physical mode cannot. | Commonly integrates with vSphere snapshot workflows, subject to application-consistency concerns. |
| Backup and recovery | Requires validation that the backup product protects the mapping and the raw-LUN data correctly. | Usually fits standard VM image and virtual-disk backup workflows more directly. |
| Portability and migration | Depends on raw-device visibility and product compatibility at the destination. | Usually simpler because the virtual disk travels through datastore and VM management workflows. |
| Lifecycle management | Mapping-file management and SAN-LUN management are separate tasks. | Virtual disk and datastore lifecycle are more closely integrated. |
| Operational complexity | Higher: device identity, host presentation, path health, ownership, and support constraints must be managed. | Lower for ordinary workloads. |
| Default choice without a special requirement | Usually not the default. | Typically preferred. |
Planning and Prerequisites
- Shared storage design: Use a supported block-storage design such as Fibre Channel or iSCSI SAN storage presented to ESXi.
- VMFS location: Provide a VMFS datastore with enough space for the mapping file and associated VM configuration.
- SAN presentation: Verify zoning, iSCSI network access, LUN masking, host groups, permissions, and storage connectivity.
- Host visibility: Confirm that every ESXi host that may run the VM can see the same LUN with consistent identifiers and capacity.
- Multipathing: Check that multiple intended paths are present and healthy, with the appropriate path-selection policy.
- LUN ownership: Ensure the chosen LUN is not already being used as a VMFS datastore or claimed by a conflicting workload.
- Stable identification: Record canonical device identifiers, capacity, storage-system identity, owner, and intended VM or cluster.
- Application support: Verify the vendor's requirements for RDM mode, clustering, snapshots, backup, replication, and mobility.
- Change control: Use least-privilege permissions, a maintenance window, documented approvals, and a tested recovery plan.
RDM Creation and Attachment Workflow
- Provision a dedicated LUN on the SAN and document its identifier, size, owner, and intended consumer.
- Present the LUN to the required ESXi hosts through correct zoning, masking, or iSCSI access controls.
- Rescan the ESXi storage adapters after the SAN presentation change.
- Verify the device identifier, capacity, path status, and multipathing health on every relevant host.
- Confirm that the LUN is not a VMFS datastore and is not in conflicting use.
- In the vSphere Client, edit the VM hardware and add a hard disk using the available raw-device mapping option.
- Select the intended raw LUN using verified identifiers and capacity, rather than relying only on a friendly name.
- Choose physical or virtual compatibility mode according to the workload's supported requirements.
- Select a VMFS datastore and folder where vSphere will store the RDM mapping file.
- Attach the RDM to the planned virtual SCSI controller and SCSI node. Follow any controller or sharing requirements specified by the cluster or application vendor.
- In the guest operating system, rescan storage and confirm the expected disk identity and size before initializing, formatting, mounting, or adding the disk to a cluster.
- Validate the final mapping, compatibility mode, guest visibility, application configuration, and path health.
Deployment Checklist
| Checkpoint | Why it matters | Validation method |
|---|---|---|
| Dedicated LUN provisioned | Prevents accidental reuse or data collision. | Compare the storage record with the approved request and ownership documentation. |
| Correct SAN presentation | Only intended ESXi hosts should receive access. | Review zoning, masking, host groups, or iSCSI access controls. |
| All potential ESXi hosts can see the LUN | Supports VM mobility and failover. | Compare canonical identifiers and capacities on every candidate host. |
| Multipathing is healthy | Reduces path-related outages and supports the intended availability design. | Inspect path count, state, and policy in vSphere storage views. |
| LUN is not in conflicting use | Prevents mapping a datastore or another workload accidentally. | Check VMFS inventory, device claims, and storage ownership records. |
| VMFS datastore exists for mapping file | The mapping object needs a VMFS location. | Confirm datastore capacity and accessibility. |
| Correct mode selected | Mode affects SCSI behavior and snapshots. | Compare the selected mode with vendor and application requirements. |
| Guest operating system detects the disk | Confirms the complete path from VM hardware to guest. | Rescan the guest and verify identity and capacity. |
| Application or cluster support confirmed | Technical possibility does not equal supported operation. | Review current VMware, operating-system, and application support guidance. |
| Backup and recovery procedure tested | RDM data may not follow ordinary VM backup assumptions. | Perform a controlled restore or recovery test. |
Feature Limitations and Operational Considerations
Snapshots
Physical-mode RDMs do not support vSphere snapshots. Virtual-mode RDMs can participate in snapshots, but snapshot support must be considered together with application consistency, guest quiescing, backup tooling, and storage behavior.
Backup and Recovery
The mapping file and the raw LUN are separate protection objects. A backup product may protect the VM configuration and mapping file without automatically protecting the data on the LUN, or it may require a specific RDM-aware workflow. Confirm what is backed up, how application consistency is achieved, and how the LUN is restored or reattached.
Migration, Cloning, Replication, and Disaster Recovery
Mobility and protection operations can depend on compatibility mode, vSphere version, storage platform, backup or replication product, and destination-LUN design. Validate vMotion, storage migration, cloning, replication, and disaster-recovery procedures against the current product support matrices before relying on them.
Separate Lifecycles
Managing the mapping file is not the same as managing the raw LUN. Deleting a mapping file does not automatically delete or sanitize the data on the LUN. Conversely, removing SAN presentation while a VM still uses the mapping can cause guest I/O failure.
Accidental Selection and Reassignment
RDM operations carry an increased risk of selecting, deleting, or reassiging the wrong LUN. Use canonical identifiers, capacity, storage-system records, ownership labels, and peer review. Never present a production LUN to an unintended host or VM.
Administration, Monitoring, and Lifecycle
Maintain an inventory of every RDM-backed VM. Record the VM, mapping-file path, compatibility mode, raw-device identifier, LUN capacity, SAN array, owning application, participating ESXi hosts, and backup method.
Monitor the SAN paths and device availability from ESXi, the guest disk state from the operating system, and capacity from the storage system. For shared disks, also monitor cluster ownership, reservations, fencing, and failover events.
Use this safe removal sequence:
- Confirm that no guest, application, or cluster node is using the disk.
- Stop or remove the application and cluster configuration according to its supported procedure.
- Remove the virtual disk attachment or mapping file deliberately, recording the action and retaining the mapping if policy requires it.
- Inspect the actual SAN LUN and apply data-retention or sanitization policy.
- Only after the data decision is complete, remove SAN presentation and deprovision the LUN.
Removing the mapping file alone does not prove that the raw-LUN data has been erased. Treat the mapping object and the underlying device as separate lifecycle items.
Security and Change Control
- Use least-privilege permissions for VM hardware edits, datastore access, SAN provisioning, and host storage changes.
- Document LUN identifiers, ownership, intended consumers, cluster membership, and access boundaries.
- Use maintenance windows and validated backups before mode changes, storage reconfiguration, or cluster changes.
- Require review before presenting any production LUN to an additional ESXi host or VM.
- Keep SAN-side changes and vSphere changes synchronized so that the mapping never points to an ambiguous or reassigned device.
Common RDM Issues and Likely Causes
| Symptom | Likely cause | Investigation | Corrective action |
|---|---|---|---|
| Raw device unavailable during attachment | The LUN is not presented, storage was not rescanned, access controls are wrong, or the device is already claimed. | Check SAN presentation, ESXi connectivity, device visibility, identifiers, and current claims. | Correct zoning, masking, iSCSI access, or host permissions; rescan storage; confirm the LUN is dedicated and appropriate. |
| Mapped disk missing in the guest | Incorrect VM attachment, missing guest rescan, offline or uninitialized disk, or guest-level multipathing state. | Inspect the VM SCSI controller and node, rescan the guest, and check guest disk management. | Correct the attachment, rescan, and configure the disk according to guest and application requirements. |
| VM cannot run on another host | The destination host cannot see the LUN or has inconsistent SAN or multipathing configuration. | Compare device visibility, identifiers, paths, and policies across candidate hosts. | Correct zoning, masking, iSCSI access, host groups, or path configuration before enabling mobility. |
| Snapshot operation is unavailable | An attached RDM uses physical compatibility mode, or another VM condition prevents snapshots. | Check every attached RDM and the VM snapshot compatibility state. | Use an application-appropriate backup method, or evaluate virtual mode only if the workload supports it. |
| Cluster disk validation fails | Unsupported shared-disk design, inconsistent presentation, incorrect controller settings, missing fencing, or unintended access. | Review current VMware, operating-system, and application guidance; inspect ownership and host visibility. | Correct the supported cluster configuration, enforce dedicated access, and test controlled failover. |
| Unexpected disk or LUN ownership conflict | The LUN was presented to an unintended host or VM, or records identify the wrong device. | Compare canonical identifiers, storage records, VM mappings, and SAN access lists. | Remove unintended access under change control and verify the correct owner before proceeding. |
Practical Examples
SAN-Aware Database or Enterprise Application
An application vendor requires storage behavior associated with a directly mapped SAN LUN. The administrator provisions a dedicated LUN, presents it to all required ESXi hosts, verifies paths, and attaches a physical-mode RDM only after confirming product support. Because physical mode does not support vSphere snapshots, the protection design uses an approved application-consistent backup method.
Windows Shared-Disk Cluster
Two Windows VMs require a shared data disk for a supported cluster design. A dedicated LUN is presented consistently to the participating hosts and attached according to the supported controller and SCSI configuration. Cluster ownership and fencing prevent both nodes from writing to the disk inappropriately.
Snapshot-Capable Mapped Disk
A workload needs a mapped device and a supported VM-level snapshot process. The administrator evaluates virtual compatibility mode, then confirms snapshot consistency, backup behavior, and application support before using the design.
Choosing a VMDK Instead
A general-purpose application has no direct SAN-device requirement and no shared raw disk. A standard VMDK on VMFS is selected because it reduces complexity and fits common virtual-disk backup, migration, and lifecycle workflows.
Safe Decommissioning
Before retiring an RDM-backed application, the administrator verifies that the guest and cluster no longer use the disk, removes the VM mapping deliberately, applies the organization's retention or sanitization policy to the LUN, and only then removes SAN presentation.
Exam-Relevant Notes
- An RDM mapping file uses the
.vmdkextension but is not a conventional data-containing VMDK. - The mapping file is stored on VMFS; guest workload data is stored on the raw LUN.
- Physical compatibility mode provides the most direct SCSI behavior and does not support vSphere snapshots.
- Virtual compatibility mode behaves more like a virtual disk and can participate in vSphere snapshots.
REPORT LUNsis an exception to physical-mode SCSI command pass-through.- All ESXi hosts that may run the VM must have consistent access to the mapped LUN.
- RDM is a specialized choice for identified technical requirements, not a general replacement for VMDKs.
- Deleting an RDM mapping file is not the same as deleting the data on the raw LUN.
For a concise reference to this topic, see Raw Device Mapping (RDM).