1. Articles
  2. Hosted Private Cloud
  3. VMware on OVHcloud
  4. Getting Started

Articles in this section

Migrating a PCC to Hosted Private Cloud

Avatar
Stephanie R.
  • Updated

Learn about all aspects of migrating a PCC service to the OVHcloud Hosted Private Cloud.

There are two aspects to migrating a PCC infrastructure:

  1. The Hosted Private Cloud (OVHcloud) context, which includes the customer's side of administrating an infrastructure.
  2. The VMware infrastructure, which includes the entire VMware ecosystem.
Should you choose to migrate an infrastructure to a new vDC instead, please follow this dedicated guide.

 

Requirements

 

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 organizational needs. You must therefore create them again on the destination Hosted Private Cloud and assign them the appropriate rights, depending on the destination Hosted Private Cloud configuration.

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 to enable KMS on the destination Hosted Private Cloud.

 

Certifications

PCI DSS and HIPAA options may have been enabled for compliance reasons on the source PCC.

 

Network

vRack
NOTE: VMnetworks located in the same region cannot be interconnected in a vRack.

You can link your PCC services within the same vRack as part of a migration process. Please consult our guide to using private cloud within a vRack.

 

Public network
NOTE: If your PCC offer pre-dates 2016, please contact our support teams to verify the requirements.

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.

 

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 aspects 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 how to edit distributed port teaming and failover policies.

Automation tips: Powercli cmdlet “Export-VDPortGroup” can retrieve Distributed Virtual Portgroup information which can then be imported into the destination Distributed Switch with the use of the “New-VDPortgroup -BackupPath” cmdlet.
NOTE:
  • Some virtual routing appliances, such as pfSense, use CARP to provide high availability.
  • VMs that use CARP will need “Promiscuous Mode” enabled in the security settings of a portgroup.
  • Customers can enable this setting themselves on the vRack vDS on the destination Hosted Private Cloud.
  • However, if promiscuous mode needs to be enabled on the “VM Network” portgroup in the new Hosted Private Cloud, please open a ticket with OVHcloud support before migration to ensure connectivity remains during migration.

 

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
GET /dedicatedCloud/{serviceName}/datacenter/{datacenterId}/vm/{vmId}
The “backup” section of the returning json will give information on the current backup configuration.

 

1.8 Inventory organisation (optional)

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 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 of 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 of 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 of 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:

Please refer to our guide on setting up Veeam Backup & Replication. 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"):
POST /dedicatedCloud/{serviceName}/datacenter/{datacenterId}/vm/{vmId}/enableBackup

 

Go further

For more information and tutorials, please see our other Hosted Private Cloud support guides or explore the guides for other OVHcloud products and services.

Related articles