Dr. Pranay Jha

A deployment that sits at 12% for nine minutes and then fails with no IP address available in range is almost never a network problem. It is an integration problem. The template asked for a static IP, nothing was wired to hand one out, and the engine waited until it gave up. That is the whole story of integrations in VCF Automation: the platform provisions VMs perfectly well on its own, and falls flat the moment it needs to talk to the IPAM database, the ticketing system, or the config-management server that the rest of your estate already runs on. This Part wires those three in, and is blunt about the boundary that decides whether you can wire them at all.

The integration surface, and the VM Apps boundary

VCF Automation (formerly VMware Aria Automation, before that vRealize Automation) carries forward the integration model from the Aria 8.x days, but VCF 9 reorganized where it lives. In the current product the prebuilt integrations, external IPAM, ServiceNow ITSM, Ansible, Puppet, are administered inside a VM Apps organization. That is the VM-centric org type that stays close to Aria Automation 8.x. The newer All Apps organization, built on the Kubernetes-style API, does not surface those same integration points. If your design started with an All Apps org because someone liked the word Kubernetes, and you assumed the Infoblox plugin would just be there, it will not be.

The first thing I check on any integration engagement is which org type the catalog actually lives in. It changes the entire conversation. I covered the trade-off in detail in Part 3 on VM Apps vs All Apps, and it is the single most consequential decision on this page.

External IPAM with Infoblox

How it actually works

The external IPAM framework does not call Infoblox directly from the provisioning engine. It runs a packaged set of ABX actions in an on-prem embedded running environment. You download the provider package (the Infoblox plugin .zip from the vendor or the Broadcom marketplace), import it, and select the integration point, something like Infoblox_abx_intg, as the running environment. From then on, every allocate, deallocate, and update operation against an external-IPAM-backed network range fires those actions. One consequence worth saying out loud: the IP lifecycle now belongs to Infoblox, not to vCenter or the network profile. If a deployment is destroyed and the IP is not released, that is an ABX failure to chase, not a vSphere one.

You also have to enable the right extensible attributes inside Infoblox before anything works. The plugin reads and writes them; if they are missing, allocation fails with a permission-shaped error that sends people down the wrong rabbit hole.

Wiring it into a cloud template

Once the network profile maps a range to the external IPAM provider, the template stays clean. You ask for a static assignment and constrain placement onto the IPAM-backed network with a tag. The plugin does the rest.

formatVersion: 1
inputs: {}
resources:
  app-vm:
    type: Cloud.vSphere.Machine
    properties:
      image: ubuntu-22
      flavor: medium
      networks:
        - network: '${resource.app-net.id}'
          assignment: static          # plugin must supply the IP
  app-net:
    type: Cloud.Network
    properties:
      networkType: existing
      constraints:
        - tag: 'ipam:infoblox'        # range backed by external IPAM

Expected result: the deployment binds a real Infoblox-managed IP and DNS record. Failure mode: assignment: static with no IPAM behind the range, which is exactly the nine-minute hang from the opener.

In VCF 9.1 there is a tighter path on the networking side: the new NSX-to-Infoblox external IPAM integration lets a provider tie an Infoblox network container directly to VCF Automation IP blocks, so the address management is consistent from NSX through to the self-service request. If you are on 9.1 and running NSX, prefer that alignment over two disconnected IPAM stories.

ServiceNow ITSM

Plenty of organizations want VCF Automation to do the provisioning but never want users to leave ServiceNow. The VCF Automation Plugin for ServiceNow ITSM (downloaded from the ServiceNow Store) handles that. It pulls your published catalog items into the ServiceNow service catalog, lets users request and run day-2 actions from the ServiceNow portal, and writes the results back to VCF Automation and the CMDB. The bridge in the middle is a MID Server, the ServiceNow component that reaches into your environment and calls the VCF Automation API. No MID Server, no integration.

Version alignment is the part that quietly fails registrations. The current plugin tracks recent ServiceNow families (Yokohama and Xanadu at the time of writing) and a specific VCF Automation release. The first thing I check on a broken ServiceNow integration is the compatibility matrix, not the credentials. Confirm the plugin version supports both your ServiceNow family and your VCF Automation build before debugging anything else.

Configuration management: Ansible and Puppet

Provisioning a VM gets you an OS and an IP. It does not get you a configured application. VCF Automation gives you three escalating options. For light first-boot work, cloud-init through the cloudConfig property is enough. When you need real configuration and ongoing drift control, integrate Ansible (Open Source or Ansible Automation Platform / Tower) or Puppet Enterprise. The difference matters operationally: cloud-init runs once at birth and forgets; Ansible and Puppet keep enforcing state for the life of the machine. If you care about a host staying compliant in month six, cloud-init is the wrong tool.

Once the integration exists, you add the component to the cloud template and point it at the playbooks. With Ansible Open Source it looks like this:

  ansible:
    type: Cloud.Ansible
    properties:
      osType: linux
      account: ansible-oss
      username: svc_ansible
      host: '${resource.app-vm.*}'
      groups:
        - webservers
      playbooks:
        provision:
          - 'site.yml'
      maxConnectionRetries: 15

Expected result: after the VM is up, the playbook runs against it and the host lands in the right inventory group. Failure mode: SSH not ready when Ansible fires, which is why maxConnectionRetries exists. With Puppet, you set installMaster to the compile master so deployed nodes get the enhanced day-2 actions instead of a one-shot run.

One field warning: do not let two systems own the same config. If Puppet enforces a package and an Ansible playbook also touches it, you get a fight that surfaces as random drift nobody can reproduce. Decide which tool owns which layer, and write it down.

When there is no plugin: the API path

Every estate has a system with no prebuilt integration, a homegrown CMDB, a secrets vault, a billing platform. And All Apps orgs do not get the classic plugins at all. The answer in both cases is the same: the VCF Automation API, usually orchestrated by VCF Operations Orchestrator or ABX, triggered by Event Broker subscriptions. The token flow is the same one from Part 20: get a refresh token, exchange it for a bearer access token, then call the API.

# 1. Get a refresh token
curl -k -X POST https://automation.vcf.example.com/csp/gateway/am/api/login 
  -H 'Content-Type: application/json' 
  -d '{ "username": "svc-automation", "password": "REDACTED" }'
# -> { "refresh_token": "xMfw..." }

# 2. Exchange for a bearer access token
curl -k -X POST https://automation.vcf.example.com/iaas/api/login 
  -H 'Content-Type: application/json' 
  -d '{ "refreshToken": "xMfw..." }'
# -> { "token": "eyJ0eXAi..." }

# 3. List the IPAM-backed IP ranges
curl -k https://automation.vcf.example.com/iaas/api/network-ip-ranges 
  -H 'Authorization: Bearer eyJ0eXAi...'

Failure mode worth memorizing: a 401 here is usually the org-type trap, the wrong domain or the wrong login endpoint for a provider versus tenant context. Validate which org and which identity you are authenticating against before assuming the credentials are bad. For deeper API context this overlaps with the separate Automating VCF Series on API authentication, which covers the infrastructure side.

My Take

Use the prebuilt plugins when you can. The Infoblox IPAM and ServiceNow integrations exist because almost everyone needs them, they are supported, and rebuilding either by hand is a waste of a quarter. My recommendation: standardize on external IPAM from day one if you run Infoblox, expose the catalog through ServiceNow if that is where your users already live, and reuse your existing Ansible or Puppet estate rather than reinventing config management inside templates. Where I would do it differently: if you are committed to an All Apps org, stop expecting the classic plugins and budget for the API-plus-Orchestrator path up front, because discovering that boundary mid-project is how integration timelines double. The trade-off is real, prebuilt is faster but VM Apps only, custom is portable but slower, and you should pick deliberately, not by accident of which org someone clicked first. Which integration is blocking your rollout right now, IPAM, ITSM, or config management? Start there.

References

• Broadcom TechDocs: Add an external IPAM integration for Infoblox in VCF Automation
• Broadcom TechDocs: Using the ServiceNow ITSM Plug-in for VCF Automation
• Broadcom TechDocs: What is configuration management in VCF Automation for VM Apps
• Broadcom TechDocs: What’s new in VCF Automation 9.1

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts