SRM Service, He's dead Jim.

SRM service, He's dead Jim.

Ever had your SRM server randomly through an error like this?

The server 'server.domain' could not interpret the client's request (the remove server returned and error: (503) Server Unavailable.)

Well I might just have a fix for ya!

This was a pretty simple one. Cracked open the logs (C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs\vmware-dr-###) and saw this gem:

DBManager error: Could not initialize Vdb connection: ODBC error: (08001) - [Microsoft][SQL Native Client]Named Pipes Provider: Could not open a connection to SQL Server [2].

In this case, the issue was that the SQL server was dead due to an expired password but this message in the logs could point to SQL being down for any reason or being unreachable (if say you had a remote SQL server instead of a local one). Always remember to crack open those logs!

**********************************************Disclaimer**********************************************

This blog is in no way sponsored, supported or endorsed by VMware. Any configuration or environmental changes are to be made at your own risk. Casey, VMware, and any other company and/or persons mentioned in this blog take no responsibility for anything.  

NetApp SRA issue

A NetApp SRA issue:

Last week I encountered an SRM issue that I thought would be an easy fix. Turned out it wasn't.

The Issue:

The admin was unable to create a protection group pair. In the devices tab, we saw replication one way but not the other. We saw the following error:

Device '/vol/NFS_datastore_name' cannot be matched to a remote peer device.

The Environment:

The important thing here is that the datastores were NFS. The array was a NetApp DS5020. The other important thing in this case was that the storage that wasn't replicating was on a new shelf (same head though).

The Fix:

This turned out to be an issue with the NetApp SRA. The datastores were unable to replicate due to a permissions issue. Originally, the array was set up to allow all hosts to have root access. To fix the issue, we had to give the hosts explicit root access individually. Once that was finished, replication started right up!



**********************************************Disclaimer**********************************************
This blog is in no way sponsored, supported or endorsed by VMware. Any configuration or environmental changes are to be made at your own risk. Casey, VMware, and any other company and/or persons mentioned in this blog take no responsibility for anything.