Leave us your email address and be the first to receive a notification when Robin posts a new blog.
The Policy engine, or declarative API, was introduced to allow for a much simpler way of consuming NSX-T. An engineer or administrator can now declare the desired state in one API call and the system will determine which actions need to be taken to reach that desired state. Instead of figuring out the current state and taking detailed steps (multiple API calls) to reach the desired state.
But for customers who were already working with NSX-T in the simplified UI, later called the Manager UI, there was no way to migrate or promote the created objects to the Policy engine. Even customers who started with NSX-T 2.5 and terraform were forced to use the Manager API because Terraform didn’t support the Policy engine when NSX-T 2.5 was released.
During the upgrade from those older versions, customers had to continue to work with the Manager API or re-create the objects from scratch in the Policy API or engine. With NSX-T 3.2 this has finally changed.
Policy vs Manager
As a little background, the Policy engine is like a layer on top of the Manager layer. The Policy engine allows for API calls to declare a desired state using the Patch API. This desired state is created through the Manager layer. So, the objects created with the Policy engine are visible, though read-only, in the Manager layer. Objects created in the Manager layer cannot be viewed or seen in the Policy engine. For more information about the differences see the NSX-T documentation.
With NSX-T 3.-0 the Advanced Networking & Security section became the NSX Manager layer and with each newer version the Manager layer moved more and more to the background. Including the option to hide the button to switch between the Manager and the Policy engine in the GUI. VMware has stated that the Policy engine would be the way forward and that new objects should no longer be created in the Manager engine. This new feature to promote objects to the Policy engine will probably remove all the need to still create objects or work with the Manager layer in NSX-T.
Although this is a great step forwards, not all objects can or need to be promoted from Manager to Policy, because they may be deprecated, are not available in Policy, or they have passthrough APIs. For example: Upgrade, Service Insertion, License management, and Bridge firewall objects.
To be able to promote the object, the migration coordinator service needs to be started. The service can be started with ‘Start Service Migration-coordinator’ from the NSX-T manager command line. Once the migration coordinator service has been started and there are Manager objects present, an orange exclamation mark will appear in the top right corner of the NSX-T GUI.
The objects can be promoted by clicking on the blue link or going to System > Settings > General Settings > Manager Objects Promotions and clicking Start Objects Promotions.
As shown in the screenshot, I have created a few items in the Manager, to demonstrate the promotion to the Policy engine
Especially on the Segments it is clear to see that there are no segments available in the Policy engine.
Errors during promotion
After clicking Continue the objects will be promoted to the Policy engine. As shown in the next screenshot this isn’t always possible in a single go. For the demo I have created a Group based on a Logical Switch or a logical port. Because the Logical switch hasn’t been promoted yet, the Group can’t be created or promoted.
Even though I was able to skip the creation of the group, the group was also used in the firewall rule. So, my only option was to cancel and rollback, which also failed.
Maybe a retry button for the security group would be a good idea, so the creation of the group can be retried after the segment has been created.
When my rollback also failed, I saw that the segments had been created. So, I decided to do a little troubleshooting in my lab environment.
These next steps should not be used in a production environment. I used them to troubleshoot a failed promotion in a lab environment.
Because the Manager Object Promotion is part of the migration service, I decided to logon to the NSX manager, to clear the log folder /var/log/migration-coordinator/mp2policy and restart the promotion. Since my logical segments had already been created and only the Groups with the firewall rules need to be promoted.
After restarting the migration coordinator there were still 4 objects left to promote and I was able to complete the promotion of these objects in the normal way.
All objects can now be found in the Policy layer of NSX-T.
Again, test the promotion in a lab environment or in a separate NSX-T manager before performing this in a production environment and make sure there is a back-up available. The method I used here to continue and finish the promotion is my own trial and error. It’s not based on any recommendation from VMware, so please use it carefully in your own NSX-T environment.
I hope you have enjoyed reading this and please leave a note if you have any questions.
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.