Before you run a failback plan, you can configure what actions the plan takes during a failover or failback, and the specific order in which those actions occur when the plan runs.

Recover steps in a plan consist largely of restoring individual VMs or VMs contained in protection group snapshots, and copying and restoring files and vSphere groups to the target recovery site.

When you edit a plan's recovery steps, you specify scripts to run before and/or after a VM is powered on during a failover or failback. You can also configure how you want the running plan to handle errors it encounters during failover and failback operations. You can also require user input on some steps before the plan continues running.

You can also choose to pause the plan and require user confirmation before VMs in the plan are failed back, which allows you to control when the VMs are powered off during recovery.

Configure Failback to Wait for User Confirmation for VM Power-off

To control when VMs in the plan will be shut off, select the 'During failback, wait for user confirmation before powering-off VMs'.

This option allows you to control the time at which VMs in the plan will be shut down. During failback, VMs must be powered off in the recovery SDDC, the last changes are replicated back and the VMs are powered back on, which can take considerable time, depending on the size of VMs being failed back.

When you select this option, the plan pauses after you start the plan and waits for a user to confirm powering off the VMs. Once a user confirms and clicks Continue, the plan starts powering off VMs and begins the process of failing back VM changes to the protected site. You can also add an additional prompt for the user who will confirm powering-off the VMs. This stage of the process can take a substantial amount of time, depending on the size of the VMs.

To configure a failback plan recovery step to wait for user input before powering off VMs:
  1. From the Recovery plans list in the left navigation, select a plan and click the Edit button.
  2. In the Edit plan dialog box, select 'Recovery steps' from the left side.
  3. In the recovery steps page, select the 'During failback, wait for user confirmation before powering off VMs' option.

    Under 'Additional instructions', you can add an option message to the user who will be confirming the VM power-off operation.

  4. To add an email alert when the plan is pause, select Alerts from the left side of the plan, and select 'Plan runtime alerts' then 'Waiting for user input'.
  5. Click Finish. Now when you run the failback plan, the plan will pause and wait for a user to confirm powering-off all VMs in the plan.

Select Power Actions

For each recovery step in a plan, you must select a power action which determines if you want VMs to be powered-on or powered-off after recovery.

A recovery step for protection groups or VMs require one of these three power actions:

  • Power-on only VMs that were powered-on when the snapshot was taken.
  • Power-on all recovered VMs.
  • Do not power on VMs.

Protection Groups, Snapshots, and VM Power State

When a protection group takes a snapshot of its member VMs, it captures the power state of VMs in the group, either on or off. If the VM is powered-on when a snapshot is taken, the VM is powered-on when it is restored.

Conversely, If the VM is powered-off at the time the snapshot was taken, the VM is powered-off when it is restored.

VMs that are powered-off when the snapshot is taken are not able to be powered- on until after the Storage vMotion of that VM to the SDDC completes.

If your VMs must be powered-on and ready for use immediately after recovery, you can override that default behavior when you set the recovery power state in your recovery plan to be on.

Select Pre-recover and Post-recover Actions

In addition to configuring a power action for recovered VMs, you can also select actions that occur before and after a VM is powered on.
  • Pre-recover action:
    • Run a script in the script VM. This pre-recover action requires entering the script path and any custom parameters.
  • Post-recover actions:
    • Wait for VM IP address. Wait for the VM’s IP address to be assigned before moving to the next step in the plan.
    • Wait for VMware Tools. Wait for VMware Tools to launch before continuing to the next step in the plan.
    • Run script in the Script VM. This requires entering the script path and any custom parameters.

Script Configuration for Pre- or Post-Recover Actions

If you select to run a script as a pre-recover or post-recover action, you must configure script settings. This script VM is independent of the VMs that you recover as part of the plan.

To configure script execution, you must identify both the script and the script VM.

  • You can only specify one virtual machine for script execution. The name of this virtual machine must be unique in its vCenter context.
  • You must identify the script by its location on the script VM and by execution requirements. See Recovery steps.

There are two types of script execution:

  • A pre-recover action script runs before powering on a recovered virtual machine.
  • A post-recover action script runs after the recovered VM has been powered on. Post-action scripts can be paused for a certain amount of time to allow IP address configuration on recovered virtual machines, and can be paused to allow VMware Tools installation on recovered virtual machines.

Script Actions

Note: This action runs a script on a VM within the context of a plan execution recovery step. The script action takes an absolute path to the script on the script VM and a list of parameters that you can specify.

For Powershell scripts, only the absolute path to the 'powershell.exe' can be in the script path, and the Powershell script must be set in the parameters.

For example:

Configuring a script actions in a recovery Plan.

The timeout value (measured in seconds) is the amount of time to wait for this action before returning a failure on timeout. You can enter any value for the timeout. (The value of 300 shown in the image above is just an example.)

The script execution action returns an exit code for the script, where a non-zero exit code means failure, and an exit code of zero means success. At the time of recovery execution, you must supply the script VM credentials so that it is possible to run the script in the script VM remotely.

Failback and Rollback Script Actions

Script actions have both a forward (failback) and backward (rollback) execution:

  • If the script was run in the forward direction, a “ --failover” flag is added to the parameters list so the script can distinguish between directions.
  • If the script was run in the reverse direction, a “ --rollback” flag is added to the parameter list.