One of my favorite products has just dropped a new version. vRealize Network Insight 3.8 (vRNI) has just hit the downloads and has a bunch of cool new stuff.

vRNI 3.6 introduced a public API with which you can do most of the day-2 operations. vRNI 3.7 didn’t bring any changes to the API, but 3.8 does. Below are the changes in the API version 1.1.0.

Fetching info in bulk

Version 1.0.0 had endpoints to grab information from entities (VMs, hosts, firewall rules, etc), but it was a bit tedious. You had to request a paged list of entities you were looking for and would get a list of entity IDs. You would then use these entity IDs to request information on that entity one a 1 by 1 basis. That results into 51 API calls for info on 50 entities.

This release allows you to retrieve information in bulk, using a list of entity IDs you supply in one go.

Entities

All entities can be fetched in bulk. You do need a list of entity IDs and types before you can use this. It does mean that you only have to do 2 API calls to get information on 50 entities: first get a list of the entities you want and then call the new endpoint with the list of entities to get their details.

Endpoint

POST /api/ni/entities/fetch

Body

{
  "entity_ids": [
    {
      "entity_id": "14307:1:863020427",
      "entity_type": "VirtualMachine"
    },
    {
      "entity_id": "14307:1:862869488",
      "entity_type": "VirtualMachine"
    },
    ..etc..
  ]
}

Note: you can have a mixed list of entities. For instance: have the IDs of a VirtualMachine and a Datastore type in the same list and you will get proper results.

Result

{
  "results": [
    {
      "entity_id": "14307:1:863020427",
      "entity_type": "VirtualMachine",
      "entity": {
        "entity_id": "14307:1:863020427",
        "name": "GRE-1-0",
        "entity_type": "VirtualMachine",
         ....etc....
       }
    },
    {
      "entity_id": "14307:1:862869488",
      "entity_type": "VirtualMachine",
      "entity": {
        "entity_id": "14307:1:862869488",
        "name": "3TA-Edge01-0",
        "entity_type": "VirtualMachine",
         ....etc....    
    }
  ]
}

Applications

As with the entities, you can also grab a complete list of applications in 1 API call now.

Endpoint

GET /api/ni/groups/applications/fetch

Result

{
  "results": [
    {
      "entity_id": "14307:561:1180819457",
      "name": "vRNI",
      "entity_type": "Application",
      "create_time": 1518959331317,
      "created_by": "admin@local",
      "last_modified_time": 0,
      "last_modified_by": ""
    },
    ....etc...
  ]
}

Metrics

There are a lot of metrics available in vRNI. For instance: bandwidth counters, VM CPU usage, datastore usage, etc. You can now retrieve those counters from the API to use those metrics for processing.

Endpoints

GET /api/ni/metrics
GET /api/ni/schema/{entity-type}/metrics

These are pretty elaborate endpoints, which probably deserve a separate post. Essentially, you can export the metrics to create your own reports or graphs in another portal.

Settings

Not many settings in vRNI are ripe for automation, as they almost never change. But east-west and north-south IP ranges can be an exception to that. If you have a registration procedure for new IP ranges that are specifically used for a certain task, it can happen that those IP ranges need to be registered within vRNI to keep the traffic direction reports on track.

You can use the following API endpoints to register new east-west and north-south IP ranges:

Endpoints

GET /api/ni/settings/ip-tags/tag-ids
GET /api/ni/settings/ip-tags/{tag-id}
POST /api/ni/settings/ip-tags/{tag-id}/add
POST /api/ni/settings/ip-tags/{tag-id}/remove

Example

If you want to add a certain IP range (let’s say 1.1.1.0/24) to the east-west IP range settings, so that it starts counting as east west traffic, you can use the endpoint to add a IP range to a tag. First, let’s see which tags there are:

Endpoint

GET /api/ni/settings/ip-tags/tag-ids

Result

{
  "tag_ids": [
    "INTERNET",
    "EAST_WEST"
  ]
}

For now, these will be the only tags available in vRNI – so it’s a safe bet you need either INTERNET or EAST_WEST and you do not need to do the lookup every time you want to make a change. Now that we know the tag, let’s move on to adding the IP range:

Endpoint

POST /api/ni/settings/ip-tags/EAST_WEST/add

Body

{
  "tag_id": "EAST_WEST",
  "subnets": [
    "1.1.1.0/24"
  ],
  "ip_address_ranges": [
    {
      "start_ip": "1.1.1.0",
      "end_ip": "1.1.1.255"
    }
  ]
}

The “ip_address_ranges” is a different way of adding IP ranges and can be used if you’re not adding a complete subnet. In this case, I left it out of the body and only used “subnets”

Result

New Data Source types

This is not not earth shattering; vRNI 3.7 introduced some new data source types and the API can now handle those.

• NSXTManagerDataSource
• InfobloxManagerDataSource

As usual, all the endpoints are documented in the Swagger instance located on your vRNI Web Interface.

Share the wealth!