Moving an ALB (AVI) Virtual Service to a different set of Service Engines

[grimsrue]

I wanted to find out if anyone has run into an issue moving an ALB Virtual Service from one set of Service Engines over to a different set of Service Engines from within the "NSX-T UI"? I so have you figured out a fix? If no one has a fix I am going to open a ticket with VMWare so they can send it up the line to Engineering to look into.

The Basic License for AVI (NSX-T ALB) does not allow the option of "Enable Per-app Service Engine Mode". To get around this license issue I decided to build out multiple Service Engine groups and I assign two Virtual Services per SE Group. I have 4 test Virtual Services and tried moving a Virtual Service to on of the other SE Groups from within the NSX-T UI. The Virtual Service successfully moves to the new SE Engine and Load Balancing is still working, but it seems to throw an error in NSX-T UI and tells me the Virtual Service is "Failed" The error I am seeing is "java.lang.NullPointerException"

The only way I can fix the "Failed" error is to delete and created the Virtual Service. That's a bit over the top. When looking at the Virtual Service from the AVI UI there are not issues and the Virtual Service is working as it is suppose to.

[engyak · Accepted solution]

I apologize, you're not going to like this...

I tested the early UI/API integration between NSX DC / NSX ALB as well, and it was not running particularly well (even though it was an API proxy). NullPointerException was a pretty frequent error, and it appears to just mean that the check or test for a given change was not yet created or was a generally unfinished integration.

It's a bummer because implementing not just a proxy but unit testing was actually a pretty neat idea, all things considered.

VMware has already announced its intent to deprecate this feature: https://kb.vmware.com/s/article/87899 

[grimsrue]

Well. Its good to know they finally gave up on trying to integrate AVI into NSX-T at that level. Wish I had seen that KB article earlier. I opened an SR with VMWare Tech Support and they were responding to me asking HOW i was integrating AVI into NSX-T. They generally did not understand what I was talking about. My mind was blown. One less SR I need to keep track of.

I had been testing the NSX-T AVI UI integration for MONTHs in my lab noticing how many problems there were with the API and the UI. It just seem like it was thrown together in a sloppy manner. Frustrating is all I can say.

[engyak]

The link I provided is extremely difficult to find, and it isn't linked in patch notes as a deprecation yet.

This is an example of where leveraging Google is actually less helpful than the internal doc search now - which was how I found this.

FYI - no notes on how to break the NSXT/Avi integration off cleanly yet!

[grimsrue]

The one thing I find interesting about that KB Article is that the last update to it was mid March. That means VMWare decided to deprecate the AVI/NSX-T UI integration  just a few months after releasing it in 3.2.0 and 3.2.0.1. It would be nice if VMWare would have just let everyone know they were deprecated that feature awhile ago. There are probably a lot of people trying to test and work with it not knowing it is going away.

The KB does state they are not going to completely break NSX-T/AVI integration. VMWare is planning to leave the ability to deploy controllers from the NSX-T UI and will leave links in place to redirect to the AVI UI Dashboard. Virtual Services that are created in AVI do not get created in NSX-T UI. I suspect that if anyone has this in prod that they can just recreate the Virtual Services/VIPs, and Pools in the AVI Dashboard and then delete them from the NSX-T UI as needed. Have not tried that yet, but since I am just runniing in lab I'll give it a try.

[engyak]

The data constructs are the same, you could also port it to a new SEGroup via the API.