Migrating an infrastructure to a new vDC

Step 1.2 Select your hosts (compute)

You have now chosen your commercial range.

Please note that this choice is not definitive, you can start with 2 hosts of 96GB RAM and switch to 3 hosts of 192GB RAM.

Step 1.3 Select your datastores (storage)

You have now chosen your commercial range and your hosts. Please note that some of your actual datastores might be compatible with the newer ranges, that is to say those datastores can be made global. A global datastore is a datastore mounted on all clusters / virtual datacenters within a VMware infrastructure, i.e. shared between the source vDC and the destination vDC. Run the OVHcloud API to check datastores compatibility:

Expected return: boolean

If the API return is TRUE, this datastore is compatible with the newer ranges and you can keep this datastore, you will make it global later on in the upgrade process. If the API return is FALSE, this datastore is not compatible, you will need to order new datastores, VMware On OVHcloud datastores.
Based on your needs in terms of storage capacity, you can select which type and how many datastores you would order.

You only need to replace the datastores that are not compatible. You will be able to release the datastores that are not compatible after you upgrade your storage.

Please note that this choice is not definitive, you can start with 4x3TB and switch to 2x6TB later on.

Step 2.2 Add new hosts and Datastores

In the OVHcloud Control Panel, you will see your new vDC attached to your existing service. You can proceed with ordering new hosts and datastores (selected in step 1) in the new Destination vDC following this Information about Hosted Private Cloud billing guide.

Step 2.3 Convert a datastore to a global datastore

You now have new datastores in the new virtual Datacenter, as well as compatible datastores in the previous datacenter. You can convert those datastores to global

Run the OVHcloud API to convert the datastore to global:

Expected return: Task information

Step 3.2 Assign users rights

In the lifecycle of the source vDC, a list of users may have been created for business or organisational needs. These users will also be present on the new vDC but will have no permissions on this new vDC. You must therefore assign the users the appropriate rights, depending on the configuration of the destination 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.

Step 3.3 Activate Veeam Managed Backup & Zerto Disaster Recovery Options

This options are enabled and configured per vDC. You need to enable the relevant option on the new vDC.

Step 3.4 Check your network (vRack, Public IP)

Step 3.4.1 vRack

As part of a migration process, by default, the new vDC will be linked to the same vRack as the source vDC. Please consult our guide to Using Private Cloud within a vRack.

Step 3.4.2 Public network

The Public IP addresses attached to the source vDC will automatically be available for use in the destination vDC.

Step 4.2 Reconfigure VMware Distributed Resource Scheduler (DRS)

Setting up a new vDC 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.

Step 4.3 Rebuild resource pools

Setting up a new vDC 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.

Step 4.4 Recreate Datastores Clusters (if relevant)

If datastore clusters are present in the source vDC, setting up a new vDC 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

Step 4.5 Enable vSAN (if relevant)

If vSAN was enabled on your source VDC, you will need to enable it again on the destination vDC. Please refer to our guide on Using VMware Hyperconvergence with vSAN.

Step 4.6 Recreate vSphere networking

Setting up a new vDC 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 VDC, 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 Hosted Private Cloud within a vRack.

Here is a checklist of aspects to take into account:

• Portgroup VLAN type
• Security settings (Important in case promiscuous mode is needed)
• Teaming and Failover settings
• Customer network resource allocation

For more information, consult OVHcloud's guide How to create a V(x)LAN within a vRack and VMware's documentation on how to edit general distributed port group settings.

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.

Step 4.7 Check inventory organisation (if relevant)

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.

Step 4.8 Migrate NSX-V to NSX (if applicable)

As part of an NSX-V to NSX-T migration, several NSX-V services need to be migrated to NSX-T. If you are using any of the services listed below, here is a step-by-step guide on how to migrate them.

As a first step, please read our documentation on getting started with NSX.

Step 4.8.1 NSX Distributed Firewall

However, it is crucial to understand that objects placed in the Distributed Firewall will correspond to the significant object ID locally. For example, if a vRack VLAN port group is used in a rule in the Distributed Firewall, it will reference the port group from the original vDC only, not from a recreated vRack port group in the destination vDC.

It will be necessary to verify if the Distributed Firewall contains significant local objects and modify the Distributed Firewall so that it can also see the objects in the new vDC. For example, a rule that uses a vRack VLAN port group from the original vDC can be modified to use both the original vRack VLAN port group and the new vRack VLAN port group in the destination vDC.

The objects to be considered are:

• Clusters
• Datacenters
• Distributed Port Groups
• Legacy Port Groups
• Resource Pool
• vApp

For more information, read our documentation on Managing the distributed firewall in NSX.

Step 4.8.2 NSX Distributed Logical Router

The NSX-V Distributed Logical Router does not have a direct equivalent in NSX. To migrate the Distributed Logical Router, routing should be directly done in the T1 Gateways.

Step 4.8.3 NSX Edges

Generally, depending on the number of edges deployed via NSX-V in the source vDC, you should create T1 Gateways in the NSX of the destination vDC. However, it might be beneficial to step back and review the implemented network architecture to better align with the requirements of the new NSX product.

Additionally, if your production requires zero service interruption, solutions can be implemented to avoid these disruptions.

In both cases mentioned above, our Professional Services team can assist you in this process.

Step 4.8.3.1 Create T1 and segments

To create T1 Gateways, follow our documentation on Adding a New Tier-1 Gateway. This documentation also guides you on how to create segments. Before creating segments, it is necessary to inventory the VXLANs used in the source vDC and create a segment for each VXLAN used in your infrastructure.

Afterwards, you can connect them to the provided T0 in NSX.

For more information, read our documentation on segment management in NSX.

It is also possible to create VLAN-type segments and connect them to vRack via the ovh-tz-vrack Transport Zone. Then, either at the T1 level or at the T0 level with Service-type interfaces, VLAN segments should be positioned to establish connectivity with vRack via NSX.

Step 4.8.3.2 DHCP

To recreate DHCP and associate them with your segments and T1 Gateways, refer to our guide on configuring DHCP in NSX.

Step 4.8.3.3 DNS

To recreate DNS and associate them with your T1 Gateways, please refer to our guide on configuring the DNS forwarder in NSX.

Step 4.8.3.4 NAT Rules

To recreate your NAT rules and associate them with the T1 Gateways, please refer to our guide on Setting up NAT for port redirections with NSX.

Step 4.8.3.5 NSX Load Balancing

To recreate your Load Balancers, follow the instructions in our guide on configuring Load Balancing in NSX.

Step 4.8.3.6 T0 T1 Gateway Firewall

To recreate the firewall rules associated with your previous edges, please refer to our guide on Gateway Firewall Management in NSX.

Step 4.8.3.7 VPN

Step 4.8.3.7.1 IPSec

To recreate your IPSec sessions, please refer to our guide on setting up an IPsec Tunnel with NSX.

Step 4.8.3.7.2 SSL VPN

If you are using SSL VPN functionality, unfortunately, this feature no longer exists in NSX. However, there are open-source alternatives available, such as OpenVPN, OpenConnect VPN, WireGuard, etc. These network appliances need to be deployed on dedicated VMs hosted in your HPC. Each client needs to be installed on the employees' workstations to regain access to their VPN.

Step 4.8.3.8 Reconfiguration of the Initial IP Block

For this step, you will need two elements:

• The IP block initially associated with the NSX-V vDC.
• The public IP of the VIP associated with the NSX-T0 (visible in Networking => Tier-0 Gateways => ovh-T0-XXXX => expand => HA VIP Configuration => click on 1 => IP Address / Mask section)

Next, in the OVHcloud Control Panel, follow the instructions in our Move an Additional IP guide to move the initial NSX-V block to the PCC service you are migrating, but specify the VIP IP of the T0 as the "next hop", as shown in the example below:

Step 4.9 Extend Zerto Disaster Recovery Protection (if relevant)

The Zerto Replication is configured at the vDC level. To protect workload on the new vDC, you need to do some actions.

Prerequisites:

• Having a new vDC
• Having under the new vDC a host cluster with the required number of hosts (same as the source cluster with a minimum of 2 hosts)
• Having under the new vDC a datastore that can be accessible from the two (2) hosts
• Having enabled Zerto Replication on the new vDC

Run the OVHcloud API to prepare the migration:

{datacenterId} is the new vDC id, you can get it with the following API call:

A task is launched on the infrastructure to deploy vRA on each of the hosts of the new vDC.

After this, the Zerto Replication will work on both datacenters:

• The old one is still running and protects your workload.
• The new one is ready to host your workload.

The next step depends on the current configuration per Virtual Protection Group:

• Source of replication
• Destination of replication

Step 4.9.1 VPG as Source

With the migration on the new vDC, Zerto will continue to protect workload with vRA deployed on the target cluster and hosts.

Step 4.9.2 VPG as Destination

Unfortunately, there is no way to update VPG configuration, the only option is to delete the VPG and create a new one.

Step 5.2 vMotion

Since both source and destination vDC are within the same vCenter, hot or cold VMware vMotion can be used to migrate VMs.

Hot vMotion can be used when the CPU chipset is the same between source and destination (eg Intel to Intel).

Cold vMotion can be used when the CPU chipset is different between source and destination (eg AMD to Intel).

Here is a checklist of aspects to take into account:

• ESXi host CPU chipsets on source and destination vDCs
• EVC modes on source and destination Clusters
• vDS versions are the same between source and destination vDC. You can upgrade the vDS vRACK in the source vDC. For the vDS with VM Network (VXLAN vDS), please contact the support so that the vDS can be upgraded.

Step 6.2 Reconfigure Zerto Disaster Recovery (if relevant)

Run the OVHcloud API to finalize the migration:

{datacenterId} is the new vDC id, you can get it with the following API call:

A task is launched to:

• Check if no destination VPG still exists on the datacenter: they MUST be removed.
• Switch the Zerto Replication option (subscription) from the old to the new vDC.
• Remove all vRA from hosts on the old vDC.

Step 6.3 Recreate Affinity rules

Affinity rules are based on VM objects so rules can only be created after VMs have been migrated to the destination vDC. Once the migration is completed, affinity rules can be re-applied on the destination vDC.

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

Step 6.4 Reconfigure the Private Gateway (if relevant)

To "move" Private Gateway to destination vDC, you must first disable it by following the steps in Disable the private gateway.

Then enable it again by following the steps in Enable the private gateway and choose the datacentreId of the new vDC.

Step 6.5 Put hosts in maintenance mode

You must put hosts in maintenance mode by following these steps:

1. In the vSphere Client navigate to Hosts and Clusters.
2. Navigate to a Host.
3. Right click the Host.
4. Navigate to Maintenance Mode.
5. Click Enter Maintenance Mode.

Repeat action for each host.

Step 6.6 Remove old datastores

At this step, we can consider there is no longer any data and/or VM on the old vDC, so we can now remove resources.

In the following instructions, {datacenterId} is the old vDC id, you can get it with the following API call:

With the API, get the filer (datastore) ID list:

Then for each id:

For global datastores, you can use the following API call:

A task is created for each call, you can follow the progress with:

Step 6.7 Remove old hosts

In the following instructions, {datacenterId} is the old vDC id, you can get it with the following API call:

With the API, get the host id list:

Then for each id:

A task is created for each call, you can follow the progress with:

Step 6.8 Remove vDC

In the following instructions, {datacenterId} is the old vDC id, you can get it with the following API call:

With the API, ask for the vDC deletion: