How to create vSphere VMs with RDM disks
Raw Device Mapping (RDM) is one of those features that refuses to die. It is no longer the default answer for most workloads, but there are still cases where nothing else fits quite right. If you need a VM to talk to a LUN more directly than a regular VMDK allows, RDM is still on the table.
This article walks through what RDM actually does, when it still makes sense, and how to configure it without surprises.
What RDM actually is
RDM is a pointer. Not a special disk format. Not a faster VMDK.
When you create an RDM, vSphere places a small mapping file on a datastore. That file redirects the VM’s virtual SCSI device to a real LUN presented from your storage array. The data does not live in VMFS. VMFS just holds the reference.
From the guest OS perspective, it is talking to a raw disk. From vSphere’s perspective, it is brokering access.
Compatibility modes
RDM comes in two flavors, and choosing the wrong one is where most mistakes start.
Virtual Compatibility Mode (vRDM) The LUN is still wrapped enough for vSphere to use features like snapshots and Storage vMotion. You get some VMFS mediation, but the VM still accesses the raw device underneath.
Physical Compatibility Mode (pRDM) The VM gets near-direct access to the LUN and can pass SCSI commands straight through. That is why clustering software and certain legacy apps require it. The tradeoff is losing snapshot support and some mobility features.
If you do not explicitly need SCSI pass-through semantics, use vRDM. pRDM should be a deliberate decision, not the default.
When RDM still makes sense
Years ago, RDM was the answer for performance, size limits, and array integration. Most of those gaps have closed. Today, typical reasons to use it look more like this:
- Guest clustering that needs shared disks visible at the SCSI level
- Applications that insist on raw device semantics
- Direct use of array-native snapshots or replication workflows
- Very specific vendor requirements that have not caught up with modern VM storage
If none of those apply, a standard VMDK is usually simpler and easier to live with.
How RDM works behind the scenes
The mapping file stores identifiers for the LUN and tells the VMkernel where to send I/O. Reads and writes bypass VMFS and go straight to the device.
This means:
- Storage behavior is dictated by the array, not the datastore
- Pathing, multipathing, and failover follow SAN rules
- vSphere is coordinating access, not owning the data layout
Understanding that division helps when troubleshooting. If performance or connectivity is off, the answer is usually in the SAN, not vSphere.
The mapping file itself is tiny and exists only so vSphere can reference the raw device. You can inspect it when troubleshooting, but do not edit it manually. If the mapping becomes invalid, recreating the RDM is the safe fix.
Preparing the LUN
RDM setup starts on the storage side, not in the hypervisor.
- Create the LUN on the array and present it to every ESXi host that may run the VM. Consistency matters here. Use the same LUN ID across hosts and verify zoning or masking carefully.
- After presentation, rescan storage adapters on the hosts and confirm:
- The device appears on all required hosts
- Multipathing is correct
- SATP/PSP policies match vendor guidance
If the LUN is not cleanly visible everywhere, stop and fix that first. RDM will not compensate for bad presentation.
Adding an RDM disk to a VM
Once the LUN is visible, the vSphere side is straightforward.
Edit the VM settings and add a new disk, choosing Raw Device Mapping instead of a VMDK. Select the LUN from the list, choose the compatibility mode, and store the small mapping file on a datastore.
That is it. There is no data copy because the data is already on the LUN.
Inside the guest OS, the disk appears uninitialized. Partition and format it just like a new physical drive.
What you gain
RDM can give you tighter alignment with array-level operations. If your storage team relies on hardware replication, consistency groups, or external snapshot orchestration, RDM lets those workflows operate without abstraction.
What it does not give you is magic performance. Modern VMFS and VMDK stacks are already efficient. The difference is usually negligible unless you have a very specific workload pattern.
The real value is behavioral, not speed-related.
Tradeoffs you need to accept
RDM adds coordination overhead between virtualization and storage teams. You are now managing access at two layers.
It also reduces portability. Moving a VM with an RDM requires the destination hosts to see the same LUN. That complicates migrations, lab copies, and DR testing if storage layouts differ.
Feature support also depends on mode. pRDM especially limits what vSphere can do because it deliberately steps out of the way.
None of this is a problem if you actually need RDM. It becomes a problem when RDM was chosen out of habit.
A quick note for vSAN environments
RDM is meant for external block storage. It does not sit on top of vSAN. If you need guest-level access to shared storage in a vSAN cluster, you are looking at in-guest protocols (iSCSI, NFS) rather than RDM.
When to choose something else
Many historical RDM use cases are better solved today with shared VMDKs, modern clustering support, or storage integrations that did not exist when RDM was introduced.
If you are reaching for RDM because “that’s how we always did SQL clusters,” it is worth re-checking current platform capabilities before committing.
If you are using it because the application explicitly requires it, then you are exactly the audience RDM was designed for.
Final thoughts
RDM is not obsolete, but it is no longer the general-purpose tool it once was. Treat it as a specialized option for workloads that need direct LUN interaction or array-driven behavior. Use it deliberately, configure it carefully, and avoid it when a standard virtual disk does the job with less friction.
