Leave us your email address and be the first to receive a notification when Robin posts a new blog.
This blog continues where the first blog about this topic has ended - just after importing and checking the configuration from NSX-V. To give a very quick summary:
- Install NSX-T alongside the current NSX-V environment
- Start the migration coordinator
- Import the NSX-V configuration
- Resolve and, if required, adjust the configuration
If you haven’t read the first blog yet, check it out here.
Migrating the configuration to NSX-T
When the configuration has been resolved to a point where it is acceptable to continue with the migration, the next step is to import it into NSX-T. From the ‘resolve configuration’ page click continue to reach the ‘migrate configuration’ page. To create the distributed firewall configuration in NSX-T just click start and then migrate. As shown in the screenshot, objects related to the distributed firewall should not be changed or deleted in NSX-V or NSX-T during the migration.
Once the creation of the distributed firewall objects in NSX-T has been completed, it can be viewed to see how the configuration looks. At this point a rollback can still be performed by pushing the blue ‘rollback’ button next to the ‘start’ button. This will remove the created configuration from NSX-T and the process can be started all over again.
First have a look at what the migration coordinator created, before deciding if a rollback is required.
In the Ethernet Category you can now see two times a default layer 2 rule. The top one was imported by the migration coordinator. All other firewall rules are created in the Application category.
All policies are created here with “::NSX Service Composer – Firewall” add to the name, for which I don’t see the benefit. So, that’s something I will change with a script after the migration has been completed. As said, all policies are created in the application category with no option to move them to another category, other than recreating them. At least not that I have found in the GUI or API guide. Again, a script to read specific policies and create them in another category would work, but this should be run after the migration is complete.
At this stage it is important to check if all policies, firewall rules and objects have been migrated, since a rollback is still possible. The number of created options during the ‘Migrate Configuration’ step should have given a good estimate already. But a double check on the important firewall rules or specific applications can save a lot of pain if something is missing. If required or if something is missing, this is the time to rollback or continue when everything seems to be present.
The next step in the migration process is to prepare the infrastructure. According to the documentation on the VMware site this step enables CDO on the NSX-V environment. But in the environment that I’m migrating, the controllers have not been deployed. Since only the Distributed Firewall functionality is being used, which doesn’t require the NSX-V Controllers. Even though the controllers are a prerequisite, this step does succeed without the controllers present.
The last step in this process is to migrate the ESXi hosts from NSX-V to NSX-T. Before the migration is started the order of the clusters can be changed and it’s possible to pause between the groups (clusters).
So, a cluster with low impact VMs can be done first, before continuing with more important clusters. It should be also possible to disable or exclude clusters, but that hasn’t worked for me during the migrations I have done so far.
Once started, the hosts are placed into maintenance mode one by one. NSX-V is removed from the Host and NSX-T is installed and so on. This looks a lot like the regular NSX upgrade process. NSX-V will start to report some errors since the hosts are no longer prepared for NSX-V. For example: one of the errors shown in recent tasks list is ‘UserVars.RmqHostid’ is invalid.
Which can be expected since the NSX-V environment will start to look like this.
Once all hosts have been migrated from NSX-V to NSX-T the migration is complete.
At this stage all the VMs are migrated to the NSX-T VLAN backed segments on the virtual Distributed Switch and have received the appropriate tags. The next step is to verify that all VMs and the distributed firewall are still working as expected, do some optimalisation and of course to clean-up the NSX-V environment.
But those are topics for another blog post. Thanks for reading and 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.