This is the final blog of the series I am writing covering the exam prep guide for the VMware Certified Advanced Professional 6 – Network Virtualisation Deployment (3V0-643)  VCAP6-NV certification.

The reference guide for the entire blog series is here.

At the time of writing there is no VCAP Design exam stream, thus you’re automatically granted the new VMware Certified Implementation Expert 6 – Network Virtualisation (VCIX6-NV) certification by successfully passing the VCAP6-NV Deploy exam.

For previous blogs in this series please refer to the VCAP6-NV Reference Guide I created. This has all the links to VMware NSX content and lists out each exam objective and the associated blog. Check it out here –>Exam Objective Reference Guide.

This blogs covers:

Section 8 – Utilize API Commands to Manage a VMware NSX Deployment
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

What’s REST?

The VMware NSX API documentation says the following about REST:

REST, an acronym for Representational State Transfer, is a term that has been widely employed to describe an architectural style characteristic of programs that rely on the inherent properties of hypermedia to create and modify the state of an object that is accessible at a URL.

Once a URL of such an object is known to a client, the client can use an HTTP GET request to discover the properties of the object. These properties are typically communicated in a structured document with an HTTP Content‐Type of XML that provides a representation of the state of the object. In a RESTful workflow, documents (representations of object state) are passed back and forth (transferred) between a client and a service with the explicit assumption that neither party need know anything about an entity other than what is presented in a single request or response. The URLs at which these documents are available are often “sticky,” in that they persist beyond the lifetime of the request or response that includes them.

My NSX API overview…

The NSX Manager has a REST API that accepts API requests on TCP port 443 and utilises the standard HTTP application protocol.

You need a REST client to be able to send REST requests to the NSX Manager API. You can send REST requests via clients such as the Chrome app Postman, or the plug-in for Firefox or cURL.

You can do everything and more with the NSX API. There are somethings you cannot do in the vSphere Web Client and can only be done via the NSX API. For the VCAP exam they specifically ask us to configure two things that can only be configured by the API.

I have read the main parts of the VMware NSX 6.2 API Guide to get a handle on the functionality etc., how to send API requests to create objects like logical switches or modify Edge Service Gateways. There are literally hundreds of commands so I didn’t bother looking at all of them as you would query the API guide when you need a command.

Consumption of the NSX API allows you to automate and rapidly provision or tear-down any NSX networking services.

The REST API utilises HTTP requests and allow you to programmatically create, retrieve, modify or delete NSX objects.

You can use HTTP GET commands to read and retrieve objects, HTTP PUT or POST to create or update objects and HTTP DELETE to delete objects.

When consuming the API there are only two operations you can do and these are repeated in order until the required information is located or a specific action taken. These two actions are:

• SUBMIT an HTTP REQUEST (GET, PUT, POST, DELETE) to the NSX Manager.
• EXAMINE the HTTP RESPONSE. This can either be a standard HTTP code i.e. 200 or 500, or an XML document containing information about objects.

Remember that: Submit request, Examine response, rinse and repeat.

Construct and execute an API call using correct syntax and formatting

There are a couple of parts to constructing an API request before sending it to the NSX API.

If using Chrome or Firefox you need to select the option to use Basic Authentication and you must create an Authorisation Header.

You need to know the URL to send the request to. By default the NSX Manager URL is:  https://your_nsx_manager/api, or in my case https://labnsx01.lab.local/api

You append to this URL the rest of the HTTP request for the specific object. For example to query the NSX Manager for VMs that are excluded from the NSX Distributed Firewall (DFW) the HTTP GET request would be: GET https://labnsx01.lab.local/api/2.1/app/excludelist

For every request you submit you will need to know if the request is a GET, PUT, POST or DELETE.

Finally, if you use PUT requests you will need to also define the content-type header which is: content‐type: application/xml

Lets walk through that using the Chrome PostMan REST client…

I will walk through the above using the Chrome PostMan REST client to send a request to the NSX Manager to query VMs that have been excluded from the DFW. You will see how to enable PostMan in Chrome, how to select Basic Authentication, create an Authentication Header and enter the URL.

To get the Chrome REST client

Open Chrome and do a Google search for Chrome Postman REST client.

One you can see the REST client, click Add to Chrome.

To open Chrome PostMan, click on the   Apps icon and select PostMan REST client.

The PostMan REST client opens.

Select Basic Authentication and create Authorisation Header

Click Basic Auth. Enter the username and password that has rights to log into the NSX Manager.

Click on Refresh Headers, this will create the Authorisation Header.

Once you click Refresh Headers, you can see the Authorisation Header.

Add the NSX API URL

We need the URL for the object we want to query, obviously this will be a GET command. I am going to query any objects excluded from the DFW and the URL will be: https://labnsx01.lab.local/api/2.1/app/excludelist

Once I enter the URL, I select GET  and then I click on the Send button.

The HTTP request is sent to the NSX API and processed. The NSX Manager returns an HTTP response that contains XML as shown:

If I zoom in on a specific bit of the XML response I can see the VMs that I have excluded:

And that’s the basics of sending an HTTP GET request to the NSX API and seeing some information returned.

Repeat this process for other objects to get familiar with it.

Note: To use the Firefox REST client, open Firefox, select Open Menu and click Add-Ons. Search for REST client and install the add-on. I installed the RESTEasy client.

Note: To use the cURL REST client, download it and install it.

Let’s do another one…

I want to query the NSX Manager and determine what NTP time-server the NSX Manager is configured for by a GET request. Then I want to send a PUT request to modify this.

I look in the API guide to get the commands I need.

I already have Basic Authentication selected and an Authorisation Header created. As I am going to use a PUT request I will also need to create the content-type: application/xml.

The GET request to retrieve the objects is: GET https://labnsx01.lab.local/api/1.0/appliance-management/system/timesettings

The XML response is returned showing that my NSX Manager is configured as below:

Now I want to change the NTP server that the NSX Manager uses. I need use a PUT request to modify the object, I also need the XML for the request. Look in the NSX API guide to find the XML required. The XML is:

I am going to change my NTP server to: MyNTPserver.com and change the time zone to NZ. I enter the details and click SEND, make sure it’s a PUT request.

I then run a GET request to query the service to confirm the change has been made.

If I log into the NSX Manager and have a look, sure enough it’s changed.

Done! So that pretty much covers the basics.

Up next I will be looking at adding Syslog to the NSX Controller and Modify DLR declared dead time via the NSX API.

Programmatically Configure NSX Controller Syslog

The NSX Controller syslog setting can only be configured by a request to the NSX API. VMware specifically ask us to configure this object in the exam.

The request and XML is

https://labnsx01.lab.local/api/2.0/vdn/controller/controllerId/syslog

First I need to identify the ControllerID to run the command against, so I run the following command to see all NSX Controller information:

https://labnsx01.lab.local/api/2.0/vdn/controller

I want to add syslog to controller-6.

I need the POST request and the XML to set the syslog object.

The POST request is:

https://labnsx01.lab.local/api/2.0/vdn/controller/controllerID/syslog

*Change ControllerID to Controller-6.

https://labnsx01.lab.local/api/2.0/vdn/controller/controller-6/syslog

The XML is:

If I now run the same query but as a GET, I can see the configuration change.

And that’s how you configure syslog for an NSX Controller.

Programmatically Configure and Modify DLR declared dead time

Again, VMware specifically ask us to configure this object in the exam.

I am sure that VMware are referring to high-availability here for the Edge Services Gateway. Let’s get into it.

First I am going to need to know what Edge instance I will be changing, I will need to do a GET and retrieve all the ESG instances and find the ObjectID for a specific instance.

I can do this with a GET https://labnsx01.lab.local/api/4.0/edge

I am now going to retrieve with a GET the high-availability status of Edge-42 with the following command:

GET https://labnsx01.lab.local/api/4.0/edges/edge-42/highavailability/config

Can see in the above screenshot that the DeclareDeadTime for Edge-42 is set to the value of 15.

I want to change this value to 6 (seconds).

I use the same request, this time using a PUT request and the XML:

PUT https://labnsx01.lab.local/api/4.0/edges/edge-42/highavailability/config

The XML is:

Now I can repeat the GET request to confirm the setting for DeclareDeadTime has been changed to 6. Which it has.

And that pretty much covers off all of the exam objective. I am not going to detail the last section as I believe I have covered most of that in this blog already.

Make sure to do this stuff in your lab or VMware Hands On Labs and have a good look at the NSX API guide.

Once I sit and complete VCAP6-NV it will be my 3rd VCAP. They are not easy exams and I am in no rush to sit it if I think I might fail, there is a heap of content in this blueprint.

From New Zealand the VCAP exam experience can be an interesting and frustrating one when sitting a deploy exam, the latency can be a killer. Fingers crossed.

I hope you have learnt something new about VMware NSX and this blogging series helps you study for the exam. I doubt very much that you could read these blogs, memorise it and pass, the VCAP exam will require a good amount of hands-on-experience. It’s a race against the clock and when you walk out 4 hours later it will feel like you have only been at the test center for 30 minutes!

Blogging this exam blueprint has been a massive learning curve. I have done some production NSX deployments in the past but going over the blueprint like this has given me a good depth of all the features and taught me some new networking concepts in the process.

It’s been good to read the content, absorb it, digest it, do it in the lab, document it and finally summarise it in a way that hopefully isn’t to complex for a blog.

It was September 10th 2016 when I decided to start studying for VCAP6-NV. 10.5 weeks have passed and I have spent 150 hours sitting in my home-office studying and blogging. Hopefully only another 50 to go and then I will go and smash this exam. Looking forward to getting some time back and spending it on my motorbike!!

The reference guide for the entire blog series is here.

Follow me on Twitter or LinkedIn.

Be Social; Please Share.