How to delete the protected objects created by VMware PKS in NSX-T via APIs

-

 Hello Everyone,

I was working on a VMware Tanzu Grid environment and later on i need to delete this environment but unfortunately can't delete all the objects in NSX-T which were created by VMware Tanzu Grid on NSX-T during the Tanzu deployments.

VMware Tanzu/PKS and NSX-T is fully integrated with each other and PKS create lots of protected objects like logical-switches, logical-routers,firewall rules,load Balancer, NAT rules etc.. inside NSX-T to make sure that these are not mistakenly deleted by an administrator.

We can not delete these PKS created objects from NSX-T admin GUI as these are protected by a PKS super user.

If you see below screenshot, then i don't have option to delete these logical-switches from GUI. Delete option is not highlighted here.

 

 

 

 

 

Now, the way to delete these protected objects via NSX-T API only.

NSX admin GUI has API documentation and you can check what all API  available there for NSX-T.

Also, you can refer below VMware link for NSX-T APIs as well.

https://code.vmware.com/apis/1030/nsx-t

 

  


 

OK, So how we will interact with NSX-T via APIs. we need a API client tool for this task.

Here, I am using API client tool POSTMAN, it is a very simple and interactive tool. you can download it and install on your local PC or server from where you can reach to NSX-T manager nodes.

 

 

 This tool can be install without creating an account as well.

 

 

If you are using NSX-T manager with self-signed certificates then , you need to disable the SSL certificate verification option on this tool, otherwise it will hit back to you with SSL certificate error while running APIs.

 

           

Let's create a request on POSTMAN and set Authorization to Basic and add NSX-T admin credentials for authentication.

 


 

        

Now, create a header key with name Content-Type, with a value of application/json format which is expected by NSX-T API.


        

 Alright, now we are in postion to start with API calls.

As a testing, we are going to call a GET request to NSX-T and let see what output, we will get from it.

GET https://10.100.26.25/api/v1/node

so, we got 200 OK response from our API call and also got the NSX-T information like product version, node version etc..

 

             

 

Now, this output shows that we have configured the POSTMAN correctly as a NSX-T REST API client.

Let's use PATCH API request to create a logical-switch on NSX-T name as WebTier01.

 

          

Here, our Segment is successfully created under NSX-T.

 

              

 Now, we can go ahead and delete this segment as well via DELETE API call. 


      

We got 200 OK response and this segment is deleted from NSX-T GUI.

So, now we are moving to delete the PKS protected objects from NSX-T via API calls.

I just run a GET API call to get the PKS logical-switch details and if you see below screenshot then it is showing Created User is not Admin and also protection: REQUIRE OVERRIDE. It means Admin user didn't create this and can't delete it as well.

          

Here the solution to delete this protected logical-switch, we need to add a header KEY:X-Allow-Overwrite with VLAUE of True.

Also, if Logical-Switch has any active port connected to Tier-1 router or any Guest Virtual Machine then we need to add a parameter ?detach=true&cascade=true to API command like this 



  Otherwise, we will get below error while deleting the logical-switch which has active ports connected.




Let's run the DELETE API call to delete this logical-switch with additional parameter as stated above. this logical-switch has 5 active logical ports connected as of now, see below screenshot.


  


I run the DELETE API call and it deletes the logical-switch this time, got 200 OK response now.




That's all about this NSX-T API section. You can do anything via API calls which we normally do with GUI portal.


Thanks and Cheers !!!


Comments

Post a Comment

Popular posts from this blog

How to migrate the N-VDS as the host switch to VDS 7.0 in NSX-T 3.x

-
Image
  Hello There, In this article, i am covering how to migrate the ESXi host switch from N-VDS to VDS 7.0 switch in NSX-T 3.2.x version. When using N-VDS as the host switch,  NSX-T  is represented as an opaque network in  vCenter Server . N-VDS owns one or more of the physical interfaces (pNICs) on the transport node, and port configuration is performed from  NSX-T Data Center . You can migrate your host switch to  vSphere  Distributed Switch (VDS) 7.0 for optimal pNIC usage and manage the networking for  NSX-T  hosts from  vCenter Server . When running  NSX-T  on a VDS switch, a segment is represented as an  NSX-T  Distributed Virtual Port Groups. Any changes to the segments on the  NSX-T  network are synchronized in  vCenter Server. We have an NSX-T environment running with NSX-T 3.2.2.1 version. this environment was designed and implemented with NSX-T 2.x version and that time we used the N-VDS as host switch configuration on the transport nodes bcuz VDS was not supported that time. 
Read more

vROPS appliances password remediation tasks failed from SDDC manager

-
Image
Issue details:-   Password remediation tasks on SDDC manager getting failed with below error. However, we are able to connect SSH with root password on the vROPS appliances, no issues with credentials. I checked Operations logs on SDDC manager and found below logs, indicating the SSH connectivity issues from SDDC to vROPS appliances. Tried to do SSH vROPS appliance from SDDC manager, getting below error... Seems some issue with ECDSA key.. Resolution:- SSH to vROPS appliance and retrieve the ECDSA ssh keys as below. Now, we have 2 options to update the correct SSH keys for vROPS appliance on SDDC manager known_Hosts files located at below location.   /root/.ssh/known_hosts   /etc/vmware/vcf/commonsvcs/known_hosts   /home/vcf/.ssh/known_hosts   /opt/vmware/vcf/commonsvcs/defaults/hosts/known_hosts First option is manually copy and paste the SSH key on all the known_hosts files and restart the SDDC manager services and then try to remediate the password again. it will be successful this
Read more

How to Import/Register a VM into vRA portal

-
Image
You can import an unmanaged virtual machine to a vRealize Automation environment. An unmanaged virtual machine exists in a vCenter but is not managed in a vRealize Automation environment and cannot be viewed in the vRA portal . Once you import an unmanaged virtual machine, the virtual machine is managed by using the vRealize Automation management interface. you can see the virtual machine on the Managed Machines tab or the Items tab. Please follow below steps to Import/Register VM into a vRA portal. Log in to vRealize Automation as a fabric administrator and as a business group manager. If you are importing virtual machines that use static IP addresses, prepare a properly configured address pool.  If you use bulk import to import a virtual machine with a static IP address that is allocated to another virtual machine, the import fails. Create a Blueprint and should not have even network attached as well. See below snapin. Create Network profile that shoul
Read more