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 two hosts of 96GB RAM and switch to three hosts of 192GB RAM.

Step 1.3 Select your datastores (storage)

You have now chosen your commercial range and hosts. Please note that some of your current datastores may be compatible with the newer ranges, meaning that those datastores can be made global. A global datastore is a datastore mounted on all clusters/vDC 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 it. If the API return is FALSE, this datastore is not compatible, you will need to order new datastores, either VMware on OVHcloud datastores.

Based on your needs in terms of storage capacity, you can choose the type and number of datastores to order.

You only need to replace the datastores that are not compatible. You will be able to release the datastores that are not compatible at the end of the process.

Please note that this choice is not final; you can start with 4x3TB and move to 2x6TB later.

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 order new resources (selected in Step 1) in the new destination vDC. You can see billing information for OVHcloud products and services in this guide.

Step 2.3 Convert a datastore to a global datastore

You now have new datastores in the new destination vDC, as well as compatible datastores in your previous vDC. 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 user rights

In the lifecycle of the source vDC, a list of users may have been created for business or organizational 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

These options are enabled and configured per vDC. You need to enable the relevant options on the new vDC; see Step 6.1 (Veeam) or Step 6.2 (Zerto) for instructions.

Step 3.4 Check your network (vRack, Public IP)

Step 3.4.1 vRack

As part of a migration process, the new vDC will (by default) 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 do not automatically route to the new destination vDC. See Step 4.8.3.8 for more details.

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

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 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
• Scalable CPU/Memory option
• CPU/Memory Limits

Step 4.4 Recreate Datastores Clusters (if relevant)

If datastore clusters are present in the source vDC, setting up a new vDC may require recreating 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 your vSphere networking

Setting up a new vDC involves recreating the vRack VLAN-backed port groups 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 on How to create a V(x)LAN within a vRack and VMware's documentation on how to edit general distributed port group settings.

Step 4.7 Check inventory organization (if relevant)

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

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

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

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

The NSX distributed firewall automatically protects the entire vDC. 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 portgroup is used in a rule in the Distributed Firewall, it will reference the portgroup from the original vDC only, not from a recreated vRack portgroup 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 portgroup and the new vRack VLAN portgroup in the destination vDC.

The objects to be considered are:

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

For further information on the Distributed Firewall, refer to our guide Distributed Firewall Management 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 interruptions, solutions can be implemented to avoid these disruptions.

• Step 4.8.3.1 Create the T1 and Segments

  To create T1 Gateways, follow this documentation: 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.

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

  For further information on segments, this documentation can be helpful: 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, please see the DHCP Configuration in NSX guide.

• Step 4.8.3.3 DNS

  To recreate DNS and associate them with your T1 Gateways, see the Configuring DNS Forwarder in NSX guide.

• Step 4.8.3.4 NAT Rules

  To recreate your NAT rules and associate them with your T1 Gateways, see the Configuring NAT Redirection guide.

• Step 4.8.3.5 NSX Load Balancing

  To recreate your Load Balancers, follow the instructions in our Load Balancing Configuration guide.

• Step 4.8.3.6 Firewall for T0 T1 Gateways

  To recreate the firewall rules associated with your previous edges, see our Gateway Firewall Management in NSX guide.

• Step 4.8.3.7 VPN

  • Step 4.8.3.7.1 IPSec

    To recreate your IPsec sessions, here is the documentation: How to Set 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

  NOTE: This step will result in a service interruption as all traffic will be redirected to the T0 VIP (you will no longer be able to use this IP block with VMs on the VM Network portgroup). It is up to you to decide whether you want to point the primary IP block of NSX-V to the NSX-T0 before or after migrating your VMs (see Step 5.2).

  For this step, you will need two elements:

  1. The IP block initially associated with the NSX-V vDC.
  2. 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 How to Move an Additional IP guide to move the initial NSX-V block to the PCC service you are migrating. 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 the workload on the new vDC, you need to take some actions.

Prerequisites:

• Having a new vDC
• In the new vDC, have a host cluster with the required number of hosts (same as the source cluster, with a minimum of 2 hosts)
• In the new vDC, have a datastore that can be accessible from the two (2) hosts
• Having Zerto Replication enabled 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 data centers:

• 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 to the new vDC, Zerto will continue to protect the workload with vRA deployed on the target cluster and hosts.

Step 4.9.2 VPG as Destination

Unfortunately, there is no way to update the 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 (i.e., Intel to Intel).

Cold vMotion can be used when the CPU chipset is different between source and destination (i.e., 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 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 a 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 complete, the affinity rules can be reapplied on the destination vDC.

Step 6.4 Reconfigure the Private Gateway (if relevant)

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

Then enable it again by following the steps in enable the private gateway and choosing the datacenterId of the new vDC.

Step 6.5 Remove the old environment

Preparation

When you are ready to have resources removed, please follow the procedure below.

1. Log into vCenter.
2. Turn off DRS on the old Virtual Datacenter.
3. Turn off NSX-V edges through the NSX-V Networking and Security plugin.
   Verify the NSX-T environment is still working as intended.
   If it is, delete the NSX-V edges from the NSX-V Networking and Security plugin.

4. If you are using OVHcloud managed Veeam, disable it in the OVHcloud Control Panel on the virtual datacenter that is being removed.

   This will remove the backups that are being managed by OVHcloud managed Veeam. Be sure that the backups are either saved elsewhere or that they are not needed and can be deleted.

5. Make note of the hosts and datastores that you want to return to OVHcloud.

6. Put the host into maintenance mode.

   To put a host in maintenance mode:

   • In the vSphere Client navigate to Hosts and Clusters.
   • Navigate to a Host.
   • Right-click the Host.
   • Navigate to Maintenance Mode.
   • Click Enter Maintenance Mode.

   Repeat the action for each host.

Remove datastores

1. Ensure the datastores are empty of all files.
2. Right-click on the datastore and scroll down to OVHcloud.
3. Select Remove this storage....

Allow the process to complete before continuing.

Remove hosts

1. Right-click on a host that is in maintenance mode.
2. Scroll down to OVHcloud.
3. Select Remove this host...

Allow the process to complete before continuing.

Remove vDC

From the OVHcloud Control Panel, remove the old vDC.

Park IP blocks

Park any IP blocks that are no longer being used in the OVHcloud API Console.

1. Click Login in the upper-right corner.
2. Navigate to the POST /ip/{ip}/park API call.
3. Enter the IP block to be parked and click Execute.