5.5
Table Of Contents
- Site Recovery Manager Administration
- Contents
- About VMware vCenter Site Recovery Manager Administration
- SRM Privileges, Roles, and Permissions
- Replicating Virtual Machines
- How the Recovery Point Objective Affects Replication Scheduling
- Replicating a Virtual Machine and Enabling Multiple Point in Time Instances
- Configure Replication for a Single Virtual Machine
- Configure Replication for Multiple Virtual Machines
- Replicate Virtual Machines By Using Replication Seeds
- Reconfigure Replications
- Stop Replicating a Virtual Machine
- Creating Protection Groups
- Creating, Testing, and Running Recovery Plans
- Testing a Recovery Plan
- Performing a Planned Migration or Disaster Recovery By Running a Recovery Plan
- Differences Between Testing and Running a Recovery Plan
- How SRM Interacts with DPM and DRS During Recovery
- How SRM Interacts with Storage DRS or Storage vMotion
- How SRM Interacts with vSphere High Availability
- Protecting Microsoft Cluster Server and Fault Tolerant Virtual Machines
- Create, Test, and Run a Recovery Plan
- Export Recovery Plan Steps
- View and Export Recovery Plan History
- Cancel a Test or Recovery
- Delete a Recovery Plan
- Reprotecting Virtual Machines After a Recovery
- Restoring the Pre-Recovery Site Configuration By Performing Failback
- Customizing a Recovery Plan
- Recovery Plan Steps
- Specify the Recovery Priority of a Virtual Machine
- Creating Custom Recovery Steps
- Types of Custom Recovery Steps
- How SRM Handles Custom Recovery Steps
- Create Top-Level Command Steps
- Create Top-Level Message Prompt Steps
- Create Command Steps for Individual Virtual Machines
- Create Message Prompt Steps for Individual Virtual Machines
- Guidelines for Writing Command Steps
- Environment Variables for Command Steps
- Customize the Recovery of an Individual Virtual Machine
- Customizing IP Properties for Virtual Machines
- Advanced SRM Configuration
- Configure Protection for a Virtual Machine or Template
- Configure Resource Mappings for a Virtual Machine
- Specify a Nonreplicated Datastore for Swap Files
- Recovering Virtual Machines Across Multiple Hosts on the Recovery Site
- Resize Virtual Machine Disk Files During Replication Using Replication Seeds
- Resize Virtual Machine Disk Files During Replication Without Using Replication Seeds
- Reconfigure SRM Settings
- Change Local Site Settings
- Change Logging Settings
- Change Recovery Settings
- Change Remote Site Settings
- Change the Timeout for the Creation of Placeholder Virtual Machines
- Change Storage Settings
- Change Storage Provider Settings
- Change vSphere Replication Settings
- Modify Settings to Run Large SRM Environments
- Troubleshooting SRM Administration
- Limitations to Protection and Recovery of Virtual Machines
- SRM Events and Alarms
- vSphere Replication Events and Alarms
- Collecting SRM Log Files
- Access the vSphere Replication Logs
- Resolve SRM Operational Issues
- SRM Doubles the Number of Backslashes in the Command Line When Running Callouts
- Powering on Many Virtual Machines Simultaneously on the Recovery Site Can Lead to Errors
- LVM.enableResignature=1 Remains Set After a SRM Test Failover
- Adding Virtual Machines to a Protection Group Fails with an Unresolved Devices Error
- Configuring Protection fails with Placeholder Creation Error
- Planned Migration Fails Because Host is in an Incorrect State
- Recovery Fails with a Timeout Error During Network Customization for Some Virtual Machines
- Recovery Fails with Unavailable Host and Datastore Error
- Reprotect Fails with a vSphere Replication Timeout Error
- Recovery Plan Times Out While Waiting for VMware Tools
- Reprotect Fails After Restarting vCenter Server
- Rescanning Datastores Fails Because Storage Devices are Not Ready
- Scalability Problems when Replicating Many Virtual Machines with a Short RPO to a Shared VMFS Datastore on ESXi Server 5.0
- Application Quiescing Changes to File System Quiescing During vMotion to an Older Host
- Reconfigure Replication on Virtual Machines with No Datastore Mapping
- Configuring Replication Fails for Virtual Machines with Two Disks on Different Datastores
- vSphere Replication RPO Violations
- vSphere Replication Does Not Start After Moving the Host
- Unexpected vSphere Replication Failure Results in a Generic Error
- Generating Support Bundles Disrupts vSphere Replication Recovery
- Recovery Plan Times Out While Waiting for VMware Tools
- Index
To configure array-based replication, you must assign each virtual machine to a resource pool, folder, and
network that exist at the recovery site. You can specify defaults for these assignments by selecting inventory
mappings. SRM applies inventory mappings when you create the protection group. If you do not specify
inventory mappings, you must configure them individually for each member of the protection group. SRM
does not protect virtual machines that you did not configure or that you incorrectly configured for
replication, even if they reside on a protected datastore.
If your storage array supports consistency groups, SRM is compatible with vSphere Storage DRS and
vSphere Storage vMotion. You can use Storage DRS and Storage vMotion to move virtual machine files
within a consistency group that SRM protects. If your storage array does not support consistency groups,
you cannot use Storage DRS and Storage vMotion in combination with SRM.
n
How SRM Computes Datastore Groups on page 30
SRM determines the composition of a datastore group by the set of virtual machines that have files on
the datastores in the group, and by the devices on which those datastores are stored.
n
Create Array-Based Protection Groups on page 31
You create array-based protection groups to enable the protection of virtual machines in datastore
groups that you configure to use array-based replication.
n
Edit Array-Based Protection Groups on page 32
You can change the name and description of an array-based protection group and add or remove
datastore groups that are part of the protection group.
How SRM Computes Datastore Groups
SRM determines the composition of a datastore group by the set of virtual machines that have files on the
datastores in the group, and by the devices on which those datastores are stored.
When you use array-based replication, each storage array supports a set of replicated datastores. On storage
area network (SAN) arrays that use connection protocols such as Fibre Channel and iSCSI, these datastores
are called logical storage units (LUN) and are composed of one or more physical datastores. On network file
system (NFS) arrays, the replicated datastores are typically referred to as volumes. In every pair of
replicated storage devices, one datastore is the replication source and the other is the replication target. Data
written to the source datastore is replicated to the target datastore on a schedule controlled by the
replication software of the array. When you configure SRM to work with an SRA, the replication source is at
the protected site and the replication target is at the recovery site.
A datastore provides storage for virtual machine files. By hiding the details of physical storage devices,
datastores simplify the allocation of storage capacity and provide a uniform model for meeting the storage
needs of virtual machines. Because any datastore can span multiple devices, SRM must ensure that all
devices backing the datastore are replicated before it can protect the virtual machines that use that datastore.
SRM must ensure that all datastores containing protected virtual machine files are replicated. During a
recovery or test, SRM must handle all such datastores together.
To achieve this goal, SRM aggregates datastores into datastore groups to accommodate virtual machines
that span multiple datastores. SRM regularly checks that datastore groups contain all necessary datastores
to provide protection for the appropriate virtual machines. When necessary, SRM recalculates datastore
groups. For example, this can occur when you add new devices to a virtual machine, and you store those
devices on a datastore that was not previously a part of the datastore group.
A datastore group consists of the smallest set of datastores required to ensure that if any of a virtual
machine's files is stored on a datastore in the group, all of the virtual machine's files are stored on datastores
that are part of the same group. For example, if a virtual machine has disks on two different datastores, then
SRM combines both datastores into a datastore group. SRM also combines devices into datastore groups
according to set criteria.
n
A virtual machine has files on two different datastores.
Site Recovery Manager Administration
30 VMware, Inc.