Skip to content


vSphere Replication and SRM Implementation Notes

I went through a vSphere Replication and Site Recovery Manager implementation this week and overall it went very well.  There are a few things that aren’t really noted in the documentation that I wanted to get out there just in case anyone else runs into the speed bumps I did this week.  While I’ve implemented SRM with array based replication many times, this was my first go with vSphere Replication.

 

First, and most important, is to use the FQDN throughout the entire implementation of SRM, VRMS, and VRS.  While we used the FQDN for the vCenter server when we installed SRM, when you deploy the vSphere Replication Manager Server (VMRS) it defaults to the IP address for the vCenter server on the configuration page.  If you don’t change this to the FQDN of the vCenter server SRM won’t be able to “find” the VRMS servers when you attempt to create the connection between the two.

 

SQL Express port issue.  This customer decided they wanted to use the vCenter implementation of SQL Express for the VRMS database.  While this works fine you need to understand that when vCenter does it’s install of SQL Express it chooses a variable port by default.  Since it does that, you’ll need to manually change the port the DB connections are received on.  I recommend port 1433 which is the default SQL Server port.  You can follow a good blog post on MSDN here:  Link

 

VRMS and VRS SSH root access.  By default root access is not enabled for remote SSH management.  While a good security practice, it makes troubleshooting a PitA.  There is a great KB article you can read here, but I’ve listed the steps below if you would rather stay here.

  1. Open the console for the appliance in vCenter
  2. login with root. You set this password during deployment of the appliance
  3. cd to /etc/ssh/
  4. vi sshd_config
  5. find line with “PermitRootLogin” and set to yes. (type i to insert and then ESC when done editing. :wq will save changed and quit.)
  6. restart the SSH service with service sshd restart
Logs for VRMS and VRS.  Locations for the logs for each appliance are listed below.  Once SSH is configured you can use a SFTP client to connect and download the logs.  If you need a support bundle, refer to the KB article listed above.
VRMS logs = /opt/vmware/hms/logs  You’re looking for the latest hms*.log
VRS logs = /var/log/vmware  You’re looking for the latest hbrsrv*.log
Multiple Datastores per Source VM.  Sometimes you might have multiple datastores presented to a VM for any number of reasons.  If you’re in this boat here is how you need to setup the target datastores you’re replicating to.  You have two options here:
  1. Create a one to one datastore “mirror” so that you can automatically map the datastores to each other in the “Datastore Mappings” tab within vSphere Replication.
  2. Create a single datastore and then create folders on that datastore for the individual hard disks the VM is using.  e.g. For server FS1 that has 3 VMDKs, each on a different datastore you would create folders fs1_hd1, fs1_hd2, and fs1_hd3 on a single datastore. Then you can simply select those folders when setting up vSphere Replication for that VM.

 

Well I hope this helps someone as they’re going through this implementation.  It definitely gives me a quick go to if I run into any of these again. ;)
Share

Posted in Snig, vmware.

Tagged with , , , , .


2 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Chetan says

    Hi Ron,
    Your write-up was greatly helpful since I am planning to implement SRM with vSphere Replication in our environment shortly.
    Our vCenter database will also run on an instance of SQL Express. So the pointer about variable ports was certainly instructive.
    As far as seeding the initial copy goes, what are efficient ways to do it? is sneakernet the preferred way? If so, would I be copying just the vmdk,vmx files onto the removable drive (USB?)

    Thanks!

  2. snig says

    I’m glad this helped!

    SRM with vSphere replication has the option for you to seed the data at the remote site by allowing you to select the VMDKs on the remote datastore when replication is being setup. All you need to move over is the VMDKs associated with the VM(s) you are replicating. I would recommend creating the same directory structure at the DR site on the datastores that you have at the production site.

    A large USB disk would work fine.