Integrating Infoblox IPAM with vRealize Automation - Part 1

Many customers love the idea of self-service provisioning through vRealize Automation (vRA), but do not want to give up control of IP address management (IPAM) to the new tool. I frequently see requests for us to integrate vRealize Automation into a customer’s existing IPAM solution – and pretty much every time this is the Infoblox solution. So, I thought I’d give it a go!

In this first blog, I will replay how I initially configured my environment to integrate the solutions. In my next post, I will explain how I used that integration to achieve an effective server build from the vRA blueprint.

In my environment, I am using vRealize Automation 6.2.1, and vRealize Orchestrator 6.0.1. For Infoblox, I used the virtual appliance vNIOS version 6.11, and their vRO plug-in version 2.4.1.

For starters, I had some trouble in my past attempts to do this. The Infoblox plug-in for vRealize Orchestrator (vRO) was finicky and a little hard to work with. But Infoblox have revised their plug-ins and their core solution, and I have to say I had almost no trouble this time around.

Deployment of the appliance is easy enough, documented here: https://www.infoblox.com/sites/infobloxcom/files/resources/vnios-trial-quick-start-guide_1.pdf

Deployment of the plug-in was similarly fairly easy, and documentation is provided with the plug-in itself (for which you need to register, here: https://www.infoblox.com/downloads/software/vmware-vcenter-orchestrator-plug-in).

Two quirks of note that I discovered:

• I could not register the vNIOS appliance to the plug-in using the FQDN. I believe this was because the appliance FQDN was a “.local” domain, and deemed as invalid. Using the IP address got around this problem, and the error message made it pretty clear that it was not happy with DNS validity, so it wasn’t hard to drill down to what alternatives to try.
  
  
• The self-signed certificate was expired. It appears that the default certificate generated has a lifetime of one year.  This was only an issue for me when trying to connect the plug-in. Again, fairly easily fixed – this time through the Infoblox System Manager web app under System – Certificates.
  
  

The vRO plug-in also requires a workflow package to be imported, to support some of the additional functions that the plug-in invokes.  This package is included in the plug-in download, and included in the documented instructions.

Once I installed the plug-in for my setup, I used the provided Infoblox vRO workflows to:

• “Install vCO customization wrapper”.
  
  
  
  
  This enabled vRA to call out to Infoblox via vRO (aka vCO) during three distinct lifecycle stages:
• Building – this stage is where IP addressing is reserved in IPAM and passed back into vRA during the initial provisioning.
• Provisioned – once the machine is built, this calls out to the workflow “Update MAC address for vCAC VM wrapper”, which appears to grab the as-built MAC address from the VM (nic0) in order to populate Infoblox with this detail.
• Disposing – when the machine is destroyed, this calls-out to “Remove Host Record or A/PTR/CNAME/Fixed address/Reservation of vCAC VM wrapper”. In essence, this removes the entries made by the previous workflows.
  
  
  
• CAVEAT: In my environment only, the above Removal workflow does not release the IP address back into the available pool. I am still working on this, and will update this article accordingly. For the moment, I manually review the “Used” records (without any other data associated) and perform a “Reclaim” in the Infoblox management console.  Strangely, this behaviour did NOT happen in a customer's environment, nor in Infoblox's own test environment.  
• “Create Build Profile for Reserve an IP for a vCAC VM in Network”. This piece of absolute magic sets up a new Build Profile in vRA so that I can merely select it during blueprint definition to enable IPAM integration. Magic!!

I used the “in Network” method of IP allocation, because I just wanted Infoblox to pick the next address within a given subnet range. I already have certain ranges carved out and reserved for other purposes (such as vRA’s own ranges that it manages, more on that later) – so anything that wasn’t already reserved is free game for Infoblox to grab. The other methods are “in Range” (if you have specifically carved out one in Infoblox for this purpose), or “general” (if the IP address to reserve is already known, perhaps through an external process prior to the request).

Once I had run these initial configuration workflows, everything was almost ready to go for vRealize Automation to utilise.

 This wraps up the first blog covering initial setup. In the next blog article, I will specify how vRA is configured to utilise Infoblox as part of its provisioning.