8.6 Migrate Replication services from vSphere to Cloud Director

Cloud Director support has been first introduced in Veeam Cloud Connect 9.5 Update 4. Since then, service providers can freely choose to use vSphere or Cloud Director as the preferred replication target, even at the same time.

There are scenarios where a service provider started to offer DRaaS over vSphere, and may want later to migrate their Replication services from vSphere to Cloud Director. This procedure shows how to move tenants between the two virtualization platforms.

A tenant is consuming a vSphere Hardware Plan:

Existing vSphere Hardware plan

and has two virtual machines successfully replicating to it:

Virtual machines in the Hardware Plan

To migrate the tenant from vSphere to Cloud Director, both the tenant and the service provider work together to complete the migration, and both need to use the latest version of Veeam Backup & Replication.

IMPORTANT: the existing snapshot chain will be removed during the first replication cycle after the migration. The chain will be recreated upon further replication cycles.

Step 1: tenant removes vSphere Replication

  1. Tenant deletes the replication job(s) pointing to the vSphere Hardware Plan:

delete replication jobs

  1. Tenant removes the Service Provider from the backup infrastructure, since the authentication is not going to use anymore a Standalone account but it will use a Cloud Director account:

delete service provider

Step 2: Provider migrates the virtual machines

  1. Provider prepares the Cloud Virtual Datacenter (vDC) to host the replicated virtual machines. This can be a vDC already used for virtual machines running at the service provider, or a new vDC specifically created for the replication services:

prepare a Organization vDC

In this example, the tenant tenant1 receives a new vDC named “Tenant 1 - DR vDC”.

  1. Provider creates a new tenant in Veeam Cloud Connect mapped on the Organization Tenant1 and using the vDC Tenant 1 - DR vDC as the replication target:

Map the Organization vDC in Cloud Connect

  1. Provider opens the Tenant account into Cloud Director, and creates a new empty vApp. This vApp is convenient to be used as a container for all the replicated VM:

Create a new empty vApp

  1. Provider opens the newly created vApp and in the Virtual Machines tab selects the action Import from vCenter:

Import VMs into the vApp

Here, one by one the VMs are selected, and for each one the new name is configured, following the original name to make things easier for the tenant. Remember to select Move VM to avoid unnecessary IO on the underlying storage.

Import VMs into the vApp

The import is usually completed in a few seconds, and the VMs appear to be now part of the vCloud Director vApp:

VMs into the vApp

Step 3: Tenant Replica with Seeding

  1. Tenant connects to Cloud Connect using the vCloud Director credentials and verifies that the vDC is correctly listed under his resouces:

vDC is avalable via Cloud Connect

  1. Tenant creates a new Replication job using vCloud Director as a target. It’s mandatory to select both Replica seeding and Network remapping:

New vCloud Replication Job

  1. Tenant selects the same VM as the previous replication job, chooses the available Organizaion vDC as the target, the vApp created by the Service Provider during the import operation, and the storage policy:

New vCloud Replication Job

  1. Tenant configures in the Network Mapping step the mapping between the local and the remote network:

Network Mapping

  1. In the Seeding step, Tenant edit the seeding option of the VM and selects the available copy of the same VM that has been auto-imported:

Replica Seeding

  1. Tenant completes the wizard and starts the first replica. In the details of the job, tenant will observe that the system will calculate the digest of the existing VM blocks in order to use it as a seed for the new replica:

First replica after the migration with Digest calculation

After the first run of the Replication job will be completed, replica will proceed as before creating incremental restore points inside Cloud Director.