Site Recovery Manager FAQ

VMware Site Recovery Manager™ is the industry-leading disaster recovery management solution. Site Recovery Manager offers automated orchestration and non-disruptive testing of centralized recovery plans for all virtualized applications.

VMware Live Recovery is the latest version of disaster and ransomware recovery from VMware. It combines VMware Live Site Recovery (previously Site Recovery Manager) with VMware Live Cyber Recovery (previously VMware Cloud Disaster Recovery) under a single shared management console and a single license. Customers can protect applications and data from modern ransomware and other disasters across VMware Cloud Foundation environments on-premises and in public clouds with flexible licensing for changing business needs and threats. For more details see the VMware Live Recovery FAQ and the VMware Live Recovery resource page.

Site Recovery Manager integrates with VMware vSphere® through VMware vCenter™ and an underlying replication technology. It can integrate natively with vSphere Replication™ or with a broad range of storage array-based replication solutions from leading storage vendors through storage replication adapters or VMware Virtual Volumes. Site Recovery Manager guides users through the process of configuring recovery plans. At the time of failover or testing, Site Recovery Manager automates the execution of the recovery plan. 

vSphere Replication is VMware’s hypervisor-based replication technology for vSphere virtual machines. vSphere Replication is a robust and scalable solution that simplifies DR protection through storage-independent, VM-centric replication with customizable recovery point objectives (RPO) and multiple point-in-time recovery. vSphere Replication is a feature of the vSphere platform, included at no additional cost. For more details and answers to common questions about vSphere Replication see the FAQ located here.

Yes. A 60-day evaluation copy of Site Recovery Manager can be downloaded from the Product Evaluation Center. Only the latest generally available version of the Site Recovery Manager product is available for free evaluation.

Yes. vSphere Replication is a feature of the vSphere platform. As such, it can be evaluated as part of the 60-day evaluation copy of vSphere.

VMware Hands-on-Labs are the best option if you don't want to or can't install SRM in your environment. VMware Hands-on-Labs provides an opportunity to interact with live environments and either follow the lab manual through various exercises or just try out the available products.  There is a lab specifically focused on Site Recovery Manager that will allow you to experience much of what Site Recovery Manager has to offer without you spending the time installing and configuring it in your own environment.

Yes. It is only available as a photon OS-based appliance.

VMware offers the VMware Site Recovery (VSR) service for VMC on AWS

Site Recovery Manager can be used with supported Hyperscaler SDDC service offerings. This requires Site Recovery Manager subscription term licenses. Please refer to the Pricing and Licensing section for more details. 

Currently, Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE), Oracle Cloud VMware Solution (OCVS) and Alibaba Cloud are supported. 

We may add other hyperscaler cloud services after evaluation. If your company is interested in being added to this list, please contact your VMware Alliance Executive. 

Production support is automatically included when purchasing a Site Recovery Manager subscription license.

Depending on the criticality of your systems being managed by Site Recovery Manager, you may want to consider purchasing Mission Critical Support or Business Critical Support. The Mission Critical Support is a supplemental service to Production Support which provides the highest level of personalized, proactive customer support available from VMware. It includes an assigned Account Manager and quarterly business reviews. Business Critical Support is a supplemental service to Production Support which provides your centralized data center team with personalized technical support delivered by a designated team of experts familiar with your system configuration, past support experience and specific business needs. For more details on Production and Basic subscription levels, please visit the VMware Support Services Website. 

When you purchase Site Recovery Manager subscription licenses production support is automatically included for the term of the subscription.  

Up-to-date information regarding the Lifecycle Policy of Site Recovery Manager can be found here

Questions and problems that appear to be caused by Site Recovery Manager should be directed to VMware support. Questions and problems that appear to be caused by the array-based replication software, storage replication adapter (SRA) or storage array should be directed to the support services of the storage vendor. VMware and the vendors who provide replication adapters have cooperative agreements in place to ensure that support requests can be coordinated between VMware and the storage partner.

Instances of vSphere, vCenter Server and Site Recovery Manager are required at both the protected site and the recovery site (Note: This does not involve licensing which is covered later segment in this document). Site Recovery Manager also requires an underlying replication solution to copy virtual machines to the recovery site. Customers have the choice to use either vSphere Replication or third-party array-based replication software. When using array-based replication software a Storage Replication Adapter (SRA) is also required.  Using VMware Virtual Volumes integrated with Site Recovery Manager does not require an SRA.

Site Recovery Manager is supported with any edition of vSphere, except for vSphere Essentials. See the Product Interoperability Matrix for specific versions of vSphere that are supported for each version of Site Recovery Manager. Site Recovery Manager does not require that all licenses of vSphere associated with its deployment be from the same edition.  

Site Recovery Manager is supported with vCenter Server for Essentials, vCenter Server Foundation and vCenter Server Standard. See the Product Interoperability Matrix for specific versions of vCenter Server that are supported for each version of Site Recovery Manager. Note that Site Recovery Manager has requirements about the versions of vCenter Server it is compatible with.   

Site Recovery Manager integrates with third-party storage array-based replication products through either VMware Virtual Volumes or a Storage Replication Adapter (SRA). See this Compatibility Guide for supported VMware Virtual Volumes array vendors and this Compatibility Guide for supported SRAs.  

Yes. Site Recovery Manager supports stretched storage solutions available by some of the major VMware storage partners. For details, check their SRA documentation.

Yes. Currently, Site Recovery Manager requires an SRA to integrate with stretched storage products. See the Compatibility Guide for supported SRAs.

Yes. SRAs are updated to support the latest generally available version of Site Recovery Manager. See the SRA documentation for details.

Yes, vSAN is fully supported as either a protected or recovery site for Site Recovery Manager when using vSphere Replication.

Yes, Site Recovery Manager is compatible with VMs located on VMware Virtual Volumes and replicated either with array-based replication or vSphere Replication. For a list of Virtual Volumes array-based replication compatible vendors see here.

Site Recovery Manager works with many of the features in vSphere. For a complete list and details around usage check here.

See the VMware Live Recovery FAQ for details

Customers with SRM Standard perpetual, SRM Enterprise perpetual, and SRM per-processor perpetual licenses can no longer renew SnS or purchase additional perpetual licenses. To expand the number of licenses in their environment, customers must purchase VMware Live Recovery subscription licenses.

Customers with SRM for Hyperscalers subscription licenses can continue using them and purchase additional SRM subscription licenses for use either with Hyperscalers.

The licensing metric for Site Recovery Manager (and VMware Live Recovery) is per protected virtual machine. A protected virtual machine is defined as a VM that is part of a Site Recovery Manager protection group, regardless of the state of the VM.
Note – In the past, Site Recovery Manager also had “per processor” licensing, which is no longer available. 

Yes. Customers with SRM perpetual or term licenses can purchase VMware Live Recovery licenses without impacting their existing ones. Please see the next question regarding using different types of licenses in SRM instances.

No. SRM/VLSR only supports having one SRM/VLSR license installed per instance/pair. If you need to use multiple license types you must install a separate SRM pair for each different license type.

Yes, vSphere licenses are required for any server on which vSphere is installed, whether that host is at a protected or recovery site and whether a server is running or powered down at the recovery site. Site Recovery Manager requires at least one licensed vSphere server at the protected and recovery sites.

Yes, Site Recovery Manager requires two active and licensed vCenter Server instances, one at each site (protected and recovery).
NOTE: The shared recovery sites feature in Site Recovery Manager enables multiple protected sites with multiple vCenter Server instances to be recovered at a site with a single vCenter Server instance. (i.e., the multiple instances of Site Recovery Manager running at the shared recovery site are registered with the same single instance of vCenter Server at the shared recovery site, so you do not need multiple vCenter Server instances at the shared recovery site.).

Only virtual machines that are protected by Site Recovery Manager require Site Recovery Manager licensing. Licenses are required for all protected virtual machines, even if they are powered off.

There are two scenarios to consider:
Uni-directional protection: Site Recovery Manager is configured only to fail over virtual machines from site A to site B. In this case, licenses are required only for the protected virtual machines at protected site A.

Bi-directional protection: Site Recovery Manager is configured to fail over virtual machines from site A to site B at the same time that it is configured to fail over a different set of virtual machines from site B to site A. In this case, Site Recovery Manager licenses must be purchased for the protected virtual machines at both sites. 

To fail back from site B to site A (after failover from site A to site B), Site Recovery Manager licenses are required for the “re-protected” virtual machines at Site B. The “per virtual machine” licenses originally used at site A can be used at site B for this purpose, as long as the licenses are no longer in use at site A.

Site Recovery Manager licenses are required only for protected virtual machines. In a shared recovery site scenario (multiple protected sites configured to failover into a shared recovery site) Site Recovery Manager licenses are required only at the protected sites. The shared recovery site does not require any additional Site Recovery Manager licenses to protect those sites.

Site Recovery Manager uses the same license-key system used by vSphere and vCenter Server.

Site Recovery Manager is licensed through vCenter Server.

No. vSphere Replication is included with vSphere Essentials Plus and higher editions. Usage of vSphere Replication for disaster recovery with Site Recovery Manager does not require additional licensing.

Yes. Customers with a current SnS contract or subscription for Site Recovery Manager are entitled to licenses of the latest version of the product at no additional charge.

No, Because their SnS is expired, they are not entitled to receive an upgrade to the latest version of Site Recovery Manager. They must purchase a new SRM Subscription license if they want access to the latest release.

Yes. As long as you have an active SnS contract or subscription at the time of general availability of the latest version of Site Recovery Manager, you are entitled to perform a version upgrade on your licenses at any time.

Yes. You can upgrade all, some, or none of your Site Recovery Manager licenses. For example, if you have 50 Site Recovery Manager 8.8 licenses and want to upgrade only 30 of them, you will have 30 licenses of the latest version of Site Recovery Manager and 20 licenses of Site Recovery Manager 8.8 after the upgrade process.

Licensing restrictions are only imposed when a VM is protected. The idea behind this is that recovery should always work. Remember that running a reprotect workflow will trigger the license check, so valid licenses will be required. The reprotect workflow will fail if there are insufficient licenses at the recovery site (which is now your protected site).

Remember that SRM is licensed per protected VM, so if the license key is installed at the protected site, not using enhanced linked mode when the VMs failover to the recovery site, they won't be able to be reprotected until licenses are moved from the protected site.

The Site Recovery Manager license enables customers to use SRM in any topology supported by SRM, including hyperscalers as protected sites, recovery sites, or both.

Because their SnS is expired, they are not entitled to receive an upgrade to the latest version of Site Recovery Manager. They must purchase a new subscription license.

Customers are not required to use the latest version of Site Recovery Manager, although it is recommended. Licenses of the latest version cannot be used with earlier versions of Site Recovery Manager. Customers must downgrade their Site Recovery Manager licenses via the License Portal. Site Recovery Manager Enterprise edition licenses may be downgraded at a 1:1 VM ratio. Licenses cannot be downgraded to versions earlier than Site Recovery Manager 8.1.

Site Recovery Manager requires either vSphere Replication or storage-based replication for Virtual Volumes, iSCSI, FibreChannel, or NFS storage arrays. For storage-based replication, VMware works with storage partners to ensure that customers can deploy Site Recovery Manager with their choice of storage and storage replication platform. Site Recovery Manager is architected to work with a wide variety of replication software through “storage replication adapter” plug-ins developed and certified by storage vendors for use with Site Recovery Manager. The current list of storage replication adapters and supported storage is available online in the Storage Partner Compatibility Matrix.

New adapters can be added at any time without requiring a new release of Site Recovery Manager. Please contact your storage partner for specific information about when specific replication adapters will be available.

Site Recovery Manager orchestrates the recovery process for virtual machines. In cases in which some workloads are running on physical severs with a separate disaster recovery solution, Site Recovery Manager coordinates the recovery process by allowing users to create custom scripts that ensure that workloads are restored in appropriate order.

Site Recovery Manager provides a choice between vSphere Replication and storage-based replication, enabling customers to choose the best solution for their specific needs. For a detailed comparison of the differences between array-based replication and vSphere replication please review this blog post.

Yes, Site Recovery Manager provides automated failback. The first step is to perform a “reprotect” of the virtual machines from the failover site to the original production site. This consists in coordinating the reversal of replication to the original site, and mapping virtual machines back to their original virtual machine folders, virtual switches, and resource pools. The second step is to execute the planned migration back to the original site, using the original recovery plan executed in reverse direction. Each of these steps is automated in that there is no manual intervention required beyond starting the reprotect and migration processes.

Planned migration and DR failover both leverage the same recovery plans. DR failover is used in the event of a disaster and is designed to quickly recover virtual machines at the failover site. Planned migration is used for preventive failovers or for routine migrations. Planned migration ensures an orderly shutdown of virtual machines at the protected site, synchronizes the data with the failover site by ensuring complete replication of all the data, and finally recovers virtual machines at the failover site. Planned migration ensures application-consistent to the secondary site with no data loss.

The level of consistency depends on the recovery process and the underlying replication solution. For DR failovers, consistency is provided by the underlying replication solution. With storage-based replication, many VMware partners offer solutions to ensure application-consistent replication and recoveries. vSphere Replication supports VSS-based application consistency for Windows environments. In all other environments, Site Recovery Manager provides file-consistent recovery. When executing a planned migration (as opposed to DR failover), Site Recovery Manager provides fully application-consistent migrations between sites, since virtual machines are gracefully shutdown before completing replication and initiating the recovery plan.

Yes, Site Recovery Manager supports configurations in which both sites are running active virtual machines that Site Recovery Manager can recover at the other site. Site Recovery Manager also supports active/passive sites in which Site Recovery Manager recovers virtual machines from a protected site at a recovery site that is not running other virtual machines during normal operation.

In an active/active scenario, users configure recovery plan workflows in one direction from Site 1 to Site 2 for the protected virtual machines at Site 1. Recovery plan workflows are configured in the opposite direction from Site 2 to Site 1 for the protected virtual machines at Site 2.

Yes. Site Recovery Manager provides the option to protect multiple sites using a common “shared recovery site”. At this shared recovery site, you will still need to have multiple instances of Site Recovery Manager running. Each instance manages the pairing with one of the protected sites. However, to provide simpler disaster recovery management in a many- to-one configuration, only one instance of vCenter Server is required at the shared recovery site. All instances of Site Recovery Manager register with that single vCenter Server instance. Please consult the product documentation for more details on how to use this feature.

In addition to the shared recovery site configuration, Site Recovery Manager also allows and supports shared protected site (1:N) and many-to-many (N:N) configurations. It is also supported to begin with a standard two site SRM deployment and later on add additional site pairings to add in more complex topologies. Keep in mind that while Site Recovery Manager does allow for the failover of different VMs to different sites, it does not support the failover of the same VM to multiple recovery sites. Site Recovery Manager only supports a VM being protected by a single Site Recovery Manager pair.

Site Recovery Manager provides capabilities for disaster recovery automation and management for a virtual environment. Work with your VMware and VMware partner contacts to understand which products complement VMware technology for disaster recovery and the use cases to which they apply.

VMware does not have preferred storage and replication partners, only a list of currently supported replication adapters provided by partners.

Site Recovery Manager does not support server-based replication.

Site Recovery Manager requires a supported version of vSphere and a supported version of vCenter Server. Consult the Site Recovery Manager Compatibility Matrix for your specific version of Site Recovery Manager.

Site Recovery Manager is compatible with vSphere Essentials Plus. It is not compatible with vSphere Essentials.

Site Recovery Manager does not support the free version of vSphere ESXi but does support licensed versions of vSphere ESXi used with a supported vSphere or VMware Infrastructure edition and version. See the Compatibility Matrix for the latest information.

Yes, Site Recovery Manager requires two active and licensed vCenter Server instances, one at each site (protected and recovery). NOTE: The shared recovery/protected sites feature in Site Recovery Manager enables multiple protected or recovery sites with multiple vCenter Server instances to be recovered or protected at a site with a single vCenter Server instance. (I.e., the multiple instances of Site Recovery Manager running at the shared recovery/protection sites are registered with the same single instance of vCenter Server at the shared recovery/protection site, so you do not need multiple vCenter Server instances at the shared recovery/protection site.).

The Site Recovery Manager Service must be installed at both the primary site and the recovery site. However, Site Recovery Manager licenses are required for both sites (protected virtual machines) only when each site acts as a recovery site for the other. For protection in one direction (e.g., Site 1 site fails over to Site 2), licenses are required only for the protected virtual machines at Site 1.

Yes. It is only deployable as a VM.

Site Recovery Manager provides its own embedded vPostgres database. This database requires no separate licensing or configuration. 

Requirements for placeholder datastores are minimal:

1. Placeholder datastores need to be accessible from every host in the cluster or there needs to be 1 placeholder datastore per host (local disk fine)

2. Space requirements are minimal, less than 100KB per placeholder VM. If the customer protects the limit of 5000 VMs, they need less than 500MB

3. The placeholder datastore cannot be replicated

4. If using vSphereReplication do not use the same datastore for incoming replications

SRM is coordinating the replication of the VMX file, and moving the VM to a new vCenter, so the attributes it preserves are the ones that are in the VMX file, and unrelated specifically to the protected site vCenter.

What is preserved:
- GUID (note that the placeholder VM at the recovery site will have it's own UUID. However after a failover, the recovered VM will have the same UUID as it did at the protected site)
- MAC address
- VM config (nics, drives, etc)

What is not preserved
- MOID
- Reservations/limits (these can be configured on the placeholder, or even better, use a resource pool and map it in SRM)
- DRS configurations (affinity/anti-affinity rules, DRS groups, etc)
- VM permissions

More details on reservations, affinity rules and limits:
When Site Recovery Manager recovers a virtual machine to the recovery site, it does not preserve any reservations, affinity rules, or limits that you have placed on the virtual machine. Site Recovery Manager does not preserve reservations, affinity rules, and limits on the recovery site because the recovery site might have different resource requirements to the protected site.
You can set reservations, affinity rules, and limits for recovered virtual machines by configuring reservations and limits on the resource pools on the recovery site and setting up the resource pool mapping accordingly. Alternatively, you can set reservations, affinity rules, or limits manually on the placeholder virtual machines on the recovery site.

Technically yes. Is it recommended? No. SRM workflows, including failover, can be triggered by a script. However, In almost all scenarios, falling over in an automated fashion is a poor idea.  There is a lot of risk associated with it and a lot of potential liability for failing over due to incorrect reasoning.  Failing over automatically in test mode, however, makes a lot of sense For more details see this blog post – Automating Failover with SRM and PowerCLI

There are two requirements.
1. The VM must have a supported version of VMtools installed
2. The OS on the VM must be compatible with vCenter's Guest OS Customization feature. This can be checked here

Yes, Site Recovery Manager provides full support for virtual machines using RDMs.

No. Site Recovery Manager can change the IP address and VLAN of virtual machines at the time of recovery to the configuration the user specifies during setup.

Site Recovery Manager can update the IP address and virtual switch for recovered virtual machines but does not update DNS tables at the recovery site. However, both Windows and Linux have dynamic DNS options that can do this. 

Virtual machines are shut down in the reverse order that they are powered on in. The user can specify the order in which virtual machines must be started, either serially because of dependencies and/or priority groups, or in parallel if required.

Site Recovery Manager does not run any components in the virtual machine or on the vSphere ESX® server during normal operation, so it does not affect the performance of virtual machines.

Bandwidth requirements depend on the amount of data being replicated, the frequency of replication and the specific replication software. Site Recovery Manager sends very little information between sites itself and as a result generally has no impact on the bandwidth required between sites. If using vSphere Replication, use the vSphere Replication Bandwidth Calculator to estimate bandwidth requirements. If using array-based replication, your replication vendor can help to determine the required bandwidth for replication.

Yes. Site Recovery Manager monitors whether VMware Tools has started running in each virtual machine to determine whether the virtual machines have booted successfully.

Execution of recovery does not depend on the vCenter Server or Site Recovery Manager Service at the protected site. However, recovery does depend on having a running vCenter Server and Site Recovery Manager Service at the recovery site. When the Site Recovery Manager Service is running in a virtual machine, vSphere High Availability can be used to restart the Site Recovery Manager virtual machine in the event of a physical server failure.

Site Recovery Manager notifies the administrator when it cannot connect to the remote site. Failover is always manually initiated to avoid split-brain scenarios. Recovery does not require connectivity to the protected site.

Yes. They are available in the History section of each Recovery Plan.

Site Recovery Manager does not automatically initiate failover. Failover initiation must be done manually. A best practice is to strictly limit which users have permission to initiate failover. Site Recovery Manager does include a REST API that can be used to externally initiate failover if required. Please note that this is not recommended.

vSphere vMotion® is useful only when the virtual machine is still running. If an outage occurs, vSphere vMotion has no running virtual machine to operate on. Site Recovery Manager is designed to handle cases in which virtual machines are no longer running at the production site because of an outage and must be recovered at a recovery site.

VMware provides a REST API for Site Recovery Manager that enables custom integration with other disaster recovery software. Site Recovery Manager does not provide built-in integration with third-party software products other than array-based replication software.

After running the recovery connect the sites (first making sure that the originally protected VMs are powered off) and run a planned migration of the recovery plan that they had done a disaster recovery of. SRM is intelligent enough to know that it has already performed a failover and will skip unnecessary steps. Rerunning the plan will ensure that the steps that weren't completed at the original site are completed and get's the plan back into the appropriate state to reverse the direction of replication.

Forced recovery was introduced to handle a scenario where the source array is down but the vSphere layer is up. In early versions of SRM that scenario meant failovers would sometimes timeout waiting for a reply. Forced failover fixes that bluntly by telling SRM to override its normal safety checks so be careful how you use it. If the original site returns after running a forced recovery, to get things back in sync, run the failover again, then run it as a planned migration.

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 shut down 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

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.

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 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.

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).

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.

Calculating a probable recovery time objective (RTO) is not simple as there are many variables that are unique to each customer's 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.

This is dependent on the version of SRM see the documentation for details.

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.

vSphere Replication is the industry’s first hypervisor-based replication, purpose-built for vSphere and Site Recovery Manager. vSphere Replication enables replication between sites at an individual virtual machine level and is managed directly in vCenter Server. With vSphere Replication, customers can deploy heterogeneous storage arrays across sites, reducing costs by using lower-end storage at the failover site.

With vSphere Replication, users can select the replication schedule for each individual ESX host. The RPO can be selected from a range of 5 minutes to 24 hours.

vSphere Replication cannot be used in conjunction with VMs that are not powered on, vSphere Fault Tolerance, Virtual Machine templates, linked clones, and physical RDMs.

Site Recovery Manager can support discrete, asynchronous and synchronous replication. See the Storage Partner Compatibility Matrixes for Site Recovery Manager to determine which storage replication adapters support which types of replication for a specific array.

The storage replication adapters translate generic commands generated by Site Recovery Manager for tasks such as querying replicated datastores and promoting replicated data stores into array-specific commands. They enable Site Recovery Manager to work with a variety of array types.

The Storage Partner Compatibility Matrix Compatibility Matrixes for Site Recovery Manager includes a list of storage replication adapters that have passed VMware certification for Site Recovery Manager as well as the storage array and replication with which they are supported.

VMware continues to work with additional storage partners to help them develop new adapters for Site Recovery Manager. New adapters can be added and used at any time without requiring a new release of Site Recovery Manager. If you are interested in using Site Recovery Manager with replication solutions that are not currently supported, contact your storage vendor. Also, let VMware know about your request by contacting your VMware representative or reseller.

Yes.

Yes. Multiple replication adapters can be installed in Site Recovery Manager to enable it to communicate with multiple arrays simultaneously. Keep in mind that a VM with VMDKs stored on multiple arrays cannot be protected with SRM. All VM files must be located on the same array.

Site Recovery Manager is designed to work with all devices that present themselves as storage targets and can replicate their underlying storage. Many storage- virtualization solutions can operate in this manner. For Site Recovery Manager to work with a given storage- virtualization device, a storage replication adapter must be available for that device. The Storage Partner Compatibility Matrixes for Site Recovery Manager includes a complete list of supported storage virtualization solutions.

Yes. Site Recovery Manager supports NFS storage and replication.

Site Recovery Manager monitors the replication configuration to detect when replication is turned off for a datastore containing protected virtual machines, so that it can notify administrators.

Site Recovery Manager takes consistency groups into account, although support varies depending on storage vendor. Consult the storage vendor storage replication adapter readme for details.

The answer depends on the capabilities of the array. For some arrays, the storage replication adapter takes a snapshot or clone of the datastore replica and presents it to the vSphere ESX hosts to use for testing. For other arrays, it halts replication temporarily to do testing.

VMware supports configurations that use storage replication adapters written by storage partners only. Storage partners who wish to write a new adapter should contact VMware directly.

Problems that appear to be caused by Site Recovery Manager should be directed to VMware support. Problems that appear to be caused by the replication software, storage replication adapter or storage array should be directed to the appropriate storage partner’s support services. VMware and the vendors who provide replication adapters have cooperative support agreements in place to ensure that support requests can be coordinated between VMware and the storage partner.

VMware publishes a currently supported storage and replication list in the Storage Partner Compatibility Matrix. If you have any remaining questions, you should direct them to the appropriate storage vendor.

Any application that is supported on vSphere is supported for protection with Site Recovery Manager. That said there are some things that shouldn't be protected with Site Recovery Manager. This blog has the details.