IP Space Migration in VMware Cloud Director 10.5

The first blog post of this VMware Cloud Director (VCD) 10.5 networking enchantment series covered how the provider can utilize IP Spaces Default NAT and Firewall rules to auto-configure with a “single click” network infrastructure services for the tenants and enable the provider and tenants with a secured and streamlined north-south network provisioning.

VCD 10.5 also introduces a seamless and dependable migration workflow for Provider Gateways utilizing legacy IP Blocks to enchanted IP Spaces address management without causing any data-plane disruption. This feature aims to significantly improve the providers’ operational experience and solve any existing Provider Gateway IP address management transition challenges.

IP Spaces Migration Concepts

When considering a migration scenario, it is important to take into account the two types of IP addresses involved.

The first type is IPs associated with the Provider Gateway, which usually includes Internet and Shared service networks. In this case, the migration procedure requires the provider to define these public and shared services IP Spaces and link them to the Provider Gateway prior to starting the migration wizard. Before performing the actual migration, the workflow checks for any mismatch between the IP Spaces definitions and the existing IP Pools assignment to prevent any possible data-plane disruption. All existing service IPs and routed network prefixes that fall within the associated IP Space’ Internal Scope are transferred into the IP Space domain during the migration.

IP Spaces’ Internal Scopes, IP Ranges, and IP Prefixes sequences may be expanded if the same set of IP Spaces is used to migrate another Provider Gateway.

The second type of migration is related to Private IP Spaces, which don’t necessarily have to be associated with a Provider Gateway. In this case, migration is done for each network and service associated with the IP Space during an edit/save operation if the respective service IP and/or network fall in the Private IP Space Internal Scope. IP Space’s IP Ranges (for service IPs) and IP Prefixes (for networks) definitions are also mandatory for the migration to be successful.

Watch a Demo walk-through

Here is a demo available that showcases IP Space migration scenarios. It includes a step-by-step guide for the migration wizard verifications and resolving discrepancies to provide a smooth transition.


IP Spaces Migration Details

IP Space uplinked to a Provider Gateway

When setting up IP Ranges in the IP Space, it’s essential to ensure that the legacy IP Pools are correctly configured within the IP Space. While it’s recommended to have a one-to-one mapping of Pools to Ranges, it’s not a strict requirement. Single or multiple IP Spaces can be configured to scope the existing IP Blocks definitions properly. In general, if the existing IP Blocks have been defined with respect to the service they are providing, the same pattern can be followed with the IP Space definition, for example: Internet, WAN, Services, etc.

Static IP Pools Requirements

If a specific IP Pool was never allocated to an Edge Gateway, it is optional to be included in the IP Space IP Ranges definition for the migration to work. In the case of an allocation to an Edge Gateway that was never used for Services, the provider can remove this allocation from the Edge and then migrate, excluding the specific IP Pool if desired. However, for the migration to be successful, IP Ranges must include all IPs allocated from the Provider Gateway to attached Edge Gateways. If this is not the case, the migration wizard triggers a violation, and the provider has to fix the related problems before proceeding.

Network Subnets Requirements

To successfully migrate Org VDC networks, it’s essential to establish the IP Prefix sequences in the IP Space beforehand. If a network has an IP subnet logically connected to an IP Space (falls in the Internal Scope), a corresponding IP Prefix has to be created within that IP Space, similar to IP Ranges. Creating multiple IP Prefixes to correspond with the subnets’ definitions may be necessary.

To ensure a smooth migration process, VCD also verifies if the Route Advertisement is active for any network scoped for migration and triggers violation if the route advertisement is not enabled at the IP Space Network Topology.

Private IP Space paradigm

The migration wizard considers only the IP Spaces mapped to the Provider Gateway with IP Space Uplinks. Suppose there are Edge Gateways attached to a Provider Gateway or routed Org VDC networks associated with it, which fall in a Private IP Space’s Internal Scope. In that case, they will not be migrated as part of the Provider Gateway migration. VCD will migrate those service IP addresses or networks whenever an edit/update operation is performed.

Private IP Spaces Migration

VCD providers and tenants can utilize private IP Spaces to cover internal network usage. Using IPs or Prefixes from IP Spaces is not mandatory to configure internal networks and services. Still, it is beneficial if the provider and tenant want to track usage and avoid overlapping services and networks. Providers don’t necessarily need to implement migration workflow to migrate networks or service IPs covered by private IP Space. Instead, VCD updates the allocation and usage information to a matching IP Space on a network or service’s edit/save operation.

VCD auto-allocates any network or service if it hasn’t been already allocated and the quota limit has not been reached. If an IP or Prefix falls outside the defined IP Range or Prefix sequence, VCD will not allow that service or network to be saved and will keep the existing configuration unchanged.


The VCD 10.5 IP Space Migration workflow simplifies the transition from IP Pools to modern IP Spaces, reducing the risk of errors and making it easier for providers to maximize the potential of the VCD networking, therefore providing better service for their tenants.

Remain up-to-date by regularly checking this blog for the latest updates. You can also connect with us on Slack, Facebook, Twitter, and LinkedIn. 

Stay tuned for new demo videos and enablement on YouTube, especially our Feature Fridays series.