9.8 Migrate Replication services from vSphere to vCloud Director
With vCloud Director support in Veeam Cloud Connect 9.5 Update 4, service providers may want to migrate their Replication services from vSphere to vCloud Director. There's no need to restart replicas from scratch, instead this procedure shows how to easily move tenants between the two virtualization platforms.
A tenant is consuming a vSphere Hardware Plan:
8.xx: Existing vSphere Hardware plan
and has two virtual machines successfully replicating to it:
8.xx: Virtual machines in the Hardware Plan
To migrate the tenant from vSphere to vCloud Director, both the tenant and the service provider work together to complete the migration, and both need to use Veeam Backup & Replication 9.5 Update 4.
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
Tenant deletes the replication job(s) pointing to the vSphere Hardware Plan:
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 vCloud Director account:
Step 2: Provider migrates the virtual machines
Provider prepares the vCloud 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:
In this example, the tenant vcc-tenant2 has already a production vDC. A new vDC named "Tenant2_vdc_DR" has been created.
Provider creates a new tenant in Veeam Cloud Connect mapped on the Organization vcc-tenant2 and using the vDC Tenant2_vdc_DR as the replication target:
Provider opens the Tenant account into vCloud Director, and from the My Cloud view of the selected Organization creates a new empty vApp. This allows for a vApp name that is not related to the VM name, as it would happen by importing a VM directly. Every other parameter is skipped:
Provider opens the newly created vApp and in the Virtual Machines tab selects the Import from vSphere... button:
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.
The import is usually completed in a few seconds, and the VMs appear to be now part of the vCloud Director vApp:
Step 3: Tenant Replica with Seeding
Tenant connects to Cloud Connect using the vCloud Director credentials and verifies that the vDC is correctly listed under his resouces:
Tenant creates a new Replication job using vCloud Director as a target. It's mandatory to select both enable replica seeding and enable network remapping:
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. In the Network Mapping step, tenant configures the mapping between the local and the remote networks:
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:
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:
After the first run of the Replication job will be completed, replica will proceed as before creating incremental restore points inside vCloud Director.