VCAP6-NV Deploy - Objective 8.1 - Administer and Execute calls using the VMware NSX vSphere API

VMware NSX-V VCAP6-NV VCIX6-NV HOWTO

Published on 30 July 2017 by Christopher Lewis. Words: 810. Reading Time: 4 mins.

Skills and Abilities

Objective 8.1 - Administer and Execute calls using the VMware NSX vSphere API

Construct and execute an API call using correct syntax and formatting
Programmatically configure system parameters including:
- NSX controller syslog
- Modify DLR declared dead time
Analyze, modify, and successfully retrieve configuration data using an existing API call.

Objective Prerequisites

The following prerequisites are assumed for this Objective:

A working VMware vSphere 6.x environment.
A working VMware NSX 6.x implementation.

Objective Breakdown

Construct and execute an API call using correct syntax and formatting

For API calls I tend to use Postman. I’m not sure how you can get the incorrect syntax when using the API guide from VMware. Within Postman, you choose the Request Type (i.e. GET, POST, DELETE, etc) and then enter the full URL of the API call.

In this example we are going to use Postman query the NSX API for the ID of the NSX Controller’s.

Note: I already have a Postman Collection called VMware NSX and an environment variable created for nsx-mgr which points to my VMware NSX Manager, cx-nsxc-01.thecloudxpert.local.

Launch Postman.

Within the Builder, select GET from the dropdown.

Enter the API request URL into the text field.

Note: For this Request, we’re using https://{{nsx-mgr}}/api/2.0/vdn/controller

Click Authorization and select Basic Auth from the Type dropdown.

Enter the Username and Password of the NSX Manager and click Update Request.

Click Send.

(Optionally) Click Save.

Enter a suitable name within the** Request Name** text box, select which collection to add this Request too and click Save to <Collection Name>.

Note: I have slightly enhanced the previous request in Postman so that it stores the controller id into a environment variable called controller-id. This works for me because I only have one controller.

I added the following as a Test to be completed after the request:

Programmatically configure system parameters including: NSX controller syslog

In this example, we’ll use the Controller ID from the previous example to update the NSX Controller SYSLOG settings via the API.

Open Postman.

Get the NSX Controller ID

Expand the VMware NSX collection and select Get Controller ID.

Click Send.

Note: This sets the NSX Controller ID as a environment variable called controller-id.

Check the existing SYSLOG configuration

Click Add (+) to create a new Request.

Select GET from the drop down and enter https://{{nsx-mgr}}/api/2.0/vdn/controller/{{controller-id}}/syslog into the API request URL text box.

Click Authorization and select Basic Auth from the Type dropdown.

Enter the Username and Password of the NSX Manager and click Update Request.

Click Send.

As you can see, the SYSLOG configuration hasn’t been completed yet.

Click Save.

Enter a suitable name within the** Request Name** text box, select which collection to add this Request too and click Save to <Collection Name>.

Update the SYSLOG configuration

Click Add (+) to create a new Request.

Select POST from the Request type dropdown.

Enter https://{{nsx-mgr}}/api/2.0/vdn/controller/{{controller-id}}/syslog into the Enter Request URL textbox.

Note: You can also just add the URL without the environment variables, which in my case would be:

https://cx-nsxc-01.thecloudxpert.local/api/2.0/vdn/controller/controller-2/syslog

Click Authorization and select Basic Auth from the Type dropdown.

Confirm the correct Username and Password and click Update Request.

Click Body.

Select the raw option and then select appplication/xml from the dropdown.

Either type (or copy and paste) the following into the body:

<controllerSyslogServer>
<syslogServer>**172.16.10.26**</syslogServer>
<port>**514**</port>
<protocol>**TCP**</protocol>
<level>**INFO**</level>
</controllerSyslogServer>

Click Send.

Note: A status code of 200 means a success!

(optionally) Click Save.

Enter a suitable name within the** Request Name** text box, select which collection to add this Request too and click Save to <Collection Name>.

Confirm SYSLOG Configuration

We can confirm the SYSLOG configuration by running the GET Controller SYSLOG Configuration request we saved earlier. The resultant screenshot is:

With request detail of:

<?xml version=1.0 encoding="UTF-8"?>
<controllerSyslogServer>
	<syslogServer>172.16.10.26</syslogServer>
	<port>514</port>
	<protocol>TCP</protocol>
	<level>INFO</level>
</controllerSyslogServer>

And that is it!

Programmatically configure system parameters including: Modify DLR declared dead time

From the previous example, I believe I have demonstrated the skills needed to run a REST API call for a particular scenario. The process would be:

Use GET to check what is set.
If nothing is set, then configure as required and upload using POST.
If a configuration exists, update the configuration (obtained via GET) and POST/PUT the changes required.

For this example, you could:

Use GET https://{{nsx-mgr}}/api/4.0/edges to provide a list of ALL Edges that exist.
Identify the ID of the edge and then use **GET https://{{nsx-mgr}}/api/4.0/edges/{edgeId}** to work with that specific edge.
Copy the body of the GET request and create a request using the XML with an amended declareDeadTime.
Use a PUT Request for https://{{nsx-mgr}}/api/4.0/edges/{edgeId} with the XML to update the Declare Dead Time.

Analyze, modify, and successfully retrieve configuration data using an existing API call

I think I have covered enough in the post to enable someone to look at a API call and compare it with the documentation and work out what is wrong.

Published on 30 July 2017 by Christopher Lewis. Words: 810. Reading Time: 4 mins.

Blog Categories: VMware NSX NSX-V Certification