Resolving an Infoblox IP Address with vRealize Orchestrator’s HTTP-REST Plug-in

We use Infoblox for DNS management in our private cloud environment, and as part of the provisioning process we add a new DNS entry for the VM, but before we add a new DNS entry we want to make sure one doesn’t already exist.  In our dev/test environment I was using the vRealize Orchestrator (vRO) SSH plug-in to run the nslookup command on the vRO server, parse the result and determine if a DNS entry existed.  In our production environment I wasn’t able to do this so I decided to look into using the vRO HTTP-REST plug-in.  We are using an older version of the Infoblox plug-in so it’s possible that newer versions have this functionality built-in.

Even if you’re not using Infoblox in your environment, this example will show you how easy it is to use the vRO HTTP-REST plug-in.  Using vRO context menu actions in vCenter, you could also run a workflow that extracts IPs off of VMs in vCenter and registers them with Infoblox.

The below actually looks like a lot more work than it is.  Since I already knew how to get results from Infoblox using curl, it took about 10 minutes to do the same in vRO.

Performing an Infoblox REST API call with curl

In the past I found out how to use the curl command to make REST API calls to perform options on Infoblox.  Looking up an IP address is straightforward:

curl -k -u user:pass -X GET

Let’s break this down:

  • -k is insecure mode.  This ignores self-signed certificates.
  • -u user:pass are the credentials.
  • -X is the type of HTTP request.
  • is the Infoblox host.
  • record:host specifies that we are looking up a host record.
  • The IP at the end is the IP was are looking up.

This command results in:


        "_ref": "record:host/ZG5zLmhvc3QkLl9kZWZhdWx0LmNvbS5zZWFnYXRlLm9rbGEuY2xkLmNsb3VkbGcwMTYwNTA:superserver.vmware.local/Internal%20seagate", 
        "ipv4addrs": [
                "_ref": "record:host_ipv4addr/ZG5zLmhvc3RfYWRkcmVzcyQuX2RlZmF1bHQuY29tLnNlYWdhdGUub2tsYS5jbGQuY2xvdWRsZzAxNjA1MC4xMC40OC4xNi41MC4:", 
                "configure_for_dhcp": true, 
                "host": "superserver.vmware.local", 
                "ipv4addr": ""
        "name": "superserver.vmware.local", 
        "view": "Internal"

Now let’s create a vRO workflow to do the same thing as the curl command.

The steps we need to do are:

  1. Create a REST host.
  2. Create a REST operation.
  3. Testing the operation by invoking it.
  4. Creating a new workflow based off of the host and operation.
  5. Modifying the new workflow to add extra functionality that we need.
  6. Run the new workflow and validate it returns the expected result.

Add a REST host

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST host” workflow



Add a REST Operation

We need to create a REST operation that reproduces what we did with the curl command:

curl -k -u user:pass -X GET

Our HTTP-REST host is “” and the template URL will be “record:host?ipv4addr={ip}” where {ip} is the name of the IP parameter that we pass in.

In the vRO client, go to Library > HTTP-REST > Configuration and run the “Add a REST Operation” workflow.


Invoke a REST Operation

Let’s test out our newly defined REST Operation.

In the vRO client, go to Library > HTTP-REST and run the “Invoke a REST Operation” workflow.



The result is:

[2015-04-16 17:14:10.013] [I] Request: DynamicWrapper (Instance) : [RESTRequest]-[class] -- VALUE :
[2015-04-16 17:14:10.014] [I] Request URL:
[2015-04-16 17:14:13.341] [I] Response: DynamicWrapper (Instance) : [RESTResponse]-[class] -- VALUE :
[2015-04-16 17:14:13.341] [I] Status code: 200
[2015-04-16 17:14:13.341] [I] Content as string:

"_ref": "record:host/ZG5zLmhvc3QkLl9kZWZhdWx0LmNvbS5zZWFnYXRlLm9rbGEuY2xkLmNsb3VkbGcwMTYwNTA:superserver.vmware.local/Internal",
"ipv4addrs": [
"_ref": "record:host_ipv4addr/ZG5zLmhvc3RfYWRkcmVzcyQuX2RlZmF1bHQuY29tLnNlYWdhdGUub2tsYS5jbGQuY2xvdWRsZzAxNjA1MC4xMC40OC4xNi41MC4:
"configure_for_dhcp": true,
"host": "superserver.vmware.local",
"ipv4addr": ""
"name": "superserver.vmware.local",
"view": "Internal"

We can see that the status code is 200, which means OK, and you may recognize the rest as being in the json format.  I’ll discuss this more later.

Create a new workflow off of our REST operation

Now that we know that our REST operation works, we want to create a workflow off of it so that we can modify it for our own needs.

In the vRO client, go to Library > HTTP-REST and run the “Generate a new workflow from a REST operation” worfklow.




Modifying our new workflow

Now we need to modify our workflow to make it return the fully qualified domain name (FQDN) of the IP address that we searched for.

Edit the “Infoblox IP Lookup” workflow.

  1. Select the Outputs tab
  2. Select Add Parameter

Select arg_out_0 to rename it.


Name it fqdn

2015-04-16_17-10-53It should now look like:


Remember when we invoked the REST operation to test it and it returned json as output (well, technically it returns a string that we convert to json)?  Now we need to parse the json results and get the info we need.  Since vRO uses Javascript as it’s scripting language, this is really easy to do.

Let’s add the additional code we need.

  1. Select the Schema tab.
  2. Select the Scripting object.
  3. Select the Scripting tab.


Go to the bottom and add the following code:

// Convert the results from Infoblox into a json object. 
var jsonContent = JSON.parse(contentAsString)

// The json object will be an array.  Let's print out how many results we found.  It should only be one.  
System.log("results: " + jsonContent.length)

// If our status code is 200 and we received exactly one result, access the name key, which contains our DNS name
// and then set the fqdn variable to the DNS name.  The fqdn variable will be returned to the calling workflow.
if (statusCode == '200') {
  if (jsonContent.length == 1) {
    fqdn = jsonContent[0].name
    System.log("IP resolved to " + fqdn);
  else {
    fqdn = ''
    System.log("IP doesn't exist in infoblox" + jsonContent.length)

It should look like this:


Configure the output of the workflow to return the fqdn variable.

  1. Select the Out tab.
  2. Select the fqdn variable.
  3. Select finish.


Run the Infoblox IP Lookup workflow and enter an IP you want to lookup:


The output should be the same as when you invoked the REST operation, but now at the end you should see:

[2015-04-17 12:02:41.476] [I] IP resolved to superserver.vmware.local.

You can then use this result however you want.  In our case, we either keep the existing entry or delete it and create a new one depending on if it matches the new VM we are creating.

Decommissioning the vCenter Server or a Platform Services Controller

Now that vSphere 6 is out, at some point you’ll probably be experimenting in your lab with various vCenter deployment configurations.  During my testing I shut down one of my Platform Services Controller (PSC) and vCenter to see how it would impact the other PSC/vCenter it was replicating with.  When I logged into the active vCenter I saw the following:


I wanted to remove all references to the old vCenter server (vc6c.vmware.local) so I looked through the vSphere 6 Install, Configuration and Troubleshooting guides but didn’t find anything.  They mentioned how to uninstall the vCenter software, but that’s it.

I decided to jump onto my existing PSC and try to see if I could find any commands that may be helpful.  Since it’s faster to deploy, I’ve been using the vCenter Service Appliance (VCSA) in my lab.  First I ssh to the server and then run the following commands as prompted to enter the shell:

shell.set –enabled True

The first directory that I found with some promising files was the /usr/lib/vmware-vmdir/bin directory.

vc6b:/usr/lib/vmware-vmdir/bin # ll
total 724
-rwxr-xr-x 1 root root  62656 Feb  8 06:14 vdcadmintool
-rwxr-xr-x 1 root root  46512 Feb  8 06:14 vdcbackup
-rwxr-xr-x 1 root root  48864 Feb  8 06:14 vdcleavefed
-rwxr-xr-x 1 root root   7640 Feb  8 06:14 vdcpass
-rwxr-xr-x 1 root root  50152 Feb  8 06:14 vdcpromo
-rwxr-xr-x 1 root root  13168 Feb  8 06:14 vdcrepadmin
-rwxr-xr-x 1 root root  44712 Feb  8 06:14 vdcsetupldu
-rwxr-xr-x 1 root root  42648 Feb  8 06:14 vdcsrp
-rwxr-xr-x 1 root root  57320 Feb  8 06:14 vdcupgrade
-rwxr-xr-x 1 root root 332480 Feb  8 06:14 vmkdc_admin

We can run the vdcrepadmin command to see what replication partners are registered:

./vdcrepadmin -f showpartners -h vc6b.vmware.local -u administrator -w VMware1!

Here we see that on my existing vCenter server (vc6b.vmware.local) the only replication parter is the server that I shut down (vc6c.vmware.local).

By specifying showservers as the as a parameter, we can see the distinguished name of all servers:

./vdcrepadmin -f showservers -h vc6b.vmware.local -u administrator -w VMware1!

My first attempt at trying to remove vc6c.vmware.local was by running the vdcleavefed command:

./vdcleavefed -h vc6c.vmware.local -u administrator -w VMware1!
vdcleavefd offline for server vc6c.vmware.local
Leave federation cleanup done

The output looked promising but the warning regarding vc6c.vmware.local being unavailable still remained.  I then found article Decommissioning the vCenter Server or a Platform Services Controller (2106736).  The KB article says to run the following command:

cmsso-util unregister –node-pnid vc6c.vmware.local –username administrator@vsphere.local –passwd VMware1!

The output of the command is:

2015-04-09T04:01:20.317Z   Running command: [‘/usr/lib/vmware-vmafd/bin/dir-cli’, ‘service’, ‘list’, ‘–login’, ‘administrator@vsphere.local’]
2015-04-09T04:01:20.378Z   Done running command
2015-04-09T04:01:20.449Z   Running command: [‘/usr/lib/vmware-vmdir/bin/vdcleavefed’, ‘-h’, ‘vc6c.vmware.local’, ‘-u’, ‘administrator’]
2015-04-09T04:01:26.522Z   Done running command

After I logged back into the Web Client I found that the warning regarding my old vCenter was gone.  I re-ran the vdcrepadmin command to confirm that the old vCenter was no longer being referenced.  The dir-cli service list command appears to only list the running services and the output from the cmsso-util command says the only other command that was ran was the vdcleavefed command, which I had tried previously, so it must be doing something that’s not mentioned in the output.  cmsso-util is a Python script so it should be straightforward to see what it’s doing.

I wish VMware had some more documentation around the various SSO commands.  I’m compiling my own list as I go along and thought this KB would be a good one to share.