4.1
Table Of Contents
- Site Recovery Manager Administration Guide
- Contents
- About This Book
- Administering VMware vCenter Site Recovery Manager
- Installing and Updating Site Recovery Manager
- Configuring the Protected and Recovery Sites
- Test Recovery, Recovery, and Failback
- Customizing Site Recovery Manager
- Assign Roles and Permissions
- Customizing a Recovery Plan
- Configure Protection for a Virtual Machine or Template
- Configure SRM Alarms
- Working with Advanced Settings
- Avoiding Replication of Paging Files and Other Transient Data
- Troubleshooting SRM
- Index
3 Power on the
virtual machine and verify that VMware Tools reports an OS heartbeat within the specified
period.
4 Run any post-power-on command or message steps.
NOTE Post-power-on command steps provide an application-specific way to verify that a recovered virtual
machine has all the capabilities that you expect. For example, after powering on a recovered database
server, you could execute a simple database query from a script and declare the recovery complete (by
having the script exit with status of 0) only if the script receives the expected response. In the absence of
such additional steps, the virtual machine is considered to have been recovered if it powers on and
connects to the network.
Steps That Are Not Executed During a Test Recovery
When you run a recovery plan, it starts by shutting down protected virtual machine at the protected site.
Machines are shut down in reverse priority order (high-priority machines are shut down last). This step is
omitted when you test a recovery plan.
Cleanup Steps That Are Executed Only During a Test Recovery
Clean up steps are performed after a recovery plan test. The steps begin executing after you have responded
to the prompt displayed after the test completes.
1
Power off each recovered virtual machine.
2
Unregister
the recovered virtual machines from the recovery site vCenter and re-register the placeholders.
3 Clean up replicated storage snapshots that were used by the recovered virtual machines during the test.
Guidelines for Writing Command Steps
When you create a command step to add to a recovery plan, make sure that it takes into account the
environment in which it must run. Errors in a command step affect the integrity of a recovery plan, so test the
command on the recovery site SRM server host before you add it to the plan.
All batch files or commands that you add to a recovery plan must meet the following requirements:
n
You must start the Windows command shell using its full path on the local host. For example, to run a
script located in c:\alarmscript.bat, use the following command line:
c:\windows\system32\cmd.exe /c c:\alarmscript.bat
n
Batch files and commands must be installed locally on the SRM server host at the recovery site.
n
Batch files and commands must complete within 300 seconds. Otherwise, the recovery plan terminates
with an error. To change this limit, see “Change Recovery Site Settings,” on page 60.
n
Batch files or commands that produce output that contains characters with ASCII values greater than 127
must use UTF-8 encoding. Only the final 4KB of script output is captured in log files and recovery history.
Scripts that produce more output can redirect the output to a file rather than sending it to the standard
output to be logged.
Execution Environment for Command Steps
Command steps run with the identity of the LocalSystem account on the SRM server host at the recovery site.
When a command step runs, a number of environment variables are available for it to use. Table 5-1 lists the
environment variables that are available to all command steps.
Site Recovery Manager Administration Guide
50 VMware, Inc.