Migrating a PCC to Hosted Private Cloud

Objective

There are two aspects to migrating a PCC infrastructure:

• The Hosted Private Cloud (OVHcloud) context, 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 PCC service.

Requirements

• a Hosted Private Cloud infrastructure
• access to the OVHcloud Control Panel (Private Cloud in the Hosted Private Cloud section)

Instructions

This guide will use the notions of a source PCC and a destination Hosted Private Cloud.

Hosted Private Cloud context

Security

Hosted Private Cloud 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 Hosted Private Cloud as to the source PCC.

Hosted Private Cloud users

In the lifecycle of the source PCC, a list of users may have been created for business or organisational needs. You must therefore create them again on the destination Hosted Private Cloud and assign them the appropriate rights, depending on the configuration of the destination Hosted Private Cloud.

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 Hosted Private Cloud, it will be necessary to recreate the encryption context on the destination Hosted Private Cloud. Please refer to our guide on Enabling Virtual Machine Encryption in order to enable KMS on the destination Hosted Private Cloud.

Certifications

For compliance reasons, PCI DSS and HDS options may have been enabled on the source PCC.

These options must therefore be reactivated on the destination Hosted Private Cloud. To do this, please refer to our guide on activating them.

Network

vRack

As part of a migration process, you can link your PCC services within the same vRack. Please consult our guide to Using Private Cloud within a vRack.

Public network

If the public IP addresses attached to the source PCC are required on the destination Hosted Private Cloud, it will be necessary to transfer them.

Please consult our guide to Migrate an IP block between two Hosted Private Cloud services.

The video below also shows how to migrate an IP block between two Hosted Private Cloud services.

VMware context

Step 1: Preparing your destination Hosted Private Cloud

1.1 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.

1.2 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.

1.3 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 Hosted Private Cloud.

1.4 Datastore Clusters

If datastore clusters are present in the source PCC, migration may involve the need to recreate these Datastore Clusters on the destination Hosted Private Cloud 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

1.5 vSAN

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

1.6 vSphere networking

Migration involves recreating the vRack VLAN-backed portgroups on the destination Hosted Private Cloud to ensure VM network consistency. If vRack VLANs are in use on the source PCC vRack can be used to stretch the L2 domain to the destination Hosted Private Cloud to allow for a more phased migration plan. For more information consult our guide about Using 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 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.

1.7 Veeam backup config

If OVHcloud provided Veeam is currently in use to backup VMs on the source PCC, it will be necessary to recreate the backup configuration for the VMs in the destination Hosted Private Cloud 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.

1.8 Inventory organisation (optional)

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 Hosted Private Cloud.

Automation tips: Powercli cmdlet “Get-Folder” to gather the folder information and cmdlet “New-Folder” to recreate the folder on the destination Hosted Private Cloud.

1.9 NSX

1.9.1 NSX Objects

NSX objects include IP Sets, MAC Sets, Services, Service Groups, Security Groups, Networks, Clusters and Datacenters. These are objects that are used to dynamically group vSphere entities for use in, for example, an NSX Edge firewall rule.

These objects will have locally significant IDs in the source PCC and, when re-created in the destination Hosted Private Cloud, will generate a different ID. Keeping track of these IDs is crucial to automating the migration of Edge firewall rules and distributed firewall rules.

Automation tips: The NSX API guide gives examples on how to get object IDs and how to create them.

Example: Get a "Service Object": GET /api/2.0/services/application/scope/{scopeId}
Example: Create a "Service Object": POST /api/2.0/services/application/{scopeId} (body containing xml configuration of the service object)

1.9.2 NSX Edges

On the destination Hosted Private Cloud, it will be necessary to recreate any NSX edges that are in use on the source PCC. Items to recreate include:

• Edge HA settings
• Interfaces on the destination Edge so that it mirrors the source Edge
• Edge services (Firewall, NAT, IPSEC, etc) on the destination Edge so that it mirrors the source Edge (NOTE: If automating this process, be sure to map any referenced object IDs to object IDs that exist in the destination Hosted Private Cloud)

Automation tips: The NSX API guide gives examples on how to GET Edge configurations and how to add service configurations onto new Edges.

Example: Get an Edge current configuration: GET /api/4.0/edges/{edgeId}
Example: Push a new firewall ruleset to an Edge: PUT /api/4.0/edges/{edgeId}/firewall/config (body containing firewall xml config)

1.9.3 NSX Distributed Firewall

On the destination Hosted Private Cloud, it will be necessary to recreate any Distributed Firewall rules that are in use on the source PCC. Items to recreate include:

• DFW sections on the destination DFW so that it mirrors the source DFW
• DFW rules on the destination DFW so that it mirrors the source DFW (Note: If automating this process, be sure to map any referenced object IDs to object IDs that exist in the destination Hosted Private Cloud)

Automation tips: The NSX API guide gives examples on how to GET the DFW configuration and how to create DFW rules and sections.

Example: Get DFW current configuration: GET /api/4.0/firewall/globalroot-0/config
Example: Create a new Layer 3 section in a DFW: POST /api/4.0/firewall/globalroot-0/config/layer3sections (body containing section xml config)

Step 2: Preparing Veeam for migration

The following elements are required:

• SPLA licences (on source PCC and destination Hosted Private Cloud)
• A Veeam licence
• An IP address available on the source PCC and destination Hosted Private Cloud
• A Veeam Backup & Replication virtual machine on the source PCC
• Authorising the Veeam Backup & Replication virtual machine to connect to the source and destination vCenter

Please refer to our guide on setting up Veeam Backup & Replication.

The video below shows how to configure Hosted Private Cloud with the Veeam Backup & Replication solution.

The following video explains how to replicate your Hosted Private Cloud infrastructure with the Veeam Backup & Replication solution.

You can also refer to the Veeam documentation (PDF).

Step 3: Post migration tasks

3.1 Affinity rules

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

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

3.2 Veeam Backup configuration

OVHcloud provided Veeam backups are configured per VM so can only be re-applied after the migration. Once the migration is completed, VMs can have their Veeam backups re-enabled using the UI or API

Automation tips: OVHcloud API allows VM backups to be enabled for each vm via (body containing the list of backup days, e.g. backupDays='["Friday","Monday","Saturday","Sunday"):

Go further

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