Here are a few more questions and answers that I recently added to the SRM FAQ:
Do I need to have VMtools installed on my VMs?
Having VMtools installed on VMs recovered by SRM is not required, though it is helpful. SRM will use VMtools for a few things related to recovery:
- VMtools will be used to shutdown VMs gracefully as opposed to powering them off
- VMtools heartbeats will be used to let SRM know that a VM is ready and to start the next VM or step in the recovery plan
- VMtools are used to customize IP addresses when supported by the VM OS
What if I want different recovery settings (IP address, start order, etc) for the same VM in different recovery plans?
That is currently not supported. Customization settings in SRM are associated with protected virtual machines. If the same protected virtual machine is a part of multiple recovery plans, then all recovery plans use a single copy of the customization settings.
Can I have a VM get one address during a test and another during an actual failover?
You configure IP customization as part of the process of configuring the recovery properties of a virtual machine so when using the SRM IP customization, a VM will receive the same IP address in both a Test and a Recovery.
It would be possible to write and run a script as part of a recovery to detect whether a test or actual failover was being run and to have the script customize the IP address accordingly. That said, the main idea of running a test with SRM is to duplicate the actual failover so using different addresses for test and recovery doesn’t fit with that, which is why it isn’t supported directly in the product.
Can I have multiple SRAs communicating with the same array?
Yes. In general, SRAs always see and report all replicated devices they see in the array. The list they return can be further filtered
- Some SRAs have the capability to filter devices based on some prefix. In this case, the SRA simply does not even return to SRM any device that starts with “foo*”, for example. The prefix is typically specified in the connection parameters when creating an Array Manager entry in SRM.
- SRM performs device matching only between the two array managers it knows.
- For a given replicated device pair, SRM will find a matching device in VC, for example, a datastore or an RDM. Replicated devices that are not visible to VC will be ignored.
- For a given replicated device that has a matching datastore/RDM, SRM only cares about it if it is protected. For datastores, it has to be added to a protection group explicitly. For RDMs – the corresponding VM must reside on a replicated datastore which is a part of a protection group and this VM needs to be protected (SRM will put warnings if it is not).
Can I run an SRM test with the site-to-site links disconnected?
Running a recovery plan test is supported with vSphere Replication and with some SRAs. Check with your SRA vendor to confirm is they support running a test with the inter-site links disconnected.
Can I use SRM to meet my RTO of “x”?
Calculating a probable recovery time objective (RTO) is not simple as there are many variables that are unique to each customer implementation. These are just guidelines as the only way to get a real feel for the recovery time is to try it in your environment. Running a test failover will also give you an idea of how long your recovery will take. Keep in mind that an actual failover or planned migration will be the most accurate.
So what influences the possible failover time? Here are a few of the major factors:
- Number of protected VMs
- Number of datastores being recovered (more relevant for array replication, fewer datastores/LUNs means less mount/unmount operations)
- The layout of datastores on the array (if using array-based replication grouping datastores into “device” or “consistency” groups equals fewer objects for SRM to process)
- Number of recovery sites hosts (number of ESXi hosts is an optimization axis, more hosts you have, faster you recover the VM’s, assume one host can easily power on well in excess of 100 VMs per minute if needed and if resource available)
- Resource utilization of recovery sites hosts (if hosts are running other workloads this will need to be factored in)
- PostPowerOn Guest Customization steps (if used, think network changes, each IP customization enabled VM will reboot twice so add in that additional time to the total accumulated time)
The factors differ depending on if you are using array-based replication or vSphere Replication. When recovering VM’s via vSphere Replication this is software based replication so there are no storage devices to remount. During the recovery, we simply reload the VM configuration and point it to the replicated VMDKs. This means with vSphere Replication there is no datastore mount steps to perform at the recovery site. So using vSphere Replication will mean in theory the recovery will be quicker than using say array replication with FC protocol. Keep in mind, this is only valid if vSphere replication fits your needs.
What are the ports used by SRM?
This is dependent on the version of SRM. See below for details by version:
- 8.1 – https://docs.vmware.com/en/Site-Recovery-Manager/8.1/com.vmware.srm.install_config.doc/GUID-499D3C83-B8FD-4D4C-AE3D-19F518A13C98.html
- 6.5 – https://kb.vmware.com/s/article/2147112
- 6.1 – https://kb.vmware.com/s/article/2119329
- 6.0 – https://kb.vmware.com/s/article/2103394
- 5.8 – https://kb.vmware.com/s/article/2081159
- 1.0-5.5 – https://kb.vmware.com/s/article/1009562
I want to protect “x” software with SRM, will it work?
If your VM runs on an OS that is supported on vSphere and it can be powered off and back on without issue then it will be able to be recovered by SRM. From the VMs perspective that is all that happens to a VM when it is failed over or recovered by SRM. It powers off (either crashing in the event of a disaster or shutdown via VMtools in a planned migration) and then powers back on at the recovery site. Everything else related to replicating storage, placeholder VMs, etc is invisible to the VMs OS.
This isn’t to say that all VMs are able to be successfully recovered with SRM just that there are no specific restrictions to SRM that would cause it not to work with a particular application.
I hope you find these answers helpful. As always, I owe a huge debt of gratitude to my friends and colleagues Ken Werneberg, Jeff Hunter, Lee Dilworth, Stefan Tsonev, Ivan Jordanov and many more for their help with these answers and for all that I know about SRM and vSphere Replication.
