Raw Device Mappings tend to show up in the places where infrastructure history is still attached to the workload.
A database server was moved from physical hardware years ago. A file server needed a very large LUN before VMDK limits improved. A clustered application depended on shared storage. A storage team wanted array-level tooling to see the disk directly. At the time, the decision probably made sense.
The problem is that the platform around the workload has moved forward.
When you are standardizing on VCF, moving workloads into a VxRail or vSAN-backed environment, cleaning up backup architecture, or preparing a legacy application for a more portable operating model, RDMs become operational drag. They complicate mobility, recovery, snapshot behavior, datastore placement, and the long-term modernization path.
This walkthrough uses Broadcom KB 374087 as the technical baseline for converting Raw Device Mappings into virtual disks. Broadcom confirms that both virtual-mode and physical-mode RDMs can be converted to VMDK, but the method and downtime profile depend heavily on the RDM compatibility mode. Virtual compatibility mode RDMs can be converted while the VM is powered on; physical compatibility mode RDMs require downtime for either the entire VM or at least the RDM backing LUN. The conversion is a block-for-block copy, so the guest partition type and file system are not the determining factors.
Objective
The objective is to convert an existing RDM-backed disk into a standard VMDK while preserving the guest operating system disk layout, mount points, drive letters, and application data.
The target outcome is simple:
The VM no longer depends on a raw SAN LUN.
The data disk exists as a VMDK on the selected datastore.
The application is validated after conversion.
The old RDM LUN is retained temporarily for rollback, then decommissioned after acceptance.
This is not just a storage cleanup task. It is a migration pattern for making legacy workloads easier to operate inside a modern VMware platform.
Why RDMs Become a Modernization Problem
An RDM is not just “another disk.” It is a mapping file that points a VM to a raw physical storage device. Broadcom describes the RDM as a special mapping file in a VMFS volume that manages metadata for the mapped device, while the VM sees the mapped device as a virtual SCSI device.
That design creates a split operational model.
The VM configuration is managed in vCenter. The disk capacity and identity live on the array. The guest OS sees a disk. The backup platform may or may not be able to protect it the same way it protects normal VMDKs. The migration team has to understand all of those layers before touching anything.
In a VxRail or vSAN modernization path, that split gets even more important. Broadcom states that RDMs are not supported for VMs that reside on vSAN or vVols; if the VM cannot be migrated to a VMFS datastore and still requires that storage, the resolution is to use a VMDK.
That is the real reason this conversion matters.
You are not converting an RDM to a VMDK because VMDKs are newer. You are doing it because VMDKs fit the operational model you are trying to standardize around.
AreaRDM impactVMDK modernization benefitBackupPhysical-mode RDMs do not support standard VM snapshots, which affects snapshot-based backup workflows.Standard VMDKs align better with VM-level backup and recovery patterns.MobilityvMotion keeps RDMs as RDMs; it does not solve the storage dependency.VMDKs are easier to place, move, and manage through datastore-level operations.vSAN / VxRailRDMs are not supported for VMs residing on vSAN or vVols.VMDKs can live on the vSAN datastore and be governed by storage policy.OperationsTeams must preserve LUN masking, mapping files, SCSI IDs, array ownership, and guest disk identity.The disk becomes part of the VM’s normal virtual disk lifecycle.ModernizationThe workload remains tied to external raw LUN presentation.The workload becomes more portable across supported datastore targets.
Physical-mode RDMs are especially restrictive. They allow minimal SCSI virtualization and are useful for SAN management software or certain clustering scenarios, but VMware snapshots are not available for physical compatibility mode RDMs. Virtual-mode RDMs behave more like virtual disks and are more portable, but they are still not the same thing as simply operating a normal VMDK.
Scope and Assumptions
This walkthrough assumes the following:
The VM is already running on vSphere.
The source disk is an RDM in either virtual or physical compatibility mode.
The target is a VMDK on a supported datastore.
You have enough free capacity on the destination datastore for the converted disk.
Application owners can provide a validation plan.
Backup owners can confirm the pre-change and post-change protection model.
Storage owners can confirm the raw LUN identity and retention window.
The VM is not part of an unsupported or misunderstood shared-disk cluster configuration.
That last point matters.
If the RDM is part of WSFC, Oracle RAC, another shared-disk database cluster, or an application-level clustering design, do not treat this as a simple single-VM disk conversion. Broadcom’s RDM mode-switching guidance calls out clustered configurations and notes that all cluster nodes may need coordinated handling when switching RDM modes.
For vSAN-backed shared-disk designs, use the appropriate clustered VMDK or multi-writer pattern only where supported by the application and platform. Broadcom’s Oracle RAC on vSAN guidance is explicit that vSAN does not support RDMs and that the documented approach applies to virtual disks resident on the vSAN datastore.
Prerequisites
Before starting, collect enough evidence to make rollback possible.
At minimum, capture:
VM name and vCenter inventory path.
Current host and cluster.
Current datastore for VM configuration files.
RDM disk number in vCenter.
RDM compatibility mode: RawPhysical or RawVirtual.
SCSI controller and target ID.
Backing canonical name, NAA, or VML identifier.
Guest OS disk number, drive letter, mount point, or Linux device mapping.
Application services using the disk.
Current backup status.
Snapshot status.
Destination datastore or vSAN storage policy.
Maintenance window and rollback owner.
Broadcom provides PowerCLI guidance for identifying VMs with RDMs by using Get-VM | Get-HardDisk -DiskType “RawPhysical”,”RawVirtual” and selecting the parent VM, disk type, SCSI canonical name, and device name.
Use a report before the change so you are not relying on screenshots alone.
# Inventory RDM-backed disks before conversion.
# Update the export path for your environment.
$RdmReport = Get-VM | ForEach-Object {
$vm = $_
Get-HardDisk -VM $vm -DiskType “RawPhysical”,”RawVirtual” |
Select-Object `
@{Name = “VM”; Expression = { $vm.Name }},
Name,
DiskType,
CapacityGB,
ScsiCanonicalName,
DeviceName,
Filename
}
$RdmReport |
Sort-Object VM, Name |
Format-Table -AutoSize
$RdmReport |
Export-Csv “.rdm-inventory-before-conversion.csv” -NoTypeInformation
Successful pre-change output should show every RDM candidate and its mode. If a disk does not appear in the report, do not assume it is safe. Validate in the vSphere Client and inside the guest OS.
Also confirm there are no active VMware snapshots before storage migration work. Broadcom specifically warns to commit snapshots before storage migrations, especially if mappings or disks are removed and later re-added.
Migration Flow at a Glance
The important decision is not “RDM or VMDK.” You already know the target is VMDK.
The important decision is “virtual-mode RDM or physical-mode RDM.”
What to notice in this flow: physical-mode RDMs are not just a checkbox difference. They change the cutover strategy. Virtual-mode RDM conversion can be handled directly through Storage vMotion with the right disk format selection. Physical-mode RDMs require a more deliberate outage model.
Conversion Decision Table
Source disk statePreferred conversion pathDowntime profileKey caveatVirtual compatibility mode RDMStorage vMotion and choose Thin or Thick disk format for the RDM diskCan be performed while powered onIf you keep the same format, only the mapping file may move.Physical compatibility mode RDM, full outage acceptablePower off VM, Storage vMotion, choose Thin or Thick disk formatFull VM downtimeCleanest operational path when the application can tolerate outage.Physical compatibility mode RDM, full VM outage not acceptableStop or quiesce the application using the RDM, remove/re-add the same LUN as virtual-mode RDM, then Storage vMotion to VMDKRDM/application outage, not necessarily full VM outageRequires precise SCSI ID and guest disk handling.Shared-disk clusterSeparate cluster migration designApplication-specificDo not treat as a normal single-VM disk migration.
Broadcom KB 374087 states that virtual-mode RDM data can be migrated to VMDK with Storage vMotion by changing the disk format in Advanced View, and that physical-mode RDM conversion is not supported with Storage vMotion while the VM is powered on unless you first remove the physical RDM mapping, re-add the same raw LUN as a virtual-mode RDM, and then perform Storage vMotion.
Execution Stage 1: Freeze the Design Before Freezing the Workload
Before touching the VM, hold a short technical review with the infrastructure, application, storage, and backup owners.
The review should answer these questions:
Which RDMs are being converted?
Are they virtual or physical compatibility mode?
Are they shared with any other VM?
What application writes to the disk?
What is the last known-good backup or array snapshot?
What is the rollback point?
How long will the old LUN be retained?
What post-conversion backup test will prove the new state?
Do not skip the storage owner. When an RDM is removed from a VM configuration, Broadcom warns that the device can become visible as an available device during VMFS datastore expansion workflows, creating a risk that someone selects it and overwrites existing data. Broadcom recommends making the necessary parties aware or temporarily detaching the device from hosts, while noting that an HBA rescan can reattach devices.
That is exactly the kind of operational edge case that turns a simple migration into a data-loss incident.
Execution Stage 2: Convert a Virtual-Mode RDM with Storage vMotion
Use this path when the RDM is already in virtual compatibility mode.
In the vSphere Client:
Confirm the disk is a virtual-mode RDM.
Confirm there are no active snapshots that need consolidation.
Right-click the VM and choose Migrate.
Select Change storage only.
Choose the destination datastore.
Use the advanced disk configuration view.
For the RDM disk, change the disk format to Thin Provision, Thick Provision Lazy Zeroed, or Thick Provision Eager Zeroed, depending on your standard.
Do not leave the disk as the same format as source.
Start the Storage vMotion task.
Monitor the task until completion.
Re-check the VM hardware and confirm the disk is now a VMDK.
The key step is changing the disk format. Broadcom notes that if you do not change the destination format to thick or thin provisioned in the advanced section of the migration wizard, only the RDM mapping file is migrated to the destination datastore.
Also avoid a same-datastore no-op. KB 374087 notes that when source and destination datastores are the same, no action is performed even though the task can show as completed. Change both the datastore location and disk format when converting.
After the task completes, run a quick PowerCLI check:
# Confirm the disk no longer reports as RawPhysical or RawVirtual.
# Replace the VM name with your target workload.
Get-VM “APP-SQL-01” |
Get-HardDisk |
Select-Object Parent, Name, DiskType, CapacityGB, Filename |
Format-Table -AutoSize
The converted disk should no longer show as RawPhysical or RawVirtual.
Execution Stage 3: Convert a Physical-Mode RDM with a Full VM Outage
This is the cleanest path for physical-mode RDMs when the business can approve downtime.
In the vSphere Client:
Stop the application cleanly.
Shut down the guest OS.
Confirm the VM is powered off.
Confirm the RDM mode and SCSI address one more time.
Start a storage-only migration.
In the advanced disk configuration view, select the destination datastore.
Change the RDM disk format to the desired VMDK format.
Complete the migration.
Power on the VM.
Validate guest disk identity, application services, and backup behavior.
Broadcom KB 374087 describes this as a supported option for physical-mode RDMs: convert the physical RDM to VMDK using Storage vMotion while the VM is powered off, changing the disk format to thick or thin during the migration.
This method is usually easier to explain, easier to validate, and easier to roll back than an in-service remap. The tradeoff is the outage.
Execution Stage 4: Convert a Physical-Mode RDM with an RDM-Level Outage
Use this path only when the VM must remain powered on but the application or service using the RDM can tolerate a controlled outage.
The basic idea is:
Stop writes to the RDM.
Remove the physical-mode RDM mapping.
Re-add the same raw LUN as a virtual-mode RDM.
Run Storage vMotion and change the disk format to VMDK.
Broadcom describes this as the powered-on physical RDM conversion path: delete the physical RDM disk from the VM, re-add the RDM LUN as a virtual RDM disk, and then Storage vMotion the virtual RDM while changing the disk format to Thin or Thick.
A practical sequence looks like this:
Notify application owners that the disk is entering a write-free window.
Stop the application services that use the RDM.
Inside the guest OS, offline the disk if appropriate for the operating system and application.
In vCenter, record the RDM disk’s SCSI controller and target ID.
Remove the RDM from the VM using the correct action for your vSphere version and change plan.
Re-add the same raw LUN as an RDM disk.
Select Virtual compatibility mode.
Place it on the same SCSI controller and target ID where possible.
Bring the disk online in the guest if required.
Confirm the guest OS sees the same volumes, labels, drive letters, or mount points.
Run Storage vMotion and change the disk format to Thin or Thick to create the VMDK.
Validate the VM and application.
Be careful with the removal wording in the vSphere UI. KB 374087 explains that deleting the RDM disk from the VM deletes the mapping file and not the data on the RDM. However, Broadcom’s separate mode-switching article cautions that in vSphere 8.x, Remove Device and Remove Device and Data must be interpreted carefully; it specifically warns not to select Remove Device and Data unless that is the intention. In vSphere 7.x and earlier, the older Delete from disk option removes only the RDM pointer file when removing the RDM.
That is not a place to rely on memory. Validate the UI behavior for the exact vSphere version before the change window.
Validation and Testing
The migration is not complete when the Storage vMotion task finishes.
Validate at four layers: vCenter, guest OS, application, and protection.
vCenter validation
Confirm:
The disk is no longer listed as an RDM.
The disk path points to a .vmdk on the destination datastore.
The VM has no unexpected snapshots.
The VM hardware still shows the expected controller and disk order.
The old RDM mapping file is no longer attached.
The destination datastore has expected capacity consumption.
For vSAN targets, the VM storage policy is assigned and compliant.
Guest OS validation
Inside the guest, confirm:
Disk count is expected.
Drive letters or mount points are unchanged.
Filesystems mount cleanly.
Application data paths exist.
No unexpected disk signature conflict occurred.
Windows services, Linux mounts, database paths, or application dependencies are healthy.
For Linux systems, verify /etc/fstab, UUID usage, multipath dependencies, and application mount expectations. For Windows systems, verify Disk Management, drive letters, mount points, and application service dependencies.
Application validation
Ask the application owner to run a functional test that proves the disk is usable.
Examples:
SQL Server database online check.
Application service restart.
File share access test.
Batch job read/write test.
Middleware startup validation.
Database consistency check if appropriate for the platform.
The infrastructure team should not declare success based only on VM power state.
Backup validation
After conversion, the backup team should run a new backup and confirm restore visibility for the converted disk.
This is one of the major reasons for doing the work. Physical-mode RDMs do not support VMware-native snapshots, and many VM-level protection patterns rely on snapshot behavior.
Do not assume the backup job automatically behaves correctly after the disk changes. Confirm the disk is included, run a backup, and perform at least a file-level or test restore validation when the workload criticality justifies it.
Cutover Pattern
For production workloads, treat the conversion as a cutover even if the VM stays powered on.
A good cutover pattern looks like this:
Complete the inventory report.
Confirm backup or array snapshot.
Freeze application writes.
Convert the RDM using the correct mode-specific path.
Validate vCenter disk state.
Validate guest disk state.
Validate application functionality.
Run or schedule a post-change backup.
Retain the original LUN through the rollback window.
Decommission the old LUN only after formal acceptance.
The key operational rule is this:
Once the workload starts writing to the converted VMDK, the old RDM LUN becomes stale.
That means the original LUN is a rollback point only to the moment of conversion or to the point of the last synchronized copy. If the application runs for six hours on the VMDK and then the team decides to roll back to the old RDM, those six hours of writes are not magically present on the original LUN.
Plan rollback around data consistency, not just VM configuration.
Rollback and Recovery Notes
Rollback is easiest before production writes resume.
Rollback before application writes resume
If the conversion completes but validation fails before the application is released:
Keep the VM powered off or application stopped.
Detach the newly created VMDK from the VM without deleting it.
Re-add the original RDM LUN using the recorded SCSI controller and target ID.
Confirm guest OS disk identity.
Restart the application.
Validate the application against the original disk.
Preserve the failed converted VMDK for investigation until the change is closed.
Rollback after application writes resume
If the application has written to the new VMDK, rollback becomes a data recovery decision.
Options may include:
Restore from backup.
Restore from array snapshot.
Re-run the conversion from a refreshed source.
Use application-native replication or export/import.
Manually reconcile data if the application supports it.
Do not simply reattach the old RDM and call it rollback unless the application owner confirms the data point is acceptable.
Recovery if the RDM mapping is lost
If an RDM mapping file is removed accidentally but the raw LUN still exists, the recovery pattern is usually to recreate or re-add the mapping to the VM. That is why the pre-change SCSI ID, NAA/VML identifier, and guest disk mapping are so important.
Common Gotchas
Gotcha 1: Only the pointer file moved
If the RDM is virtual-mode and the migration completed suspiciously fast, verify that you actually converted the disk. Broadcom notes that if you do not change the RDM disk format to thick or thin in the advanced migration view, only the mapping file is migrated.
Gotcha 2: Source and destination datastore were the same
KB 374087 notes that if the source and destination datastores are the same, no action is performed even if the task reports completion. Change both datastore location and disk format.
Gotcha 3: vMotion did not remove the RDM dependency
A regular vMotion changes host registration and runtime placement. It does not convert an RDM into a VMDK. Broadcom’s RDM migration guidance states that RDMs remain RDMs when the VM is migrated with vMotion.
Gotcha 4: Physical-mode RDM was treated like virtual-mode RDM
Physical-mode RDMs cannot be converted directly with Storage vMotion while the VM is powered on. KB 374087 shows that attempting to change disk format for a physical RDM during powered-on Storage vMotion results in an unsupported operation error.
Gotcha 5: The disk is part of a cluster
Clustered workloads need their own design. Broadcom notes that clustered applications or clustered VM configurations do not support Storage vMotion in the same way as ordinary VM disk migrations.
Gotcha 6: The destination datastore cannot hold the converted disk
RDMs can represent large raw LUNs. Broadcom warns that conversion can fail if the destination datastore cannot store a single contiguous file as large as the raw LUN.
Gotcha 7: The target is vSAN but the VM still has an RDM
This is a hard stop for VxRail/vSAN modernization. Broadcom states that RDMs are not supported for VMs that reside on vSAN or vVols. If the VM must run there, use a VMDK.
Operational Implications After Conversion
Once the disk is a VMDK, the VM becomes easier to manage as a complete virtual machine object.
That does not mean every operational concern disappears. Large VMDKs still need capacity planning, backup windows, datastore performance review, and application-aware protection. Shared-disk applications still require support validation. Storage policies still need to match workload requirements.
But the ownership model becomes cleaner.
The VM team can see the disk as part of the VM. The backup team can protect it through a more standard virtual disk path. The migration team can move the workload without preserving a raw LUN dependency. The storage team can retire the special-case LUN after the rollback window.
For VCF and VxRail/vSAN environments, this is the point of the exercise. The conversion is not just a one-time storage task. It is part of reducing exceptions before they become blockers in lifecycle management, disaster recovery, backup modernization, and platform standardization.
Conclusion and Next Steps
RDM-to-VMDK conversion is one of those migration tasks that looks simple until you map the dependencies.
The safest pattern is to start with inventory, identify the RDM mode, choose the correct conversion path, validate at every layer, and keep rollback tied to a real data point. Virtual-mode RDMs can usually be converted directly through Storage vMotion with the right disk format selection. Physical-mode RDMs require a deliberate outage model, either by powering off the VM or by temporarily remapping the same LUN as a virtual-mode RDM before converting.
For VxRail and vSAN modernization, the direction is clear: do not carry RDM exceptions forward unless there is a documented, supported reason. Convert them, validate them, protect them, and then remove the old storage dependency with discipline.
The next practical step is to build an RDM inventory report across the environment and classify each disk by workload owner, RDM mode, size, cluster dependency, and conversion window. That turns a risky one-off change into a repeatable migration wave.
External Sources
Broadcom KB 374087: Converting a Raw Device Mapping into a virtual disk
Broadcom KB 337539: Migrating virtual machines with Raw Device Mappings
Broadcom KB 332510: Identifying Virtual Machines with Raw Device Mappings
Broadcom KB 323064: Difference between Physical and Virtual compatibility RDMs
Broadcom KB 339865: Switching an RDM between physical and virtual compatibility modes
Broadcom KB 391143: RDMs not supported for VMs that reside on vSAN or vVols
Broadcom KB 327037: Using Oracle RAC on a vSAN Datastore
vCLS Retreat Mode: When to Use It, What It Breaks, and How to Exit Cleanly
Disable vCLS on a Cluster via Retreat Mode KB 316514 vSphere Cluster Services usually stay in the background until they get in…
The post Converting RDMs to VMDKs: A Practical Migration Pattern for Legacy Workloads appeared first on Digital Thought Disruption.