Information2 use cookies to help you have a superior and more admissible browsing experience on our website. Privacy Policy
Loading...
By:
VMware Site Recovery Manager (SRM), now called VMware Live Site Recovery, is often mistaken for a replication product.
In reality, VMware SRM doesn’t replicate virtual machines itself. It orchestrates disaster recovery by coordinating the underlying replication technology, automating failover and failback, and executing predefined recovery plans across VMware environments.
This guide explains how the architecture fits together, what happens during a failover, and the best practices for keeping recovery operations predictable and reliable.
VMware Site Recovery Manager (SRM), now known as VMware Live Site Recovery (VLSR), is VMware’s disaster recovery orchestration platform. It automates failover, failback, and recovery testing between protected VMware sites.
© VMware Blog
SRM doesn’t replicate VM data itself. It coordinates the recovery process using an underlying replication technology, turning manual runbooks into predictable, automated workflows.
The easiest way to understand SRM is to separate orchestration from replication. SRM is the orchestration layer, while vSphere Replication or storage array-based replication handles data movement between sites. SRM never copies VM data directly. Instead, it registers, configures, and powers on replicated virtual machines (VMs) in the correct sequence when a recovery plan runs.
Since Broadcom acquired VMware, SRM’s new name now is VMware Live Site Recovery within the VMware Live Recovery portfolio. Most sysadmins, technical documentation, and community discussions still refer to it as SRM, so you’ll see both names used interchangeably.
VMware Live Site Recovery provides a set of features that simplify and automate disaster recovery management. Instead of relying on manual runbooks, administrators can define, test, and execute recovery plans directly from vCenter.
This reduces operational complexity and helps ensure a more consistent recovery process during planned migrations or unplanned outages.
One of SRM’s core capabilities is automated recovery orchestration. Rather than powering on all virtual machines at once, administrators can define the exact order and conditions for recovering application stacks.
SRM allows administrators to validate recovery plans without interrupting production workloads.
During a test, the platform creates an isolated test environment at the recovery site using replicated data, enabling teams to verify application startup, networking, and recovery workflows without affecting live production workloads.
SRM integrates directly with vCenter Server, providing a centralized interface for managing disaster recovery operations.
Administrators can configure protection groups, inventory mappings, and recovery plans from a single console while monitoring replication status and recovery readiness across on-premises environments or VMware Cloud on AWS deployments.
This gives full visibility into replication status and DR readiness across the environment.
Understanding how SRM works requires looking at both its architecture and its recovery workflow. The platform uses a paired-site architecture, connecting a protected site with a recovery site to coordinate disaster recovery operations.
A typical SRM deployment consists of a vCenter Server and an SRM appliance at both the protected (primary) site and the recovery (secondary) site. These components are securely paired, allowing them to exchange configuration information, recovery metadata, and health status required to coordinate recovery operations.
SRM does not replicate virtual machine data itself. Instead, it relies on an underlying replication technology to keep workloads synchronized between sites. Administrators typically choose one of two replication methods:
| Feature | vSphere Replication | Array-Based Replication |
|---|---|---|
| Granularity | Per VM | Datastore or LUN level |
| Required Hardware | Works with any supported vSphere storage | Requires compatible storage arrays at both sites |
| Replication Type | Asynchronous | Synchronous or asynchronous |
| Recovery Point Objective (RPO) | 5 minutes to 24 hours | Near-zero (synchronous) or vendor-dependent asynchronous RPO |
| Integration Method | Native vSphere feature | Storage Replication Adapters (SRAs) |
SRM organizes disaster recovery configuration into three logical objects.
Inventory Mappings
Inventory mappings define how resources at the protected site correspond to resources at the recovery site, including networks, folders, clusters, resource pools, and placeholder datastores.
Protection Groups
Protection groups determine which virtual machines are protected and recovered together. Depending on the replication method, they can represent replicated datastores or individual virtual machines.
Recovery Plans
Recovery plans orchestrate the recovery process by combining one or more protection groups with startup priorities, scripts, network mappings, and recovery settings.
When a recovery plan is executed, SRM performs the following sequence:
The VMware SRM recovery lifecycle follows a repeatable sequence of steps.
Administrators first pair the protected and recovery sites, then configure protection groups and recovery plans.
After validating the configuration through recovery testing, they can execute failover when needed and reprotect the environment for future failback.
Implementing VMware SRM successfully requires more than configuring replication and recovery plans. Regular testing, consistent configuration, and careful infrastructure management are all essential to ensure recovery operations work as expected during an actual outage.
SRM is an orchestration layer, not a replication engine. Its actual RTO and RPO depend entirely on what’s replicating data underneath it, whether that’s vSphere Replication or a storage array’s SRA.
Both of those options come with constraints. vSphere Replication is asynchronous replication with an RPO floor of 5 minutes, and it only works VMware-to-VMware. Array-based replication needs matching SRAs on both ends, one of the more common failure points covered in the best practices above, and it ties recovery to a specific storage vendor. Switching storage platforms later means rebuilding that replication layer from scratch.
This is where a storage-independent replication tool like i2Availability can serve as an alternative underlying layer for SRM’s orchestration workflow.
Note that i2Availability’s own failover mechanism, heartbeat detection and automatic switching between a primary and standby server, is built for continuous per-application or per-database high availability.
That’s a different use case from SRM, which orchestrates planned, site-level recovery across many VMs rather than detecting failures and switching automatically. The overlap with SRM is specifically at the replication layer.
For teams also handling continuous data protection or database-specific replication needs, i2CDP and i2Stream address adjacent scenarios: continuous point-in-time protection and database/big data replication, respectively. The storage-independence angle above is what connects most directly to SRM’s architecture.
If SRA compatibility or replication granularity is a recurring constraint in your environment, a storage-independent replication layer like i2Availability is worth evaluating for that specific piece of your architecture.
Q1: Is VMware SRM still called that?
Broadcom has officially rebranded the product as VMware Live Site Recovery (VLSR), sold under the VMware Live Recovery portfolio.
But “SRM” has been the industry-standard name for over a decade, so most admins, storage partners, and documentation still call it SRM.
Q2: Do I need vCenter at both sites?
Yes. SRM uses a two-vCenter architecture. Each site, protected and recovery, needs its own vCenter Server and recovery appliance.
These two vCenter instances stay paired to sync metadata, resource mappings, and configuration details.
Q3: Can VMware SRM do failback?
Yes, through a process called reprotect. Once the primary site is restored and healthy, you run reprotect from within the recovery plan.
This reverses the replication direction, syncs changes back to the primary site, and then boots the workloads back at their original location.
Q4: Is VMware SRM free with vSphere?
No. It’s a separate product with its own subscription or license, typically sold per-VM or as part of a larger VMware SDDC bundle.
SRM handles the orchestration, not the replication. Understanding that distinction makes the rest of its architecture easier to reason about, from protection groups down to how a recovery plan actually executes during failover.
The best practices covered here, from priority groups to SRA compatibility checks, come down to one thing: making sure the orchestration layer and the replication layer underneath it are configured to work together reliably.
If SRA compatibility or replication granularity keeps showing up as a limitation in your environment, a storage-independent replication layer like Info2soft’s i2Availability is worth evaluating for that piece of the architecture.
