Leave us your email address and be the first to receive a notification when Robin posts a new blog.
With the End of General support for NSX-V approaching, now is the time to start looking at migrating from V2T. Besides looking at the vSphere version, the migration coordinator is also a good starting point to analyze what can and can’t be migrated directly or automatically to NSX-T. In this blog I will show one of the advanced features of the migration coordinator, the option for migrating the Distributed Firewall Configuration only. This first part will provide an overview of the process and in the next one I will show a migration using this method.
Before you can use the migration coordinator, you need to install an NSX-T manager in the environment and connect it to the vCenter environment to which the NSX-V manager is connected. If you don’t want to do this directly in production, an option can be to restore the vCenter and NSX-V manager in a test environment and do the analysis there. There are some requirements before the migration coordinator can be used, for example the NSX-V version must be at least 6.4.4. A complete list can be found here.
After installing the NSX-T manager and connecting it to the Compute Manager (vCenter), the Migration Coordinator can be started. Because the Migration Coordinator isn’t started by default, you need to start it from the console on a NSX-T manager, by using ‘start service migration-coordinator’.
Once started the migration coordinator can be found under System > Lifecycle Management > Migrate
The advanced migration mode that I’m discussing in this blog can be found by scrolling down:
For this and the next blog I’ll use the ‘Distributed Firewall, Host and Workload’ option on the right. This option can migrate an existing distributed firewall configuration from NSX-V to NSX-T including the hosts and workload. So, all objects like Firewall rules, IP-Sets, Services and Security groups can be migrated. The Network or Guest introspection is not migrated.
After clicking on the ‘Get Started’ button, the first task is to connect to the NSX-V manager and the vCenter server.
Once the NSX-V manager and vCenter server have been connected the existing configuration can be imported.
Importing and translating the existing configuration usually only takes a few minutes. This stage only handles an import of the configuration into the migration coordinator, it does not set or create any configuration in NSX-T yet.
The imported and translated configuration can now be checked for issues or configuration items that cannot be directly imported into NSX-T. The migration coordination will probably show that it can’t convert all Layer-7 Service configuration, since the APP-ids in NSX-V and the context profiles in NSX-T are not 100% the same. Or it can ask for some input regarding the teaming policy it needs to set in NSX-T during the migration.
But in my opinion the main reason you should at least use the migration coordinator once is to see the configuration items that can’t be migrated to NSX-T. One of those configuration items can be a security group based on a vSphere component like the vSphere datacenter or a vSphere cluster, those objects are not available in NSX-T.
In the screenshot you can see that the vSphere Datacenter object is not supported in NSX-T. For microsegmentation purposes the Datacenter object was sometimes used to create an IP-Set of all virtual machines in the vSphere environment. The screenshot already shows a group named Datacenter-NSX-Proof, for which I will show an option to migrate this group and how it can be set for usage after the migration.
So, even if you are not using the migration coordinator to migrate the configuration, it may be very useful to see if there are any non-compliant configuration items in the NSX-V environment that might have been missed.
At this stage the import can be cancelled and the configuration in NSX-V can be adjusted. On this point the migration coordinator also has been improved, because in previous versions some configuration would be left causing errors on future imports. In the current NSX-T 3.1.x versions I didn’t encounter these issues.
In this case the best solution is to change the Datacenter group into a group based on an IP-Set for the addresses in the environment. There are some down sides to this, if there are also physical or bare-metal servers within the range of the IP-Set. Then they are also included, as with the Datacenter object they are excluded. Therefore these should be excluded from the IP-Set.
For this example, I’m changing the group from a group based on a vSphere object.
Into a more static group based on an IP-Set, that will be accepted by the import and translation of the migration coordinator.
Once al the required configuration changes have been made the NSX-V configuration can be imported and translated again, to see if the configuration is now supported by NSX-T.
In the next blog post I will show how the configuration is transferred into NSX-T and what actions are required after the migration. If you have any question or remarks please feel free to contact me or leave your remarks below.
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.