We are thrilled to announce that the VMware NSX Migration for VMware Cloud Director 1.3 version is now generally available! Closely following the 10.3 version of VMware Cloud Director, which brought several critical networking and security features (routed vApp networks, dynamic security groups, etc.), this 5th iteration of the NSX Migration for Cloud Director brings several key elements:
- Support for shared networks 🥳
- Independent (named) disks
- Fast provisioning support
- DHCP services support on isolated vApp networks
- Distributed firewall with dynamic groups
- Dual-stack (IPv4/IPv6 on the same vNIC) organization VDC network
- DNS forwarder IP address re-configured on target networks
- Additional IPsec encryption algorithms: AES, AES-GCM
- Assessment mode improvements
Another significant improvement concerns the migration workflow itself. The NSX Migration for Cloud Director tool is now modular: instead of going from A to Z during a migration, you now have the opportunity to interact with the workflow by using breakpoints for better control of the overall process.
Let’s dig into some details! 👇
Shared Networks Support
Based on various feedback and the first results of assessments shared with us, we knew that shared network support was the main blocker for many cloud providers.
A shared network is an organization VDC network with a “Share” flag set to true, making it available to other virtual data centers within the same organization; the virtual data centers need of course to have fabric access to the network port groups.
For NSX-T backed organization VDCs, such sharing was not possible up to VMware Cloud Director version 10.2. Version 10.3 has added the ability to share directly connected organization VDC network connected to external VDS port group backed network.
The alternative mechanism for “sharing” organization VDC networks across NSX-T backed organization VDCs is via the consumption of a Data Center Group. Organization VDC networks added to a data center group are accessible to all the organization VDCs participating in the data center group.
Shared networks were not supported for the migration until now: the main reason is that we are migrating organization VDC by organization VDC. We had to rethink the migration process to migrate multiple organization VDCs in a single time.
With the NSX Migration for Cloud Director 1.3 release, when a shared network is present in a virtual data center that is going to be migrated, all organization VDCs that have vApps connected to the shared network must be migrated together (supported maximum is 16 organization VDCs).
The system administrator must provide a list of organization VDCs to migrate together in the YAML user input file (associated with their specific parameters).
The migration tool will create the required data center group(s) and add all organization VDCs migrated together to the relevant data center groups.
Directly connected organization VDC network to an external network used also by other organization VDCs (typically Service Network use case) will not be migrated via the data center group mechanism. Instead, the system administrator must create an identically named external network with the suffix “-v2t” before the migration: this external network must be backed by an NSX-T segment configured with same VLAN as the source external network.
The diagram above shows an example organization with four virtual data centers (A to D). There are two shared networks (Org VDC Network A and Org VDC Network C). You can notice that Org VDCs A, C and D must be migrated together as each of them has a vApp connected to the shared networks.
In the above scenario, the specification file will need to include organization VDCs A, C and D: however, the inclusion of organization VDC B is optional but allowed. The reasoning is that while organization VDC B does not currently have any vApp attached to a shared network, it might in the future, and we want to enable that Org VDC to have access to the shared network. The result post-migration is below.
One more thing: there are situations where shared networks are configured but not used. We have seen multiple situations where that was true: e.g., 2 organization VDCs, but no VMs in the 2nd virtual data center connected to the networks that are shared.
In such context, an easier way to migrate would be to “un-share” the concerned networks and migrate organization VDC by organization VDC.
Note: all shared network migration scenarios are detailed in the User Guide.
Bringing Modularity to the Migration
Until 1.2.1, we had no opportunity to interact with the NSX Migration for Cloud Director tool during a running migration. The 1.3 release introduces modularity into the process with the breakpoint feature, allowing a system administrator to skip or run a specific workflow.
The workflows can be executed in the sequence mentioned below:
- topology – Replication and preparation of target organization VDC(s), edge gateway(s), organization VDC network(s), etc.
- bridging – Automatic L2 bridging configuration between source and target organization VDC networks.
- services – Configuration of networking services (NAT, firewall, etc.) and North-South traffic switch over.
- movevapp – Workload migration (vApps/VMs).
Please note that unless otherwise instructed, the NSX Migration for Cloud Director will execute the migration in a single pass (without skipping a step or running one in particular).
One might wonder what could be the use cases for such a feature? There may be a need for more control of the overall process depending on the migration requirements, the current VMware Cloud Director implementation, or how the tenants consume networking and security services.
Below are a few examples:
- Avoid bridging – For technical reasons, some Cloud Providers may want to avoid L2 bridging.
- Additional verification from your operations team – We received several feedback where the operations team had a requirement to pause the migration to do additional checks.
- Allows the system administrator to skip vApp migration – Workload migration may be difficult (large quantity of data to migrate) or even not possible (related to the vMotion process) in some circumstances. For those situations, you can skip the workload migration workflow and delegate it to an external tool (such as VMware Cloud Director Availability), or even do it manually.
Considerations:
- Even if not specified in an ‘execute’ command, the topology replication (‘topology’) workflow will be mandatorily executed.
- Automated rollback is compatible with the breakpoints.
General Enhancements & Usability
This 1.3 release includes many other new features, but the goal is not to go through all items in this blog post. While some may seem minor, their number and benefits bring a better usability and migration experience.
- Named (a.k.a. Independent) disk migration has been added as a new feature in VMware Cloud Director 10.3. Standalone or connected (but not shared) can now be migrated during an NSX-V to NSX-T migration, starting with the NSX Migration for VCD 1.3 release.
- Fast provisioning support – Fast provisioning saves time by using linked clones for virtual machine provisioning operations.
- DHCP services support on isolated vApp networks
- Assessment mode improvements – As the NSX Migration tool and VMware Cloud Director capabilities evolve, we had obviously to update the tests conducted by the assessment mode as well as the generated report results.
- Distributed firewall with dynamic groups – VMware Cloud Director 10.3 added support for VM security tags and dynamic security groups. NSX-V dynamic security groups are now supported in the migration process.
- Dual-stack (IPv4/IPv6 on same vNIC) Org VDC networks
- DNS forwarder IP address re-configured on target networks – DNS listener IP address will change after the migration. The new IP address will be updated in the concerned organization’s VDC network configuration but will not be applied to already deployed VMs.
- Additional IPsec encryption algorithms: AES, AES-GCM
Summary
Developed by the Cloud Services Business Unit (CSBU), the VMware NSX Migration for VMware Cloud Director is the solution you’re looking for to migrate NSX-V to NSX-T if you are running a VMware Cloud Director environment: it is an external automation tool that initiates and complete the migration process with minimum downtime.
We continue to improve the scenarios and the tooling to help our VMware Cloud Providers Partners to migrate VMware Cloud Director from NSX for vSphere to NSX-T. Whether you haven’t started thinking about the NSX-V to NSX-T migration yet, or are in the planning phase, the assessment mode is a key part of the process. So, don’t be shy, try it! 😉
This migration tool has a different release cycle than VMware Cloud Director, and we already started developing the next version.
You are encouraged to continue providing feedback to help us decide how the tool should evolve. We would love to hear about you, either here in the comments section, in social media (@woueb), or via your VMware representative.
Additional resources:
