Leave us your email address and be the first to receive a notification when Robin posts a new blog.
Since I put a lot of information into my session, I decided to split the information into 3 smaller blog posts. When the recorded session becomes available, I will update this blog with a direct link.
Information on Host Migration, as discussed in my VMUG session, can be found in these previous NSX V2T migration blog posts:
Okay, so much for the introduction. Let’s get started.
NSX V2T/DFW Migration Intro
The main reason we are talking about the subject of migrating from NSX-V to NSX-T is because NSX-V has been declared End-of-General Support on January 16th 2022. Which is only a few weeks from now. So, if you haven’t considered starting with a migration, read this blog series and start making some plans.
In one of the previous blog posts I already wrote about the 'Distributed Firewall' option, which is one of the Advanced migration modes in the Migration Coordinator. In my VMUG session I showed the 'NSX for vSphere' option, which is also known as the 'Migrate All' option. If you want to know more about the other option available in the NSX-T migration coordinator, check out this documentation.
Before you can start using the NSX-T migration coordinator, there are some necessary preparations. Both NSX-V and vSphere need to be supported. For NSX-T 3.1 the requirements are:
- NSX-V versions 6.4.4, 6.4.5, 6.4.6, 6.4.8 and later are supported
- The version of ESXi used in your NSX-V environment must be supported by NSX-T
- vSphere Distributed Switch versions 6.5.0, 6.6.0 and 7.0 are supported
See the VMware Product Interoperability Matrixes for required versions of vCenter Server and ESXi.
To migrate the Distributed Firewall, the DFW Export version needs to be 1000. In version 3.1 this must be done manually, in version 3.2 this will probably be done by the migration coordinator. The procedure on how to update the export version can be found here.
Of course, the environment should be free of issues, pending reboots or upgrades. And no changes should be done in NSX-V or NSX-T once the import of the configuration has started.
Though before you start the migration, you should already consider things like scripts that run against NSX-V, monitoring NSX and especially knowledge about NSX-T. Because although V and T share a lot, there are some major differences in the way they need to be operated.
If the environment can be migrated to NSX-T the first step should be to perform an Assessment. This can be done in several different ways. The NSX-T migration coordinator documentation already provides a lot of information. But the migration coordinator will also analyse the NSX-V configuration before the migration. Because the information is imported into a new NSX-T manager this can be done as a non-disruptive task. If you haven’t started with considering a V2T migration, at least start by performing an analysis with the migration coordinator to get an estimate of the work that needs to be done before or during the migration.
To use the migration coordinator in an existing environment, the following steps must be taken:
- Install one NSX-T manager and add a license
- Connect a Compute Manager (vCenter)
- (Optionally) Deploy 2 edges and create TEP IP-pool
These are only required if you are using Network Virtualization and use the 'Migrate All' option. The edges must be deployed manually, not thru the GUI.
- Start Migration Coordinator service
A more detailed description on how to import the configuration can be found in the documentation for the migration coordinator or in this blog NSX V2T DFW only migration part one.
Once the configuration is imported and analysed, the migration coordinator shows which configuration can’t be migrated or for which components additional information is required. If you are lucky there are few issues to solve. But if you are not that lucky, the GUI isn’t the easiest way of browsing thru the issues. Check out this blog if you want to export the list to an excel sheet.
In the next blog I’ll go over and give some examples of issues I have found during previous V2T migrations. Thank you for reading and hopefully this was helpful.
Questions, Remarks & Comments
If you have any questions and need more clarification, we are more than happy to dig deeper. Any comments are also appreciated. You can either post it online or send it directly to the author, it’s your choice.