Migrating an infrastructure to a new vDC

Objective

There are two aspects to migrating an infrastructure to a new vDC:

• The OVHcloud infrastructure itself which includes the customer's side of administrating an infrastructure.
• The VMware infrastructure, which includes the entire VMware eco-system.

This guide explains how to cover all aspects of migrating a pre-existing OVHcloud infrastructure to a new vDC.

Requirements

• a PCC infrastructure
• access to the OVHcloud Control Panel

Instructions

This guide will utilise the notions of a source infrastructure and a destination vDC.

OVHcloud context

Security

Managed Bare Metal access

For connections to the VMware platform, you can choose to block access to vSphere by default. Please refer to our guide on the vCenter access policy for details.

If the access policy has been changed to "Restricted", you will need to apply the same connection IPs to the destination vDC as to the source infrastructure.

Managed Bare Metal users

In the lifecycle of the source infrastructure, a list of users may have been created for business or organisational needs. You must therefore provide the current users the same rights to the new vDC.

To do this, please refer to our guides on Changing user rights, Changing the User Password and Associating an email with a vSphere user.

Key Management Server (KMS)

If virtual machines are protected by encryption and this is a prerequisite for the destination vDC, it will be necessary to recreate the encryption context on that destination infrastructure. Please refer to our guide on Enabling Virtual Machine Encryption in order to enable KMS on the destination vDC.

Network

vRack

As part of a migration process, you can link your Managed Mare Metal services within the same vRack. Please consult our guide on how to Using Managed Bare Metal within a vRack.

VMware context

Cluster configuration

Configuring VMware HA

The migration involves reconfiguring VMware High Availability (HA), including boot order and priority. Please consult our guide about VMware HA configuration.

Here is a checklist of aspect to take into account:

• Host monitoring settings
• VM monitoring settings
• Admission control
• Advanced HA options
• VM Overrides

Automation tips: Powercli cmdlet “Get-Cluster” returns information on HA and DRS configuration settings that can be applied to the destination cluster with “Set-Cluster” cmdlet.

Configuring VMware DRS

The migration involves reconfiguring the VMware Distributed Resource Scheduler (DRS) feature, in particular the affinity or anti-affinity rules for groups of hosts and VMs. Please consult our guide about configuring VMware DRS.

Here is a checklist of aspects to take into account:

• Automation level
• VM/Hosts Groups
• VM/Host affinity/anti-affinity rules
• VM Overrides

Automation tips: This VMware community thread details options to export and import affinity-rules via powercli.

Resource pools

The migration requires rebuilding resource pools including reservations, shares, and vApps. This also applies to vApps and any start-up order configuration set in the vApps.

For more information, consult VMware's documentation for managing resource pools.

Here is a checklist of aspects to take into account:

• CPU/Memory shares settings
• CPU/Memory reservations
• CPU/Memory expandable option
• CPU/Memory Limits

Automation tips: Powercli cmdlet “Get-ResourcePool” to gather the resource pool information and cmdlet “New-ResourcePool” to recreate the resource pool on the destination vDC.

Datastore Clusters

If datastore clusters are present in the source infrastructure, migration may involve the need to recreate these Datastore Clusters on the destination vDC if the same level of structure and SDRS is needed.

Here is a checklist of aspects to take into account:

• SDRS automation level
• SDRS space, I/O, rule, policy, VM evacuation settings
• SDRS affinity/anti-affinity rules
• SDRS VM Overrides

Networks

Migration involves recreating the vRack VLAN-backed portgroups on the destination vDC to ensure VM network consistency. If vRack VLANs are in use on the source infrastructure vRack can be used to stretch the L2 domain to the destination vDC to allow for a more phased migration plan. For more information consult our guide about Using Managed Bare Metal within a vRack.

Here is a checklist of aspects to take into account:

• Portgroup VLAN type
• Security settings
• Teaming and Failover settings
• Customer network resource allocation

For more information, consult VMware's documentation on how to edit general distributed port group settings and on how to edit distributed port teaming and failover policies.

Automation tips: Powercli cmdlet “Export-VDPortGroup” can retrieve Distibuted Virtual Portgroup information which can then be imported into the destination Distributed Switch with the use of the “New-VDPortgroup -BackupPath” cmdlet.

OVHcloud provided Veeam Backup

If OVHcloud provided Veeam is currently in use to backup VMs on the source infrastructure, it will be necessary to recreate the backup configuration for the VMs in the destination vDC post-migration.

Here is a checklist of aspects to take into account:

• List of VMs being backed up
• Backup settings

Please refer to our guide on activating and using Veeam Managed Backup.

Automation tips: OVHcloud API provides VM backup information attached to each VM via:

The “backup” section of the returning json will give information on current backup configuration.

Inventory organisation

For organisational reasons, the VMs, hosts or datastores may have been placed in directories.

If you still need this organisation, you will need to create it again in the destination vDC.

VM

There are several ways of migrating VMs to a new vDC.

If your source is on Intel hosts, you can vMotion VMs to the new VDC.

If your source is on AMD hosts, power down and use cold migration.

Go further

Join our community of users on https://community.ovh.com/en/.