topic Problem configuring SRM protection on VM with RDM LUN in VMware Solutions Discussions

Problem configuring SRM protection on VM with RDM LUN

tjoycegmac — Thu, 05 Jun 2025 06:52:16 GMT

**Cross-posted to VMware community - Site Recovery Manager**

Greetings,

Bottom line:

I'm unable to protect RDM LUNs that reside within VMs on NFS datastores. Surely, this is supposed to work, right?

Details:

I have SRM (4.1.1) setup and working very well, I have successfully completed tests using machines that do not have RDM LUNs. This is on NetApp with OnTap 7.3.5 using adapter 1.4.3P1. The VM datastores are all NFS.

The problem comes when trying to configure protection for VMs with RDM luns using SnapDrive. Even though the LUNs as well as the RDM mapping datastore (called 'rdm_data') are replicated to the DR site, the "Configure Protection" wizard says: "A virtual machine has one or more devices which don't have backings on replicated LUNs".

When I go through the wizard, it claims that the three LUNs configured as RDMs are "Not Configured", as opposed to "Replicated" as is shown for the two NFS disks. It does, however, detect the rdm_data datastore and has the correct protection location listed for that datastore.

I'm not even sure if this is a NetApp or VMware issue, but I'm hoping I just missed an obvious configuration step somewhere along the line. I've read tr-3671 backwards and forwards and am really stumped.

Log file on protected site reports:

[2011-06-23 08:55:39.679 06764 trivia 'PrimarySanProvider'] 'Retrieved 4 properties of 1 objects of type 'vim.VirtualMachine'' took 0.009 seconds

[2011-06-23 08:55:39.684 06764 trivia 'PrimarySanProvider'] 'Retrieved 1 properties of 2 objects of type 'vim.Datastore'' took 0.003 seconds

[2011-06-23 08:55:39.684 06764 trivia 'PrimarySanProvider'] RDM disk 2002 is mapped to a non-replicated LUN '020000000060a98000486e5339504a4a78333650654c554e202020'

[2011-06-23 08:55:39.685 06764 trivia 'PrimarySanProvider'] RDM disk 2003 is mapped to a non-replicated LUN '020001000060a98000486e5339504a4a79384631374c554e202020'

[2011-06-23 08:55:39.685 06764 trivia 'PrimarySanProvider'] RDM disk 2004 is mapped to a non-replicated LUN '020002000060a98000486e5339504a4a78334135314c554e202020'

[2011-06-23 08:55:39.685 06764 warning 'PrimarySanProvider'] Error filling shadow VM spec: (dr.san.fault.CannotProtectVirtualDevices) {

Thanks

Problem configuring SRM protection on VM with RDM LUN

tjoycegmac — Thu, 23 Jun 2011 15:13:32 GMT

This is the error in the protection wizard. Hard Disks 3-5 are replicated RDM LUNs. rdm_data is the vmfs datastore holding the mapping files.

Problem configuring SRM protection on VM with RDM LUN

justmike2 — Thu, 06 Oct 2011 18:40:28 GMT

Same exact problem. I have one other VM with the same set up that is configured just fine, so I know it is possible to do.... Just can't remember how "we" did it.

Problem configuring SRM protection on VM with RDM LUN

justmike2 — Fri, 07 Oct 2011 18:42:51 GMT

In our case, there was a disconnect between the filer and SRM. It kept stating that the RDM's were not replicated to the DR site even though I would manually update the volume they were in from filerview. Came back the next day and was able to protect the Vm without incident. ??

Re: Problem configuring SRM protection on VM with RDM LUN

tjoycegmac — Mon, 14 Nov 2011 16:48:51 GMT

I thought an upgade to ESXi 5.0, SRM 5.0 and NetApp SRA 2.0 would clear this up, but this is still a problem...though I can't believe I've missed anything, since I can now see this documentation in my sleep.

Opening a case with NetApp now.

Re: Problem configuring SRM protection on VM with RDM LUN

SYSADMIN91 — Thu, 23 Feb 2012 21:50:21 GMT

Hello,

Is your VM's system drive and RDM LUNs all on the same filer by chance? According to TR-3671 page 13, relationships where the data (vmdk or RDM) owned by any individual VM exists on multiple arrays (physical or vFiler) are not supported.

Thanks,

Michael

Re: Problem configuring SRM protection on VM with RDM LUN

ADMWWHITEHURST — Mon, 02 Jul 2012 17:15:27 GMT

Any updates on this? I am facing the same issue and was told that SRM 5 handles this with ease.. but i've yet to see this "ease".. 😃