Create a DR service for a VM

Here you can find how you can create a new DR service.

Prerequisites

You are familiar with the Terminology and the following assumptions about the DR scenario:

There is a centralized Service Portal and CMP managing all zones.
Zones are named with single letters, like A, B, and C.
Names of DRE at the a zone follow a policy similar to the one for CMP. For example, DR_A and DR_B.
The Service Portal is integrated with the CMP and the DR engines in all zones. The Service Portal keeps information about the VMs in all zones and the IDs of the corresponding DR services.
The user is called Alice.

Service Portal sends a request to DR_A using the GET /locations method to obtain the available locations - zones that can be used as recovery zones for VMs running in Zone A.
Alice selects a recovery zone and initiates the creation of a DR service by specifying an existing VM, location, and policy.
The Service Portal sends a request to DR_A to create a DR service using the POST /drService method and providing the parameters from the previous step.
- If the VM has an active DR service DR_A returns an error.
- On success, the Service Portal stores the received DR Service identifier as an attribute of the VM.
The Service Portal sends a request with the required parameters (user, VM configuration, Zone, DR service ID) to the CMP to create a stub VM in the recovery Zone B.

The role of the stub VM is to remain stopped until the recovery event (failover) occurs - then it replaces the lost VM. The stub VM is created with the same configuration as the protected VM. It can be created with empty disks. While this step is optional, it helps to reserve the resources in the recovery zone and to reduce the RTO by minimizing the work done by the CMP during the failover when a large number of VMs need to be recovered.