VMware ESXi and vSphere Cluster Management

Raw Device Mapping (RDM) in VMware ESXi

Learn how VMware Raw Device Mapping connects a virtual machine to a SAN LUN, how physical and virtual compatibility modes differ, and how to plan RDM lifecycle, clustering, snapshots, and backups.

Raw Device Mapping (RDM) is a VMware mechanism that gives a virtual machine access to a raw SAN storage device through a small mapping file. The mapping file is stored on a VMFS datastore, while the guest operating system and applications read and write data on the mapped SAN LUN.

This design is useful when an application, cluster, or storage workflow requires direct interaction with a SAN-presented device. For many general-purpose workloads, however, a conventional VMDK is simpler to administer and usually provides better portability.

What Is Raw Device Mapping?

An RDM mapping file is a small metadata file with a .vmdk filename. It identifies a raw storage device and directs the virtual machine's disk I/O to that device. Unlike a normal VMDK, the RDM mapping file does not contain the guest's filesystem, database, or application data.

Mapping file: Stored on a VMFS datastore and used by vSphere to describe the raw-device connection.
Raw device: A SAN-presented LUN containing the guest data.
Virtual disk device: The disk that the guest sees through the VM's virtual SCSI controller.

With a normal VMDK, the virtual disk data is stored in a file on a datastore. With an RDM, the file on the datastore is primarily a pointer and metadata container; the data resides on the LUN.

How RDM Access Works

The access path includes the virtual machine, its virtual SCSI controller, the RDM mapping file, the VMFS datastore that holds that file, the ESXi host, and the SAN LUN.

The storage administrator presents a LUN from the SAN to the required ESXi hosts.
Each ESXi host detects the LUN through its storage adapters and multipathing configuration.
The administrator creates or attaches an RDM to the virtual machine and stores the mapping file on a VMFS datastore.
vSphere presents the RDM as a disk connected to a virtual SCSI controller.
ESXi redirects the disk's I/O to the underlying raw LUN, subject to the selected compatibility mode and VMware controls.
The guest operating system discovers the disk and uses its partitions, filesystem, or application-specific storage configuration.

The mapping file and the LUN are separate resources. The mapping file must be accessible through a VMFS datastore, and the target LUN must be visible to every ESXi host that may run the VM. A VM can fail after migration or restart if the destination host cannot access either resource.

RDM components and responsibilities

Virtual machine: Consumes the mapped disk as virtual hardware and runs the guest workload.

Virtual SCSI controller: Connects the virtual disk device to the guest and must be configured appropriately for the workload.

RDM mapping file: Small .vmdk-format metadata file that identifies and redirects access to the LUN.

VMFS datastore: Stores the mapping file and must be accessible to the relevant ESXi hosts.

Raw LUN: SAN logical storage device containing the guest data.

ESXi hosts: Provide storage access and must have consistent LUN visibility, identifiers, paths, and permissions.

SAN fabric and array: Provide zoning, masking, presentation, multipathing, and the underlying block storage.

RDM Compatibility Modes

When an RDM is created, choose one of two compatibility modes: physical compatibility mode or virtual compatibility mode. The choice affects SCSI behavior, snapshots, workload suitability, and operational procedures.

Physical compatibility mode

Physical mode provides the closest available SCSI command pass-through behavior between the guest workload and the mapped device. ESXi still reserves or filters certain commands. For example, REPORT LUNs is not passed through by physical-mode RDM behavior.

This mode is intended for workloads that need awareness of, or specialized interaction with, the physical SAN device. Examples include some SAN-aware applications, storage appliances, and validated legacy shared-disk clustering designs.

A physical-mode RDM cannot be included in a standard vSphere snapshot. Consequently, VM snapshot creation must not be treated as a backup, rollback, or change-management mechanism for that disk. Use application-aware, guest-based, or array-integrated protection that explicitly supports the workload and raw LUN.

Virtual compatibility mode

Virtual mode presents the raw LUN with behavior more similar to a standard virtual disk. VMware applies more virtualization behavior to the device, which can improve compatibility with vSphere features.

A virtual-mode RDM can participate in vSphere snapshots. Snapshot support does not make a snapshot a complete backup: it may not provide application consistency, long-term retention, protection from storage failure, or a tested recovery process. Coordinate snapshots with application quiescing and backup requirements.

SCSI command behavior: Physical mode permits near-direct SCSI interaction, except for commands ESXi reserves or filters, including REPORT LUNs. Virtual mode applies more virtual-disk-like behavior.

SAN-aware workloads: Physical mode is generally more suitable when the application requires special physical-device interaction. Virtual mode is suitable only when the application and vendor support its virtualization behavior.

vSphere snapshot inclusion: Physical-mode RDM disks are not included in standard vSphere snapshots. Virtual-mode RDM disks can participate in vSphere snapshots.

Typical use cases: Physical mode is associated with SAN-aware applications and certain validated legacy cluster designs. Virtual mode may suit raw-backed test or application environments that require snapshot compatibility.

Operational limitations: Physical mode reduces snapshot-based workflows and requires carefully planned backup and recovery. Virtual mode has more vSphere-like behavior but remains dependent on SAN access and application support.

Backup and recovery: Neither mode removes the need for application-consistent backups, documented dependencies, and tested restoration procedures.

RDM Compared with a Standard VMDK

Location of guest data: RDM data resides on the mapped SAN LUN; a standard VMDK stores data in a virtual disk file on a datastore.

Raw SAN LUN access: RDM requires a SAN-presented LUN and compatible host access. A standard VMDK does not normally require direct guest access to a LUN.

Snapshot behavior: RDM behavior depends on compatibility mode. Physical mode is excluded from standard vSphere snapshots, while virtual mode can participate. Standard VMDKs generally integrate more directly with vSphere snapshot workflows.

Administration complexity: RDM adds LUN presentation, identifiers, multipathing, mapping-file, and cross-team dependencies. A standard VMDK is usually simpler.

Portability and lifecycle management: RDM mobility depends on the destination host seeing the same LUN. VMDKs are generally easier to copy, move, back up, and manage as VM files.

Typical workload fit: RDM can fit SAN-aware or validated shared-disk workloads. A standard VMDK is generally preferable for ordinary operating systems, application servers, and test systems without a raw-device requirement.

When Should You Use an RDM?

SAN-aware applications: Use an RDM when a vendor-supported application needs to inspect LUN characteristics or perform specialized storage operations.
Legacy shared-disk clustering: Microsoft Cluster Service (MSCS) and other legacy clustering designs may require shared storage. Validate the exact guest OS, vSphere release, virtual hardware, controller, disk-sharing, and storage configuration.
Snapshot-dependent raw storage: A test workload that needs a raw-backed disk and short-lived vSphere rollback may evaluate virtual compatibility mode, subject to application and storage support.
Ordinary workloads: Select a conventional VMDK when there is no direct SAN requirement and the priorities are simple backups, portability, snapshots, and routine VM lifecycle operations.

Decision framework

Confirm that the application vendor requires or supports RDM rather than merely preferring it.
Determine whether the workload needs physical SCSI interaction or can use virtualized behavior.
Identify whether vSphere snapshots are required and whether they are appropriate for the application.
Check cluster requirements, including shared-disk access, reservation behavior, disk ownership, controller settings, and failover.
Review backup tooling for raw LUN support and application consistency.
Evaluate VM mobility, portability, maintenance, and disaster-recovery requirements.
Confirm the design against the support matrices for the vSphere release, guest operating system, storage vendor, and application.

Storage and Operational Constraints

RDM requires compatible SAN storage and deliberate LUN presentation. Use unique and traceable LUN identification, consistent zoning or masking, and healthy multipathing. Do not grant a host access to a LUN unless that access is intentional and documented.

Every host that may run the VM should see the intended LUN with the expected identifier.
Every such host should access the VMFS datastore containing the mapping file.
Multipathing policies and path health should be consistent with the storage design.
Storage changes should be coordinated among virtualization, SAN, backup, and application teams.
An RDM does not bypass guest filesystem rules, application write ordering, permissions, corruption risks, or accidental formatting.

Feature availability and recommended designs vary by vSphere release, guest operating system, storage vendor, and application support matrix. Treat vendor documentation and validated design guidance as authoritative for production deployments.

RDM Lifecycle and Administration

High-level implementation process

Provision a dedicated SAN LUN and document its array identifier, size, purpose, and owning application.
Present the LUN to the appropriate ESXi hosts through approved zoning, masking, or access-control procedures.
Rescan the ESXi storage adapters and verify the device identifier, capacity, paths, and multipathing health.
In the vSphere management interface, add an existing raw storage device to the VM and select physical or virtual compatibility mode.
Place the resulting mapping file on an accessible VMFS datastore.
Attach the mapping through the required virtual SCSI controller and device configuration.
In the guest, identify the disk carefully before initializing, partitioning, formatting, mounting, or assigning it.
For clustered systems, configure ownership, reservations, sharing, and failover according to the cluster product's requirements.
Validate application I/O, host mobility or failover where applicable, backup behavior, and recovery procedures.

For related vSphere storage administration, see Add Raw LUN, Add Virtual Hardware to a VM, and Datastore in Virtual SAN.

Safe detachment and removal

Deleting the RDM mapping file and deleting, formatting, or unpresenting the underlying LUN are separate operations with very different consequences. Removing the mapping file does not automatically mean the LUN's data has been erased, while deleting or reusing the LUN can destroy or expose data.

Confirm the guest no longer uses the disk, including filesystems, databases, cluster resources, and scheduled jobs.
Quiesce or stop the application and offline or unmount the disk as required by the guest operating system.
Record the VM, mapping-file path, compatibility mode, LUN identifier, datastore, application owner, and retention decision.
Detach the disk from the VM using the approved vSphere procedure.
Only after ownership and data-retention decisions are confirmed, remove the mapping file or decommission the LUN through separate approved procedures.

Troubleshooting RDM Problems

The desired LUN is not available when adding an RDM

Possible causes include missing array presentation, an incomplete storage rescan, blocked zoning or masking, an incorrect host access policy, or a device already in use.

Confirm array-side host presentation.
Rescan the ESXi storage adapters.
Check device visibility, identifiers, capacity, and path status.
Verify that all required hosts see the same intended LUN.

A snapshot does not include the mapped disk

First confirm the compatibility mode. A physical-mode RDM cannot be captured as part of a standard vSphere snapshot. Use application-aware or array-integrated backup and recovery when appropriate.

The VM works on one host but fails after migration

The destination host may lack access to the raw LUN, the mapping-file datastore, or the required storage paths. Compare datastore access, LUN visibility, zoning, masking, multipathing, and path health across the source and destination hosts before migration.

The guest sees an unexpected disk or missing data

Stop write activity before investigating. Compare guest disk identifiers with ESXi device identifiers and array records. Check for incorrect LUN selection, changed partitions or signatures, reformatting, reassignment, or other recent storage changes.

A clustered application reports shared-disk or failover errors

Validate the complete design against VMware, operating system, application, and storage vendor guidance. Confirm identical intended LUN visibility, correct ownership behavior, virtual SCSI controller settings, disk-sharing requirements, and cluster failover configuration.

Exam-Relevant Notes

An RDM mapping file has a .vmdk extension but is metadata; guest data resides on the mapped LUN.
The mapping file is stored on VMFS, while the raw device is a SAN-presented LUN.
All possible ESXi hosts need access to both the mapping-file datastore and the mapped LUN.
Physical compatibility mode provides near-direct SCSI behavior but filters reserved commands, including REPORT LUNs.
Physical-mode RDMs are not included in standard vSphere snapshots.
Virtual-mode RDMs can participate in vSphere snapshots and behave more like virtual disks.
RDM is not automatically better than VMDK; use it when application, cluster, or storage requirements justify the added complexity.
Always separate removal of the mapping file from deletion or reuse of the underlying LUN.