Quantcast
Channel: VMware Communities : Discussion List - Site Recovery Manager
Viewing all articles
Browse latest Browse all 3691

SRM 5.1-941848/NetApp RDMs - Always getting errors

$
0
0

This is a bit frustrating. Since day 1 of deployment, SRM has NEVER been consistent in behavior. The Engineer that originally deployed the install stated that in his experience it's just not something that always runs from beginning to end without some sort of "issue". Most of the time we can just push through a failure, but at other times you have to spend days, if not weeks troubleshooting through issues. Being bounced around from the storage vendor to VMware with each side claiming the issue is not theirs.

 

Within 5 months I've reinstalled SRM about 6 times now. I can do it in my sleep at this point.

 

Calling VMware and having to wait 1-2 days for a response, and then another week or so for another after logs are collected is not ideal anymore, so I'm hoping I can figure out this issue here within the community.

 

Sorry for the rant, I just feel like at this point we should have completed our Production failover test and still find myself battling what seems like the same old errors.

 

So, on with the error. We are using the latest SRM build (5.1.0 -941848) and the latest SRA adapter from NetApp. When attempting a test recovery with a VMFS datastore with guests that have RDMs I will get the following errors:

 

Error - Failed to sync data on replica device '/vol/volumename/qt1/lun1'. Device found is neither of the SAN type nor of the NAS type. Ensure that the device exists on the storage array and is of type NAS or SAN.

 

I found a few articles that walk you through disabling fastpath on the filers and also changing the storage value from the default 5 connections down to 2. The second option fixed this issue last time I was presented with it. When it happened again VMware support said the volume in question didn't have any room for snapshots as they were full. i was advised to clear some up and then retry the test. Here I have done all of the above and yet I still see the issues.

 

We have a production failover test scheduled for the weekend after next. At this point I hate to push this back as it wouldn't be the first time we did.

 

 

 

And FYI, those of you that believe a TEST is a substancial "test".. it's not. Doing a full blown Recovery compared to just a TEST is night and day. In our exprience we've run many succesful tests to only have them blow up when doing a RECOVERY.


Viewing all articles
Browse latest Browse all 3691

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>