This KB applies to:

• Customers moving from SDC to NVMe/TCP on PowerFlex 5.0 systems
• VMware vSphere 8.0U3 and 9.x environments using RDMs with either multi-writer or shared physical scsi bus controller for disks
• Oracle RAC clusters
• Windows Server Failover Clustering, including:
  • SQL Server Failover Clusters
  • File Server Clusters
  • Cluster Quorum disks

Support:

Dell supports the following versions for these procedures when using Clustered VMDK:

• ESXi versions 8.0U3 and 9.x
  • These versions support NVMe/TCP Clustered VMDK on PowerFlex 5.0
• PowerFlex 5.0
  • PowerFlex 4.x is not supported

When converting Oracle RAC, if you are not using Clustered VMDK, PowerFlex 4.x is supported.

Overview

This article outlines the supported, best‑practice approaches for converting existing SDC, RDM‑based application clusters to shared VMDKs on NVMe/TCP datastores. Conversion methods differ based on application requirements. Plan accordingly. Dell expects the user of this KB to be proficient in the covered technologies; therefore, steps are high-level and rarely include syntax.

There are two primary RDM use cases covered here:

1. Oracle RAC using physical RDMs with multi‑writer
2. Windows Server Failover Clustering (WSFC) using physical RDMs for SCSI3-PR

There is an important concept regarding virtual storage controller in VMware VMs which is essential to understand before proceeding. These controllers are responsible for connecting virtual disks to the VM. Virtual controllers are not tied to the physical storage protocol used by the underlying datastore. For example, while the default controller is labeled as “SCSI,” it is entirely virtual and does not reflect or restrict the physical storage transport used underneath. Because of this abstraction, it makes no functional difference whether you attach a VMDK using a virtual SCSI or NVMe controller regardless of whether the storage protocol is SCSI or NVMeoF. In practice, VMware generally recommends using SCSI controllers no matter the storage the VMware Paravirtual (PVSCSI) type, as they tend to offer greater stability and improved performance for most workloads; however, you can use NVMe controllers if you prefer. 

1. Oracle RAC: Converting RDMs to VMDKs

Some Oracle RAC environments use RDMs to provide shared storage for datafiles or ASM disk groups, rather than VMDKs. It is possible to convert these setups online, though some methods do require downtime. We cover both RDM-based and ASM.

1.1 RAC without ASM

If Oracle Automatic Storage Management (ASM) is not in use, you can convert online using one of the following methods.

Option A — Online datafile migration

1. Create new shared VMDKs:
• VMFS datastore on NVMe/TCP (Clustered VMDK property NOT required)
• Thick Provision Eager Zeroed (EZT)
• Multi‑writer enabled
2. Attach VMDKs to all RAC nodes.
3. Add new datafiles using the VMDKs.
4. Migrate data from RDM‑based datafiles to VMDK‑based datafiles.
5. Drop the original RDM‑based datafiles.
6. Use crsctl/ocrconfig to move clusterware.

This approach avoids downtime but may require tablespace‑level or object‑level data movement which can be time consuming.

Option B — Convert to ASM (preferred)

Converting to ASM simplifies long‑term storage management and is the recommended strategic end state.

Two supported approaches exist:

• Online migration into ASM disk groups
• RMAN using BACKUP AS COPY DATABASE
• Requires a short outage
• Faster and safer for large databases
• Commonly preferred for production systems

1.2 RAC already using ASM

If ASM is in use, RDM replacement is straightforward and online:

1. Create new shared VMDKs:
• VMFS datastore on NVMe/TCP (clustered VMDK property NOT required)
• Thick Provision Eager Zeroed
• Multi‑writer enabled
2. Add the VMDKs to the ASM disk group.
3. Allow ASM rebalance to complete.
4. Drop ASM disks backed by RDMs.
5. Use crsctl/ocrconfig to move clusterware.

This process requires no application downtime and presents minimal risk.

2. WSFC: Converting RDMs to VMDKs

⚠️ Important: Perform WSFC migration one disk at a time to maintain cluster stability. This example is a two-node cluster.

2.1 Prerequisites (mandatory)

VMware requirements

• VM hardware version supports clustered VMDKs
• VMFS datastore on NVMe/TCP
• Clustered VMDK feature enabled
• Thick Provision Eager Zeroed disks
• No snapshots on cluster VMs
• Storage DRS disabled

WSFC requirements

• Cluster healthy
• Cluster validation clean (warnings acceptable)
• Each disk has a single owning node

2.2 Create new shared VMDKs

For each RDM disk:

1. Create a new VMDK on NVMe/TCP datastore (Clustered VMDK required):
• Same or larger size
• Thick Provision Eager Zeroed
2. Attach the VMDK to both cluster nodes:
• Same SCSI controller type (PVSCSI recommended)
• Same controller number
• Same SCSI ID
• Enable SCSI physical bus sharing

2.3 Prepare disk (owner node only)

On the current owning node:

1. Bring the new disk online.
2. Initialize as GPT.
3. Format NTFS with 128KB.
4. Assign a temporary drive letter.

On the secondary node, leave the disk offline.

2.4 Migrate data (disk‑by‑disk)

Example for a SQL Server data disk:

1. Fail the SQL role to the owning node.
2. Stop SQL resources (SQL Server) using the old RDM, keep disk online.
3. Copy data using robocopy where R is the RDM and V is the new VMDK:
   1. robocopy R:\ V:\ /MIR /COPYALL /DCOPY:T /R:0 /W:0
4. Verify data integrity.
5. Change drive letters so new disk has old letter.
6. Update cluster resource dependencies to reference the new disk.
7. Bring resources online.
8. Move ownership to another node to test.
9. When complete, remove dependency to old disk (RDM).
10. Repeat for each data disk

Repeat this process for:

• Log disks
• Temp

2.5 Replace cluster disk resource

After validation:

1. Remove the old RDM disk from the cluster role.
2. Add the new VMDK disk to the role.
3. Confirm ownership and dependencies.
4. Move ownership to another node to test.

2.6 Quorum disk migration (if in use)

To prevent accidental cluster outage:

1. Temporarily switch quorum to node majority rather than disk.
   1. Set-ClusterQuorum -NodeMajority
2. Follow section 2.3 to add a new disk.
3. Add the disk to the cluster in the UI or Add-ClusterDisk in PS.
4. Set the new disk as the quorum in UI or Set-ClusterQuorum -DiskWitness "Cluster Disk X"
5. Offline and remove the RDM disk.

3 Remove RDMs

Only after successful validation in either use case:

1. Remove RDM mappings from both VMs.
2. Detach LUNs from ESXi hosts.
3. Umap the volumes in PowerFlex Manager.

4 Common issues

1. Failure to use EZT disks
   • The clustered solutions covered here require EZT – no support for thin or zeroedthick
2. Mismatched controller configuration. Any below mismatch prevents the disk from functioning correctly in the cluster.
   • The same SCSI controller type
   • The same controller number
   • The same SCSI ID
3. Failure to set multi-writer on Oracle EZT vmdks on each VM (node) for each VMDK
4. Failure to set SCSI physical bus sharing on the controller for WSFC 

4.1 Configuration support

Addtional documentation links (in no particular order):

https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver17

https://learn.microsoft.com/sql/sql-server/failover-clusters/windows/change-failover-cluster-instance-storage

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy

https://knowledge.broadcom.com/external/article/313472/microsoft-windows-server-failover-cluste.html

https://blogs.vmware.com/cloud-foundation/2023/07/06/shared-disk-clustering-on-vsphere-getting-out-of-the-multi-writer-flag-jam/

https://www.vmware.com/docs/vmw-vmdk-whitepaper-mmt

https://learn.microsoft.com/en-us/troubleshoot/windows-server/high-availability/configuring-witness-resource

https://learn.microsoft.com/windows-server/administration/windows-commands/robocopy