Site Recovery Manager FAQ

VMware vCenter™ 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.

Site Recovery Manager integrates with VMware vSphere® through VMware vCenter Server™ 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 Enterprise edition can be downloaded from the Product Evaluation Center. Only the latest generally available version of the Site Recovery Manager product is available for a 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.

Your best option is likely the VMware Hands-on-Labs. VMware Hands-on-Labs provide 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. As of version 8.4 it is only available as a photon OS-based appliance.

VMware offers 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 for Hyperscalers subscription term licenses. Please refer to the Pricing and Licensing section for more details. 

Currently, Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE), and Oracle Cloud VMware Solution (OCVS) 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. 

What kind of technical support is required/available for Site Recovery Manager?
To ensure that you realize the full benefits of the Site Recovery Manager product a minimum of one year of Support and Subscription is required – either Basic or Production. 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. 

At least 1 year of Basic or Production Support is required for the general Site Recovery Manager perpetual licenses, which is purchased separately from the license. If you purchase the Site Recovery Manager for Hyperscalers subscription term 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 (this does not involve licensing aspects. Licensing is covered in a later segment of this document) Site Recovery Manager also requires an underlying replication product 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 6.1 and newer versions support 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.

Site Recovery Manager is available in 2 editions, Standard and Enterprise. Site Recovery Manager Enterprise provides enterprise-level protection to all virtualized applications with no licensing restriction on the number of virtual machines that can be protected. It also provides certain advanced capabilities that are not available in the Standard Edition. Site Recovery Manager Standard is designed for smaller environments and is limited to 75 protected virtual machines per physical site and per Site Recovery Manager instance. Check here for more details

VMware Site Recovery Manager Standard Edition is subject to the following restrictions:
(a) protect up to seventy-five (75) Virtual Machines within a physical facility or building
(b) For each running copy of VMware Site Recovery Manager Standard Edition, manage up to seventy-five (75) Protected Virtual Machines
If at any given time, the number of Protected Virtual Machines in subsections (a) or (b) exceeds seventy-five (75), You are required to upgrade all VMware Site Recovery Manager Standard Edition licenses to VMware Site Recovery Manager Enterprise Edition.
Notwithstanding the foregoing, the SRM Standard Edition Restriction shall not apply if a failover of Protected Virtual Machines causes the number of Protected Virtual Machines to exceed the SRM Standard Edition Restriction within a physical facility or building for a reasonable period of time

Yes. Customers may upgrade Site Recovery Manager Standard to Site Recovery Manager Enterprise in 25 virtual machine packs

No. Only one edition of Site Recovery Manager can be configured under a vCenter Server instance

No. As a general policy, VMware does not allow for edition downgrades for any of its products. Site Recovery Manager is no exception.

The licensing metrics for Site Recovery Manager 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 to new customers

Customers who already have “per processor” licenses can continue buying “per Processor” licenses for expansion. These licenses are only available in the internal VMware Price books. The transaction SKU is “VC-SRM8-ENTP-C/-F/-A”

No, A customer can either have “per processor” licenses or “per virtual machine” licenses for the same SRM instance
Note - Customer can have one SRM instance with “per Processor” licenses and another SRM instance with “per virtual machine” licenses. However, customers who do not have “per processor” licenses cannot expand their environment with “per Processor” licenses

Customers who have processor licenses for Site Recovery Manager are entitled to virtual machine licenses converted at a ratio of 5 virtual machines per 1 processor. (e.g., a customer with 20 processor licenses would receive 100 virtual machine licenses). The licenses are automatically made available in the VMware License Management portal upon an upgrade of the version of Site Recovery Manager.
For cases in which the standard conversion ratio is not sufficient to support a customer’s existing deployment, customers can contact VMware support for more information.
To request a conversion, go to the Support tab on the My VMware® portal and file a Licensing Support Request. For more information on the conversion process, please see the per virtual machine licensing page.

Customers who have “per virtual machine” licenses for Site Recovery Manager cannot convert their licenses to processor licenses.

vCloud Suite Enterprise with 6.0 and earlier versions included Site Recovery Manager Licenses. Site Recovery Manager was unbundled from vCloud Suite Enterprise in 7.0 version. Customers with vCloud Suite 6 .0 Enterprise and are on active SnS, are entitled to Site Recovery Manager (per CPU) licensing. These customers can continue buying “per Processor” licenses for expansion or convert their licenses to “per Virtual Machine” licenses and buy “per Virtual Machine” licenses for expansion.
For more details, please read the Knowledge Base article

Licenses of the latest version cannot be used with earlier versions of Site Recovery Manager. Customers will need to downgrade their Site Recovery Manager licenses via the License Portal. Site Recovery Manager Enterprise edition licenses may be downgraded with a conversion ratio of 1 virtual machine to 1 virtual machine. Licenses cannot be downgraded to versions earlier than Site Recovery Manager 5.0.

Yes, vSphere licenses are required for any server on which vSphere is installed, whether that host is at a protected site or a 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 both the protected site and the recovery site.

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

With “per Virtual Machine” licensing, 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.

With “per processor” licensing, each processor on hosts that are running protected virtual machines requires Site Recovery Manager licensing.

There are two scenarios to consider:
Uni-directional protection: Site Recovery Manager is configured only to fail over virtual machines from site A to the site B. In this case, licenses are required only for the protected virtual machines at protected site A. With “per processor” licensing, each processor on hosts that are running protected virtual machines requires Site Recovery Manager licensing.

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. With “per processor” licensing, each processor on hosts that are running protected virtual machines requires Site Recovery Manager licensing.

To failback 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. If Site Recovery Manager is being licensed “per processor” through the vCloud Suite Enterprise at site A and virtual machines are failed over to a site B that originally licensed with vSphere only, the vCloud Suite licenses can be transferred to site B in order to “re-protect” and failback the virtual machines.

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 any additional licensing.

Yes. Under VMware’s new per-CPU pricing model, one CPU license covers up to 32 cores in a single CPU. If the CPU has more than 32 cores, additional (per-CPU) licenses are required.
NOTE: Older versions of Site Recovery Manager may show a license violation warning message if there are more than 12 cores in the protected processor. Customers can ignore this warning message. This warning message has been removed in current releases.

Yes. Customers with a current Support and Subscription contract for Site Recovery Manager are entitled to licenses of the latest version of the product at no additional charge through their subscription entitlement.
Customers with current Support and Subscription contracts for bundles that contain Site Recovery Manager are entitled to new versions and new licenses based on the subscription entitlement for the individual products in the bundle.
If a customer's Support and Subscription (SnS) contract expired before the latest Site Recovery Manager release, are they entitled to upgrades? Because their SnS is expired, they are not entitled to receive an upgrade to the latest version of Site Recovery Manager. They will need to renew their SnS and pay the appropriate back fees/penalties. If you are in this situation you may request a Support Contract Renewal quote.

Yes. As long as you have an active SnS contract 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 5.0 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 5.0 after the upgrade process.

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

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 general Site Recovery Manager license is available as a perpetual license in packs of 25 VMs. Site Recovery Manager for Hyperscalers is available as a prepaid 1- and 3-year term license only and is licensed on a per protected VM basis in packs of 25 VMs.

No. Existing Site Recovery Manager perpetual licenses cannot be used on public clouds. Site Recovery Managers on Hyperscalers offers customers on-demand cloud capabilities and follows the subscription/term licensing model

No. There is currently no official upgrade program in place for the SRM for Hyperscalers term license. Customers on active SnS cannot trade in existing Site Recovery Manager perpetual licenses for a one-time credit towards a subscription purchase. Please work with your VMware account representative for financial consideration for existing perpetual Site Recovery Manager licenses.

The Site Recovery Manager perpetual licenses are used for the purpose of disaster recovery between your on-premises environments only. It cannot be used for the purpose of disaster recovery to or within public cloud services environments. 

The Site Recovery Manager for Hyperscalers term license can be used to protect

1.  Workloads running in an on-premises datacenter to a supported hyperscaler cloud SDDC
2. Workloads running on a supported hyperscaler cloud SDDC to an on-premises data center, and
3. Workloads between two supported hyperscaler cloud SDDCs from the same hyperscaler (cross hyperscaler cloud configurations are not currently supported).   

A listing of hyperscaler clouds currently supported is included in the Introduction and General Information section above. 

No, not at this time.  

No. Existing Site Recovery Manager perpetual licenses cannot be used on public clouds.

The transaction SKUs for a 1-year term license with production SnS (25 VM pack) is VC-SRM8-HY25E-1Y-TLSS-C/-F and a 3-year term license with production SnS (25 VM pack) is VC-SRM8-HY25E-3Y-TLSS-C/-F.

VMware sells the Site Recovery Manager for Hyperscalers on term license using VMware’s own sales motions, including its channels, to customers. VMware will provide support for the Site Recovery Manager licenses directly to customers. Please contact your VMware sales representative to learn more.

Customers can use the SRM evaluation licenses on the SRM evaluation site. After the 60-day evaluation period, and for production use, customers will have to purchase the SRM for Hyperscalers term license. The evaluation license is strictly for evaluation purposes and there is no conversion to production, meaning that customers may have to re-replicate data for example. The evaluation licenses can be replaced with a Term License and SRM will continue to work non-disruptively through this evaluation-to-production conversion process. 

SDDC hosts will need to be obtained directly from the respective hyperscaler (Microsoft, Google, or Oracle) through the standard mechanisms they may offer (e.g., trial, on-demand, etc.).

Site Recovery Manager requires either vSphere Replication or storage-based replication for 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 6.0 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.

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.

The Site Recovery Manager Service can run on either the same physical server as vCenter Server or a separate server. The VMware recommendation would be that both vCenter and Site Recovery Manager be installed on Virtual Machines to take advantage of the benefits virtual machines provide (HA, DRS, snapshots, etc.). We would also recommend that vCenter and SRM be installed on separate VMs (eg. VM for vCenter, VM for SRM) to allow for easier maintenance, troubleshooting and performance. There is also a Photon-OS based appliance for SRM that supports the full scale and capabilities of SRM.

Yes. This is the recommended installation method.

No

Site Recovery Manager provides the option of its own embedded vPostgres database. This database requires no separate licensing or configuration. Site Recovery Manager also provides the option of utilizing external databases. These databases must be installed by the user. Each Site Recovery Manager service requires Open Database Connectivity (ODBC) only to the database at its own site. See the VMware Product Interoperability Matrixes for a list of specific databases and database versions supported with Site Recovery Manager.

No, it is fully supported for all environments up to all configuration maximums.

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.

For storage policy protection, Site Recovery Manager applies inventory mappings to virtual machines when you run a recovery plan that contains a storage policy protection group.
With array-based and vSphere Replication protection groups, Site Recovery Manager applies inventory mappings at the moment that you configure protection on a virtual machine. With storage policy protection groups, because storage policy protection is dynamic, Site Recovery Manager only applies the inventory mappings at the moment that you run a recovery plan. Virtual machine placement decisions are made according to the inventory mappings when a recovery plan runs, so Site Recovery Manager does not create 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. There is an example script for updating Microsoft DNS and BIND servers included in the scripts folder on Site Recovery Manager servers.

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, 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 an SDK that can be used to externally initiate failover if required.

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 an SDK for Site Recovery Manager that enables some degree of 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 below for details by version:

• 8.3 - Documentation
• 8.2 - Documentation
• 8.1 – Documentation
• 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

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 15 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 Matrix Compatibility Matrixes for vCenter Site Recovery Manager 6.0 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 vCenter Site Recovery Manager 6.0 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 Matrix Compatibility Matrixes for vCenter Site Recovery Manager 6.0 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 list of currently supported storage and replication in the Storage Partner Compatibility Matrix. Remaining questions should be directed to the appropriate storage vendor.

There is a white paper located here that covers Site Recovery Manager best practices in regards to performance/reduced RTO. 

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.