A platform team on Aria Automation 8.18 needed to place new virtual machines into Cisco ACI endpoint groups as part of provisioning. The official ACI plugin for vRealize could not do it. Cisco validated that plugin for vRealize Automation 8.2 through 8.4 and has not updated it for Aria Automation 8.18 or later. The blueprint was ready. The network was not.
The Challenge
ACI was already the source of truth for the virtual distributed switch. A VMM domain was connected to vCenter, the hosts were discovered, and endpoint groups were creating the port groups the VMs had to land on. What was missing was the handoff from the provisioning workflow to APIC.
Waiting for a vendor plugin release was not a plan. The environment was already on a release the plugin does not claim to support, and the provisioning path could not stay manual. Every VM that came out of Aria Automation still needed a person to find the right EPG and move the adapter.
What We Built
The replacement talks to APIC over its REST API from Aria Automation Orchestrator, and talks to vCenter from the same workflow. It does not wrap the abandoned plugin. Four actions cover the path that provisioning actually needs:
- Create an endpoint group and associate it with the VMM domain.
- Resolve the port group name ACI created for that EPG.
- List the EPGs already present in a tenant and application profile, so the workflow can attach to one instead of always creating one.
- Move the VM network adapter onto that port group.
The workflow that operators run is the composition of those actions: pick the tenant, application profile, and EPG, then place the VM. Compatibility in the environments we have run it against is ACI 5.x and 6.x, Aria Automation and Orchestrator 8.x including 8.18, and vSphere 7.x and 8.x.
It only works if the prerequisites are already true. APIC has to manage the VDS. The hosts have to be discovered. Orchestrator needs a network path to APIC on HTTPS, an APIC account that can read and write the tenant, and a vCenter connection with permission to change VM networking. If any of those are missing, a custom workflow will fail in the same place a plugin would have failed. The plugin gap was never the fabric. It was the last mile from the catalog request to the port group.
What to Check Before You Copy This
Do not start by reimplementing the whole ACI plugin. Start by writing down the one operation the catalog request cannot finish. In this case it was “put this VM in this EPG.” Everything else in the official plugin is unused surface area.
Then confirm the VMM domain is already doing its job. If EPGs are not creating port groups, no Orchestrator action will invent them. The custom code assumes that association exists and only completes the VM attachment.
Treat the APIC account as a provisioning identity, not a fabric-admin identity. It needs write access to the tenants the catalog is allowed to touch, and nothing broader. Store that account in Orchestrator. Do not put it in the blueprint.
This is the same class of problem as a blueprint that runs out of room. When the catalog item needs a side effect the blueprint schema cannot express, the side effect belongs in an Orchestrator action with a narrow contract, not in a larger blueprint.
The Results
The catalog request finishes the network move. The workflow authenticates to APIC, confirms the EPG, resolves the port group ACI already published, and changes the VM adapter. It does not recreate the fabric. If the VMM domain is not already creating port groups, the action fails in the open, which is the correct failure.
Lessons Learned
The plugin gap was the last mile, not the fabric. Reimplementing the whole ACI plugin would have been a second product. One operation, “put this VM in this EPG,” was the contract. The APIC account is a provisioning identity stored in Orchestrator, not a fabric-admin account pasted into a blueprint.
Getting Started
This one does not run from a shell. Import PlaceVmIntoEpg_SingleScript.js as an Orchestrator action in com.essential.aci, then run it with your endpoints. The names below are the essential.coach lab. Replace them.
apicHost = apic.essential.coach
tenant = tenant-app
appProfile = profile-app
epg = epg-web
vmName = web01.essential.coachClone aria-aci-epg. Read PlaceVmIntoEpg_SingleScript.js first. Import the split actions into module com.essential.aci when a catalog form needs the EPG list on its own. Endpoints, tenants, and credentials are inputs. Confirm the VMM domain is already creating port groups before you run the first placement.
Conclusion
When a vendor plugin stops at a release you have already passed, the replacement is the one operation the catalog cannot finish. Everything else stays in the product that already owns it.
The single script and the split Orchestrator actions are in the repository. Endpoints, tenants, and credentials are inputs. Nothing in the files is a site value.
Repository: github.com/noahfarshad/aria-aci-epg
Related Stories:
- vRO Actions for Aria Automation — the same pattern, a blueprint that stops being enough
- From Aria Automation 8.18 to VCF Automation 9.1 — the platform those actions have to survive