shank89's Posts

First curl -sku admin:enterpassword -X PATCH 'https://nsxfqdn/policy/api/v1/infra/sites/default/napp/deployment/platform' -H "Content-Type: application/json" -d '{"deployment_action":{"action": "FORC... See more...
First curl -sku admin:enterpassword -X PATCH 'https://nsxfqdn/policy/api/v1/infra/sites/default/napp/deployment/platform' -H "Content-Type: application/json" -d '{"deployment_action":{"action": "FORCE_UNDEPLOY"}}'
In my first response I mentioned how to do it. Run the exact same command but replace the part of the command from upgrade-coordinator with platform.
Looks like you tried to run the remove for upgrade coordinator, try to remove the platform directly.
First curl -sku admin:enterpassword -X PATCH 'https://nsxfqdn/policy/api/v1/infra/sites/default/napp/deployment/upgrade-coordinator' -H "Content-Type: application/json" -d '{"deployment_action":{"act... See more...
First curl -sku admin:enterpassword -X PATCH 'https://nsxfqdn/policy/api/v1/infra/sites/default/napp/deployment/upgrade-coordinator' -H "Content-Type: application/json" -d '{"deployment_action":{"action": "FORCE_UNDEPLOY"}}'   Then the same command but replace upgrade-coordinator with platform. You may only need the second command, you can try with it first, if it complains about upgrade coordinator then you can run the first one.    
A single TEP network, with the Edge nodes on the hypervisors also being enabled for NSX and on the same network; either requires a redesign of the VDS or to configure inter TEP networking. Have a lo... See more...
A single TEP network, with the Edge nodes on the hypervisors also being enabled for NSX and on the same network; either requires a redesign of the VDS or to configure inter TEP networking. Have a look here https://www.lab2prod.com.au/2020/11/nsx-t-inter-tep.html
Pay close attention to the resource requirements here and everything else required for the platform as well. https://docs.vmware.com/en/VMware-NSX/4.1/nsx-application-platform/GUID-85CD2728-8081-45C... See more...
Pay close attention to the resource requirements here and everything else required for the platform as well. https://docs.vmware.com/en/VMware-NSX/4.1/nsx-application-platform/GUID-85CD2728-8081-45CE-9A4A-D72F49779D6A.html
Do any of the nodes have taints for unable to be scheduled? What form factor are you deploying and what resources have you configured ?
Did you create the service account and role binding when creating the non expiring token?
The log file indicates the issue with podsecuritypolicy, which version of tkR are you using exactly ? 
Looks like it, is it a production or supported environment?   I've seen success with mucking around with tkr's to get past this issue or looking into role bindings. GSS might a good place to start.
It's in the proton directory which from memory is car/log/VMware/proton.
Have you checked the napps log yet? Can you please detail your entire IP schema Including what is used for the managers.
What is the network setup, firewalls, MTU, routing issues?   It seems like it may be a networking problem.  How far into the deployment does it get before it fails %? Are the ingress IPs being cre... See more...
What is the network setup, firewalls, MTU, routing issues?   It seems like it may be a networking problem.  How far into the deployment does it get before it fails %? Are the ingress IPs being created? What topology are you deploying NAPP into?
Did you look at the logs for the crashed pods and the napps.log on the manager?   We'll need more information to assist.
Looks like you are using the same subnet for host and edge teps? That's Ok, can be a little more tricky to configure - this article may help. https://www.lab2prod.com.au/2020/11/nsx-t-inter-tep.htm... See more...
Looks like you are using the same subnet for host and edge teps? That's Ok, can be a little more tricky to configure - this article may help. https://www.lab2prod.com.au/2020/11/nsx-t-inter-tep.html You also need to test vmkpings without fragmentation and jumbo frames 'vmkping ++netstack=vxlan -s 1572 -d <destinationTEPIP>.
If your hosts tunnels are not up, that is your main problem. Check tep connectivity using vmkpings from host teps to host teps, and edge teps.   There are some tests here and a video showing these ... See more...
If your hosts tunnels are not up, that is your main problem. Check tep connectivity using vmkpings from host teps to host teps, and edge teps.   There are some tests here and a video showing these tests in this link https://www.lab2prod.com.au/2020/11/nsx-t-inter-tep.html
This is what is supported by the management pack. https://docs.vmware.com/en/Management-Packs-for-vRealize-Operations-Manager/2.3/nsx-t/GUID-41836CBD-CF1C-4526-B82F-DBE70FA950BF.html
Depending on what information you want, vRealize Network Insight or Aria Operations for Networks is a fantastic tool to monitor NSX. It has direct hooks into the application and doesn't rely on API s... See more...
Depending on what information you want, vRealize Network Insight or Aria Operations for Networks is a fantastic tool to monitor NSX. It has direct hooks into the application and doesn't rely on API solely. Extremely complimentary.
Technically with VDS7 and NSX3.X you shouldn't deploy with NVDS, but use the VDS option. Each host supports a single overlay transport zone on a single host switch (VDS for simplicity), but as many ... See more...
Technically with VDS7 and NSX3.X you shouldn't deploy with NVDS, but use the VDS option. Each host supports a single overlay transport zone on a single host switch (VDS for simplicity), but as many vlan transport zones as you want.  If you want additional overlay transport zones, they will need to be on a separate host switch with their own dedicated pnics.  So what you described is possible, as long as you meet these requirements. I believe this answers both your queries.  
Try deploying the standard ova without vCenter, it sounds like it may take additional time in your environment due to lack of resources.