DR Plan Configuration

With DR plans, you need to perform several configurations that direct the plan where to move protected data to from the protected sites when the plan is run.

Specifically, your plan needs to define where protected resources will be moved to on the recovery site: protection groups, VMs, files, vCenter(s), all vCenter folders, compute resources, virtual networks, and IP addresses (individual or ranges). In addition, you will need to configure the Test Site operating environment for failover exercises.

Recovery Site Selection

A DR plan’s meaning is determined by the recovery site defined in the plan; that is, by the target where you want a protected site to recover.

The failover target for a DR plan is an SDDC deployed on VMware Cloud on AWS. Snapshots are replicated to the SCFS in the same AWS region as the recovery SDDC. The backups are made instantly available to a VMware Cloud on AWS SDDC resulting in instant VM power-on, once the SDDC is available and configured.

Backups are replicated to the SCFS in the same region and availability zone as the deployed SDDC.

Protected Site Selection

The Protected Site drop-down menu displays a set of sites known to VMware Cloud Disaster Recovery that are protected by a DR plan. The protected site has live VM workloads organized into protection groups. These protection groups are in the live state and replicate snapshots the SCFS in accordance with a configured replication schedule.

The on-premises recovery site drop-down menu presents a set of options for the recovery site for the chosen DR plan type. The failover process will use this site as a target, and VMware Cloud Disaster Recovery will restart protected workloads on this site.

Advanced options allow you to configure additional backup sites and to select a site for DR plan testing.

In the Site page, you define which protected site you want this to failover using this DR plan. In some cases, you may have multiple protected sites.

Also in the Site page of the Plan wizard, you can choose if you want to run DR test plans directly on the SDDC. This is highly recommended but keep in mind that an SDDC accrues costs while running.

If you are testing a plan, a test failover normally runs on a recovery site. For more about test sites, see Test Failover.

Protection Group Selection

By default, the Protection Groups page displays a list of protection groups on the protected site that have scheduled replication to the backup site, identified in the previous Sites step of the plan wizard.

Before a plan can be configured and run, you must have created protection groups with scheduled replication to the SCFS, so that when the failover occurs, the plan can use snapshots of replicated VMs to restore on the target site. When you run the plan, you can choose the snapshot to use for failover.

In the Groups page of the DR Plan wizard, you select the protection groups you want to include for failover. These selections ensure that the plan has sufficient information to recover all VMs and files covered by the selected protection groups. The plan will use snapshots of these protection groups for failover when you run the plan. Protection group selection affects a set of automatic compliance checks run for this plan.

A warning will be displayed If the selected protection groups do not have scheduled replication configured for the backup site.

Note: Protection groups that you add to a plan can only originate from the same protected site.

Datastore Mapping

When performing a failover to VMware Cloud on AWS, datastore mappings are established automatically. The VMware cloud recovery site has a single datastore making datastore mappings unnecessary.

Note: All VMs that are recovered are located at the root storage folder of the "WorkloadDatastore/" directory after the failover operation.

Datastore mappings for protected sites

To protect your VMs, you can map many source datastores on the protected sites to a single datastore on the recovery site. During failover, if a VM still exists on the source protected site during failback, the failback will use its current datastore and storage folder location.

However, if a VM no longer exists on the protected site, then the failover operation will use that VM's last known datastore and storage folder for the failover. If for some reason the last known datastore does not exist anymore, you must manually set the default datastore in the failover plan before you can run the failback plan. For example, before you run the failback plan, the Failback datastores mappings must be set:

DR plan failback datastore mapping

vCenter Mapping

Mapping vCenters in a DR plan consists of selecting source vCenters that are registered to the protected site. All source vCenters that contain VMs and that are protected by the selected group(s) can be mapped to a target vCenter on VMware Cloud on AWS as the selected recovery site.

Choosing a target vCenter for a Failover SDDC is simple; each SDDC contains a single vCenter instance. For VMware Cloud Disaster Recovery, keep in mind that a protected site can have multiple registered vCenters, but you can only map one vCenter on VMware Cloud on AWS per-DR plan.

Every valid vCenter mapping will create a vCenter mapping for the following three elements:

  • vCenter folders
  • Compute resources
  • Virtual networks

Failover Mapping and Test Mapping Tab Behavior

If the test site is deactivated, the Test mapping tab will not appear.

A mappings table with the current selected mappings will appear for every valid vCenter mapping. If there are existing mappings that are no longer valid, caused by changes in the Sites or vCenters step selections, those mappings will also appear in a table.

Invalid mappings appear in red text. A description of the error can be viewed by moving your mouse pointer over the invalid path and viewing the message in the tooltip.

Mappings can be deleted by clicking the X to the right of each mapping entry. New entries can be added by clicking the Map [vCenter object] button, which will open up a new dialog.

vCenter Folders Object Inventory Mapping

This page of the plan wizard displays a subset of the vCenter object inventory for both the source and target vCenters. Source vCenter object nodes that are detected to contain protected VMs are required to be mapped and are displayed in the UI with blue text. All other mappings are optional.

To add a mapping, select the source vCenter node and the corresponding target vCenter node indicating where the source VMs should be recovered. Then, click Add. Complete this step for each mapping, and then click OK when finished.

Note: If your VMs on the protected vSphere site have tags associated with them, make sure that the same sets of tags and tag categories also exist on the target site of the plan (the Recovery SDDC).

Tip: Avoid having other VMs in target folders because name conflicts can arise when registering VMs with vCenter.

vCenter Folders

Mappable vCenter objects:

  • Data center
  • Folder

Compute Resources

Mappable vCenter objects:

  • Clusters. If the Cluster contains VMs, its icon is highlighted in light blue font to indicate that mapping for this item is required. (This color scheme applies to all mappings.)
  • Resource pool
  • Standalone host (not in a cluster). Note that a standalone host can only be mapped to another standalone host.

Note: Regarding vCenter cluster names, "Cluster-1-<clusterIndex>" represents the name of the initial cluster when the SDDC was first created.

If the SDDC that your clusters belong to is deleted, then any plans with mappings to clusters on that SDDC will display the target cluster names with an asterisk. For example:  "Cluster-*-<clusterIndex>".

Additionally, plan compliance reports will indicate an error when clusters are mapped to a deleted SDDC, or if there is a mapping to a deleted cluster.

Virtual Networks

Mappable vCenter objects:

  • Virtual network
  • Distributed virtual port group

Multi-vCenter Selection

You can only select one vCenter per plan.

IP Address Mapping

IP mappings determine how a VM’s IP address is assigned when a protected source site is failed over to a target site. When a VM is recovered from one site to another, VMware Cloud Disaster Recovery needs to know which IP addresses will be used for the recovered VMs.

IP address mappings can be configured for VMs installed with Linux or Windows guest OS’s. VMs configured for IP address mapping will display with a target IP, target subnet mask, target gateways, and target DNS servers.

Important: In order to map IP addresses for Windows VMs, the system drive of the VMs must be mapped to c:\. Additionally, the mapped c:\ drive cannot be dynamic volume; it must be a basic disk.

Note: VMware Tools must be installed on the guest OS in order to ensure successful IP address mapping.

Note: Only iPv4 is supported for protection plan IP address mapping. This means that any VMs referenced in a DR plan must be using iPv4, or the IP address mapping will not work.

Individual IP Address Mapping

The following figure illustrates IP address mapping page, which has the following fields:

  • Optional rule description
  • Source and target IP addresses
  • Source and target subnet masks
  • Source and target gateways
  • Source and target DNS servers


Entries for individual IP addresses must be separated either by white spaces or new lines.

Entries for gateways and DNS servers must be separated by white spaces. If multiple IP addresses are specified, they will be matched in the specified order from source to target.

To configure IP address mapping, you must enter:

  • The Rule description field text (optional)
  • Source and target IP addresses
  • Source and target gateways
  • Source and target DNS servers

IP Address Range Mapping

Alternatively, you can configure IP address ranges rather than individual IP addresses. Switching to IP ranges can be done by selecting Range from Range/IP addresses, as shown below:

The IP address mapping page has the following fields: optional rule description, source and target IP range prefixes/bits, source and target subnet masks, source and target gateways, and source and target DNS servers. Entries for gateways and DNS servers must be separated by white spaces.

The Range prefix field provides an IP address within a range of IP addresses to be mapped for both source and target. The available range of IP addresses to be mapped is defined by the Bits field.

The following table describes the available CIDR Prefix values for Bits field:

CIDR Prefix

Dotted Decimal Notation

# Node addresses

# of Traditional Class Networks

/13

255.248.0.0

512K

8 B or 2048 C class

/14

255.252.0.0

256K

4 B or 1024 C class

/15

255.254.0.0

128K

2 B or 512 class

/16

255.255.0.0

64K

1 B or 256 class

/17

255.255.128.0

32K

128 C class

/18

255.255.192.0

16K

64 C class

/19

255.255.224.0

8K

32 C class

/20

255.255.240.0

4K

16 C class

/21

255.255.248.0

2K

8 C class

/22

255.255.252.0

1K

4 C class

/23

255.255.254.0

512

2 C class

/24

255.255.255.0

256

1 C class

/25

255.255.255.128

128

½ C class

/26

255.255.255.192

64

¼ C class

/27

255.255.255.224

32

⅛ C class

For example:

  • Range prefix = 10.116.1.50
  • Bits = /24

This means the available range of IP addresses to be mapped would be 10.116.1.0 through 10.116.1.255.

The Bits (CIDR Prefix) specified can be a smaller range within the defined subnet in your environment. For instance you can define the subnet as follows:

  • [network: 10.116.0.0/20,
  • netmask: 255.255.240.0,
  • gateway: 10.116.0.1,
  • range: 10.116.0.0 - 10.116.15.255]

In this example, providing a bits value of /24 with Range prefix of 10.116.1.0 allows you to provide a smaller range of IP addresses to be mapped within that subnet. The subnet mask value provided is used when the IP addresses are mapped.

Limitations when mapping IP address ranges:

  • You can provide a bits value that is smaller than the subnet mask size (CIDR prefix). For instance, if the subnet is a /20 you can define a CIDR prefix (bits) that provides a smaller IP range (i.e., /21, /22, etc.) for the range mapping.
  • You cannot, however, do the reverse.  If the subnet is a /20 you cannot enter a CIDR prefix (bits) that provides a greater IP range (i.e., /19, /18, etc.) for the range mapping. If attempted, the UI will display an error.

To configure IP address range mapping, enter:

  • Text description (optional)
  • Source (protected site) and target (recovery site) ranges expressed in CIDR notation
  • Source and target subnet masks
  • Source and target gateways
  • Source and target DNS servers

To save the IP mapping configuration, click OK.

Failover Mapping and Test Mapping Behavior

  • If the test site is deactivated, the test tab will not appear
  • If the test site is specified, the Failover mappings and Test mappings tabs can be the same depending on check box selection

Supported IP Address Mapping Combinations

The following IP address mappings are supported from source to target systems in a DR plan:

Note: VMware Cloud Disaster Recovery does not support IPv6 remapping, and IPv6 addresses cannot be entered in the plan wizard.

Mapping

Configuration Support

DHCP

VMware Cloud Disaster Recovery supports DHCP mappings for both Windows and Linux VMs.

Static IP addresses - Linux

VMware Cloud Disaster Recovery supports IP address mapping for Linux VMs, with adapters that have exactly one IPv4 and optionally one link local unicast IPv6. Only IPv4 addresses can be mapped. IPv6 configuration(s) will be preserved. Refer to the Linux-specific IP Mapping section for details.

Static IP addresses - Windows

VMware Cloud Disaster Recovery supports IP address mapping for Windows VMs. Single IPv4 address per network adapter is supported. If present on the interface, IPv6 configuration(s) will be preserved. Refer to the Windows-specific IP Mapping section for details.

Multiple Gateways

VMware Cloud Disaster Recovery supports mapping of multiple gateways per adapter for supported versions of Windows and Linux VMs.

Multiple Adapters

DHCP or Static mappings of IPv4 addresses are supported per adapter for Windows and Linux VMs.

Multiple VM recovery

VMware Cloud Disaster Recovery supports IP address mapping of static and DHCP IPv4 addresses for multiple Linux and Windows VMs. IP address mappings can be specified in the plan wizard as individual IP addresses or IP address ranges.

Mapping rules do not apply to recovered VMs

If IP address mapping rules added to the plan wizard do not match any recovered VMs, remapping is skipped.

OS Compatibility for Static IP Address Mapping

This section describes Linux and Windows OS compatibility for static IP address mapping.

Linux-specific IP address mapping

VMware Cloud Disaster Recovery supports IP address mapping for a VM if all NICs have exactly one IPv4, and optionally one link local unicast IPv6.

Also, since IP address mapping for Linux depends on vSphere guest customization, the source VM machine hostname should meet the naming requirements from vSphere Customization Spec. Otherwise, IP address mapping will be skipped.

Supported Linux versions:

  • CentOS 7.0-1406
  • CentOS 7.3-1611
  • CentOS 7.5-1804
  • RHEL 6 minimal

Windows-Specific IP Address Mapping

VMware Cloud Disaster Recovery supports IP mapping of commonly used Windows versions: 

  • Windows 10
  • Windows 2016
  • Windows 2012 R2

Multiple network adapters per VM are supported. Single IPv4 address  per network interface is supported. If present on the interface, IPv6 configuration(s) will be preserved.

If the network interface has no statically configured IPv4 addresses, no IP mapping will be performed, even if matching IP address is found on the source.

Script VM

The Script VM page of the DR plan wizard provides the ability to add custom scripts that can be run on a dedicated VM during plan execution as a recovery step.

Both Windows (Powershell) and Linux (Python) are supported for the script VM guest OS.

Script VM caveats:

  • Only 1 script VM supported per plan. (But you can have multiple script VMs in your VMware Cloud Disaster Recovery environment).
  • The script VM must have VMware Tools installed.
  • The script VM must be available in the environment before the first step requiring a script call. In other words, the Script VM can be recovered as the first steps of a plan, or already running at the target site.

Note: A script VM configured to run on multiple VMs will be run sequentially on each target VM in the batch. Be aware that depending on the number of VMs targeted by the script VM, this can take extra time and slow the recovery completion process.

Procedure
  1. Choose the Run script VM option.
  2. Enter the VM name on which the script will run and the vCenter where the VM is hosted.
  3. Once you have configured the script VM settings for the plan, you need to decide when the script will launch when the plan is running plan. For more information on configuring a script for a plan, see the DR Plan Configuration section.

Recovery Steps

A plan’s recovery steps dictate what actions the plan will take during a failover, and the specific order in which those will occur when the plan is running. Recovery steps in a plan consist largely of restoring individual VMs or VMs contained in protection group snapshots, and additionally copying and restoring files and vSphere groups to the target recovery site.

Recovery Step Types

Recovery steps also allow you to specify scripts to be run before and/or after a VM is powered on during a failover. You can also configure how you want the running plan to handle errors it encounters during failover, and also require user input on some steps before the plan continues running.

There are four types of plan recovery steps listed in the following table:

Step type

Description

Recover protection groups

Allows you to recover any of the protection groups associated with the plan. This step recovers and promotes each protection group, registers all VMs in a protection group snapshot with vCenter, then customizes and powers on the VMs.

Recover individual VMs

Allows you to recover individual VMs (you can select more than one). This step recovers then promotes each VM, registers each with vCenter, then customizes them and powers them on.

Recover all remaining VMs, files, and groups

Allows you to recover everything else referenced in plan mappings, in addition to any selected protection groups or individual VMs. This step recovers and promotes all remaining protection group and VMs and other files, registers the VMs with vCenter, then customizes and powers them on.

Other actions

This step type allows you to define other steps while the plan is running:

  • Wait. Pause the plan execution for a specified duration of time.
  • Wait for user input. Requires that a user enter text in the running DR plan to confirm a step before the plan can continue executing.
  • Run script. Run a script using the script VM configured for the plan.

Recover Protection Groups

When you select this recovery step type, you can choose multiple protection groups to be recovered:

Recover Individual VMs

When you select this recovery step type, you can choose one or more individual VMs referenced in your plan. In the DR Plan wizard, click Select individual VMs, as shown here:

The Select individual VMs dialog appears. Select VMs on the left and they will be added to the recovery step on the right side of the dialog:


Note: Any VMs that are recovered over are located at the root of the "WorkloadDatastore/" directory after the failover operation has completed.

Power Action

For each of the three recover actions (protection groups, individual VMs, and all remaining VMs), you need to choose a Power action, which determines whether or not you want the recovered VMs to be powered on when the VMs are recovered.

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

  • Power on only VMs that were powered-on when snapshotted
  • Power on all recovered VMs
  • Do not power on VMs.
Protection groups, Snapshots and VM power state

When a snapshot is taken of a protection group, it captures the power state of VMs in the group - On or Off. If the VM is powered on when a snapshot is taken, after failover the VM will be powered on when it is restored. Conversely, If the VM is powered off at the time the snapshot was taken, the VM will be powered off when it is restored.

It is important to be aware that for VMs that are powered off when the snapshot is taken, it will not be possible to power on the VM until after the storage VMotion of that VM to the SDDC completes.

To be sure, 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 DR plan to be On.

Pre-recover and Post-recover Actions

In addition to choosing a Power action for recovered VMs, you can also choose actions what will occur before and after a VM is powered on:

  • Pre-recover action:
  • Run a script in the script VM. This 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

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

To configure script execution, you need to 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 plan execution recovery step. The script action takes an absolute path to the script on the script VM as well as 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:

The Timeout field measured in seconds is the amount of time to wait for this action before returning a failure on timeout. In the example above, if the script takes more than 300 seconds, it will fail.

The script execution action returns an exit code for the script, where a non-zero exit code means failure, and an exit code of 0 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.

Alerts

As a part of DR plan configuration, you can choose to have email notifications sent when specific events related to plan execution occur. You can select which email addresses will be notified and what condition should trigger the email.

For information on how to configure alert email addresses, see Configure Email Alerts.

DR plans support email alerts for the following recovery execution steps as follows:

  • Failover execution status changed
  • Waiting for user input
  • Failover finished
  • Waiting for user commit

DR plans also support email alerts for the following compliance check events:

  • Every compliance check - after every compliance check run
  • Compliance warning - for any compliance check that results in some warning
  • Compliance error - for any compliance check that results in some error
  • Once per week
  • When check results changed - when any individual check result changes