vRealize Automation: the complete guide to versions, support, and VCF 9 upgrades
vRealize Automation is VMware’s infrastructure automation platform, which VMware renamed VMware Aria Automation at version 8.12 and now ships as VMware Cloud Foundation Automation inside VCF 9. Broadcom ended standalone licensing on 22 January 2024. Releases 8.18.0 and 8.18.1 hold general support until 11 October 2027, and every earlier release is already past it.
What vRealize Automation does
Platform teams run vRealize Automation to put infrastructure requests behind a self-service portal instead of a ticket queue. Developers and application owners pick an item from a service catalog, the request runs through an approval workflow, and the platform provisions it against whichever cloud account the policy allows, with nobody opening vCenter.
Underneath the catalog sits infrastructure as code. Teams called cloud templates blueprints before version 8 and authored them in Cloud Assembly before that became Automation Assembler. The templates describe a deployment as desired state in YAML, covering the machines, networks, storage, tags and the Day-2 actions a requester will be allowed to run later. Because the template is the source of truth, one definition can target on-premises vSphere. It can also target AWS and Azure, and Broadcom documents Google Cloud support as well, which is the multi-cloud reach across hybrid cloud estates that separated it from vCenter-only tooling.
Governance and compliance are why most organizations bought it. Approval chains, quota and lease policies, naming standards and tagging rules run inside the delivery path rather than as a review after the fact, so automated provisioning stays inside the guardrails the platform team set.
The same policies carry through infrastructure lifecycle management to the end of a deployment’s life.
- Leases expire, and Day-2 operations handle resizing and reassignment.
- Decommissioning and reclamation return capacity instead of leaving it stranded.
- Kubernetes and container management extend the same model to clusters and namespaces.
- Extensibility runs through Automation Orchestrator workflows and ABX actions.
- The REST API provides another path into the IPAM, CMDB and ITSM systems they already run, and lets DevOps teams put provisioning behind a pipeline.
All of it shipped inside the vRealize Suite, later the Aria Suite, and that packaging no longer exists.
Three names, one product
Broadcom’s KB 318130 is the authority on which name belongs to which release, and it draws the line at 8.12. It labels everything through 8.11.x vRealize Automation and versions 8.12 onward VMware Aria Automation. The last vRealize-branded release was 8.11.2 in March 2023 and the first Aria-branded release was 8.12 in April 2023. The numbering skips 8.15 entirely, which is worth knowing before anyone goes looking for it.
Two things about that rebrand get misattributed. VMware ran it, announcing the Aria brand at VMware Explore in August 2022 and shipping it with 8.12 in April 2023, more than a year before Broadcom’s acquisition closed in November 2023. Broadcom owns what came afterward, meaning the licensing decisions of January 2024 and the consolidation into VCF 9.
With VCF 9 the functionality moved into VMware Cloud Foundation Automation, which Broadcom does not sell on its own. The orchestrator took a different route: Broadcom calls it VCF Operations Orchestrator and files it under VCF Operations in the TechDocs hierarchy rather than under VCF Automation, though VCF Automation ships with an embedded, predeployed instance.
Support status and the 11 October 2027 deadline
Broadcom holds general support open for 8.18.0 and 8.18.1 until 11 October 2027, and everything released before those is already past it, so a team running 8.16 or 8.17 is unsupported today rather than in 2027.
That date carries more weight than a patching cutoff, because 8.18.1 is also the minimum source version Broadcom accepts for the Phase 3 upgrade into VCF Automation 9. Anything older has to reach 8.18.1 first as a prerequisite project. The destination is VMware Cloud Foundation 9, which turns the component upgrade into a platform-wide programme.
KB 318130 carries the master version and build table, with per-version notices in KB 326154, KB 325952, KB 325980, KB 346010 and KB 405284.
| Version | Product name | GA (on-prem) | End of general support |
|---|---|---|---|
| 8.0 | vRealize Automation | 17 Oct 2019 | 17 Oct 2021 |
| 8.1 | vRealize Automation | 14 Apr 2020 | 17 Oct 2021 |
| 8.2 | vRealize Automation | 2 Oct 2020 | 31 Oct 2022 |
| 8.3 | vRealize Automation | 5 Feb 2021 | 31 Oct 2022 |
| 8.4 | vRealize Automation | 15 Apr 2021 | 31 Oct 2022 |
| 8.5 | vRealize Automation | 19 Aug 2021 | 31 Oct 2022 |
| 8.6 | vRealize Automation | 12 Oct 2021 | 31 Oct 2022 |
| 8.7 | vRealize Automation | 22 Mar 2022 | 22 Mar 2023 |
| 8.8 | vRealize Automation | 28 Apr 2022 | 28 Apr 2023 |
| 8.8.2 | vRealize Automation | 28 Jul 2022 | Inherits 8.8 |
| 8.9 | vRealize Automation | 22 Aug 2022 | Not listed |
| 8.10 | vRealize Automation | 12 Oct 2022 | 11 Oct 2023 |
| 8.11 | vRealize Automation | 19 Jan 2023 | 19 Jan 2024 |
| 8.11.2 | vRealize Automation | 21 Mar 2023 | Inherits 8.11 |
| 8.12 | Aria Automation | 20 Apr 2023 | 20 Apr 2024 |
| 8.13 | Aria Automation | 3 Aug 2023 | 3 Aug 2024 |
| 8.14 | Aria Automation | 19 Oct 2023 | 19 Oct 2024 |
| 8.16.0 | Aria Automation | 16 Jan 2024 | 16 Jan 2025 |
| 8.16.1 | Aria Automation | 29 Feb 2024 | 20 Feb 2025 |
| 8.16.2 | Aria Automation | 21 Mar 2024 | 21 Mar 2025 |
| 8.17.0 | Aria Automation | 24 May 2024 | 9 May 2025 |
| 8.18.0 | Aria Automation | 23 Jul 2024 | 11 Oct 2027 |
| 8.18.1 | Aria Automation | 9 Oct 2024 | 11 Oct 2027 |
Broadcom lists end of general support at the parent-version level for some patch releases, so 8.8.2 and 8.11.2 take the dates of 8.8 and 8.11. Broadcom publishes no separate date for 8.9, and no 8.15 release exists.
The line opened on 17 October 2019 and closed with 8.18.1, and KB 403188 confirms 8.18.x as the final standalone release, so there is no 8.19 coming. The SaaS offering went first, with standalone Aria SaaS SKUs reaching end of availability on 12 December 2023 and the service itself ceasing on 6 December 2024, having stopped at release 8.16.0.
vRealize Automation licensing after Broadcom
Broadcom announced the end of availability for perpetual licensing and SaaS services on 22 January 2024, covering VMware vCloud Suite, VMware Aria Suite, Aria Universal Suite, Aria Suite Term, Aria Operations and Aria Automation. Perpetual sales and SnS renewals had already stopped on 11 December 2023. Existing licences remain in force on their existing terms, but the capabilities now ship only inside VMware vSphere Foundation and VMware Cloud Foundation, so renewal moves onto the foundation model whether or not the deployment changes.
Anyone reconciling old paperwork against current reality should know that Broadcom renamed vRealize Cloud Universal as Aria Universal Suite, and that the names vRealize Advanced and vRealize Enterprise Edition circulate on third-party pages without appearing in the January 2024 announcement or in any Broadcom SKU list. Broadcom’s Product Lifecycle Matrix, linked from KB 381187, tracks what survived.
Components, and what Broadcom calls them today
The component names in current documentation date from the Aria rebrand in April 2023, so anything written before then refers to Cloud Assembly and Service Broker. Older material also uses the SaltStack Config name. The mapping matters when reading older runbooks, and again when checking REST authentication or PowervRA compatibility.
| Component | Role |
|---|---|
| Automation Assembler | Where teams design and deploy cloud templates. |
| Automation Service Broker | Publishes the self-service catalog and enforces request policies. |
| Automation Config | Handles configuration management. Current Broadcom KBs such as KB 450985 call it VCF Salt. |
| Automation Orchestrator | Runs the workflow engine, renamed VCF Operations Orchestrator in VCF 9. |
In VCF Automation 9 those stopped being separate products. The VCF 9.0 release notes describe the Assembler, Service Broker and Orchestrator user interfaces as merged into one, with the old names surviving as backend service references that still turn up in API documentation. Broadcom organizes what replaced them around Cloud Services, Provider Management, Organization Management and vSphere Supervisor.
One component did not survive at all. Broadcom deprecated Automation Pipelines, formerly vRealize Code Stream, and KB 378424 names 8.18.1 as the last version supporting it, with Continuous Delivery Director as the portfolio replacement while the 8.18 release notes point to open-source tooling instead. Pages still listing it as a current component are out of date.
One thing to note is that VMware built this around private and hybrid cloud on vSphere, and while it provisions to AWS, Azure and Google Cloud too, the documented on-premises target has always been vSphere alone.
Integrations with Ansible, Terraform, ServiceNow and Kubernetes
Ansible arrives as two separate integrations in 8.18, Ansible Automation Platform, formerly Ansible Tower, and Ansible Open Source. Anyone maintaining templates should note that the 8.18 schema already marks jobTemplates as deprecated in favour of templates, which handles job templates and workflow job templates together.
Terraform runs inside a cloud template through the Cloud.Terraform.Configuration resource type, pointing at configuration files held in a version control repository. The integration accepts configuration files from GitHub or GitLab, and it accepts Bitbucket repositories too. Running it needs a Terraform runtime integration, which is a Kubernetes cluster that executes the Terraform CLI, and Broadcom supports only one runtime per organization, so every Terraform deployment there shares it.
ServiceNow integration comes through a Broadcom-authored plug-in distributed on the ServiceNow Store. It imports catalog items into ServiceNow so requesters never log into the automation product, supports approval groups, reconciles the CMDB, and carries Day-2 actions including custom ones.
Both continue into VCF Automation 9, and Broadcom limits the ServiceNow plug-in to VM Apps organizations. Kubernetes is the exception: container management exists across 8.x, but the VCF 9.0 Product Support Notes state plainly that Broadcom no longer supports TKG, PKS, OpenShift and TMC integrations.
vRealize Automation API authentication: why existing scripts stop working
Anything driving the platform through its API needs rework before it will run against VCF Automation 9, and the reason sits in the login flow rather than in the endpoints that do the work.
KB 346005 documents authentication on 8.x as a two-step exchange that catches people out the first time.
- Obtain a refresh token.
POST https://<vra-fqdn>/csp/gateway/am/api/login?access_token
{"username": "svc-automation", "password": "<password>", "domain": "corp.local"}2. Exchange it for a bearer token.
Read refresh_token from the response, then:
POST https://<vra-fqdn>/iaas/api/login
{"refreshToken": "<refresh_token>"}Read token and send it on every call as Authorization: Bearer <token> with Content-Type: application/json. The API token stays valid for 90 days while the bearer token expires after 25 minutes of inactivity, which is why scripts that pass in testing fail on long overnight runs.
VCF Automation 9 replaces that flow. Broadcom’s 9.1 documentation puts the tenant token at POST /tm/oauth/tenant/{tenant}/token with a form-urlencoded body carrying grant_type=refresh_token and the API token, and the resulting access token lasts an hour rather than 25 idle minutes. The /tm/ prefix is itself deprecated as of 9.0, with 9.1 preferring POST /oauth/provider/token for provider tokens. Every script written against the KB 346005 flow has to be reworked, which is a small and concrete illustration of why this move is re-platforming rather than a version bump.
PowervRA does not close that gap. The community PowerShell module’s most recent release, v6.0.0 from July 2023, supports vRA 8.12 and later through the /csp/gateway/am/api/login?access_token path, its README states that VMware does not support the project, and the repository documents no VCF Automation 9 support. Teams that automate the automation platform through PowervRA should plan on rebuilding that layer directly against the new API.
vRealize Automation architecture: how it accumulated
The product feels heavy to anyone who ran it before version 8 because successive VMware teams built it in stages rather than in one pass, adding endpoint agents, execution managers, Windows services, databases and high-availability pairs across a decade of releases and retaining each addition.
Cloud Automation Center provisioned across ESX and Hyper-V, reached Xen, and drove physical hardware through DRAC and iLO, with a separate connective agent for every target, and that agent-per-endpoint model outlived every rebrand until version 8. Under vCloud Automation Center the agents gave way to the Distributed Execution Manager, split into Workers that ran provisioning workflows and Orchestrators that tracked Worker state, with Orchestrators in active-passive pairs and one Worker per target platform, so provisioning into two vCenter servers meant two Workers while legacy proxy agents stayed behind for whatever the DEMs did not cover.
By vRealize Automation 7 a production deployment involved the vRA appliance, the IaaS website, the Model Manager, an external Microsoft SQL Server database, DEM Orchestrators, DEM Workers, proxy agents, vRealize Orchestrator in a pair, vRealize Business for costing and, where networking was in scope, NSX, most of it on separate Windows servers frequently doubled behind load balancers. VMware’s own 7.4 reference architecture needed a full page for the diagram. Deployment took weeks and troubleshooting took a specialist.
vRA 7 terms and their vRA 8 equivalents
Version 8 rewrote the vocabulary more than it rewrote the capabilities, which is why operators who learned the product on 7 still reach for a translation table. Moving between them was a migration rather than an upgrade, with a dedicated Migration Assistant and a separate guide for workflows and subscriptions. vRA 7 estates should also know that 8.18.1 removed 7.x migration support altogether, which leaves them without a supported route into VCF Automation 9 at all.
| vRA 7 term | vRA 8 equivalent |
|---|---|
| Blueprint | Cloud template (YAML) |
| Reservations and reservation policies | Cloud zones, storage policies, network policies |
| Property Dictionary and reserved properties | Resource Type Schema, with custom forms as the practical successor |
| vRealize Orchestrator | Automation Orchestrator |
| vRealize Code Stream | Automation Pipelines (deprecated, last supported in 8.18.1) |
| VMware Identity Manager | Workspace ONE Access (from roughly 8.10) |
| Business group | Project |
| Endpoints | Cloud accounts and integrations |
| Software components | Cloud-Init on Linux, Cloudbase-Init on Windows |
| Template | Image mapping |
| Component profile | Flavor mapping |
| Naming prefix | Custom naming template |
Our guide to vRealize Automation architecture walks through the components in more depth.
Capabilities that survived the move to 8
Third-party pages, and earlier versions of this one, describe vRA 8 as having dropped a list of capabilities it did not drop.
VMware has supported multi-organization tenancy since 8.1 in April 2020, and current Broadcom documentation describes a standard three-node deployment carrying up to 20 tenant organizations. It continues into VCF 9 through the organization model, where a migrated environment lands in a VM Apps organization, although the Product Support Notes withdraw the shared-infrastructure pieces including Virtual Private Zone and provider image management. Ansible Automation Platform integration, Resource Quota and Deployment Limit Policies, custom resources and Day-2 resource actions are all documented in 8.18 and all continue. VMware restructured the capabilities, with reservations and reservation policies becoming cloud zones with storage and network profiles, and the Property Dictionary becoming the Resource Type Schema.
One capability did come back smaller. Approval policies in 8.x dropped post levels, multi-levels, nested criteria, event-subscription integration, request-based approver determination, approver groups and email approvals, with criteria limited to cost, requestedBy, cpucount and memory, so a vRA 7 approval chain of any real sophistication is the thing least likely to survive reproduction.
Inside the upgrade to VCF Automation 9
Broadcom documents the move as Phase 3, Import and Upgrade Aria Automation 8 to VCF Automation 9, and runs the whole thing from VCF Operations. The minimum source version for the 9.1 path is 8.18.1, so anything older upgrades there first, and the separate convergence matrix requires 8.18.1 Patch 3 for the VCF convergence workflow.
Minimum requirements
| Area | Requirement or constraint |
|---|---|
| Certificate check | Replace the VMware Identity Manager certificate if it expires within one year of import. |
| Endpoint remediation | Review KB 389563 and the VCF 9.0 Product Support Notes for unsupported endpoints, itemised below. |
| IP and FQDN reservation | For 9.1 targets, reserve five sequential IPs in a unique CIDR, or five unique IPs on the existing Automation network, plus one new FQDN for the VCF services runtime. VCF Automation reuses the existing Automation UI FQDN. |
| Identity source | Aria Suite Lifecycle 8.x has to stay in place, because it runs the VMware Identity Manager that authenticates VCF Automation 9.x. |
| Fleet limit | Each VCF Operations fleet management appliance imports one Automation instance, so the rest need other fleets or VCF deployments. |
| Organization model | The migrated environment lands in a VM Apps organization, and an All Apps, Kubernetes-API build runs in parallel. |
| Licensing | VCF 9 licenses assign to vCenter instances from VCF Operations, and VCF Automation licenses automatically once it connects to a licensed vCenter. Subscription license files replace the 25-character keys, and usage reports run at least every 180 days. |
Endpoints you have to remediate first
Teams must decide how to replace or retire every unsupported integration before import:
- Automation Pipelines content. Retire or rebuild it, since VCF Automation 9 removes the component.
- TKG, PKS, OpenShift and TMC integrations. Decide where cluster provisioning goes, then remove them.
- NSX-V cloud accounts, and NSX-T accounts in manager mode. Policy mode is accepted, the rest is not.
- Avi Load Balancer cloud accounts, and VMware Cloud Director accounts. Both removed in 9.0.
The sequence itself runs from VCF Operations: import through Fleet Management > Lifecycle with Import from legacy Fleet Management, which moves control to VCF Operations; create an upgrade plan mapping the binary and target version; trigger an inventory sync, which opens the upgrade wizard; supply the IPs and one password for the vmware-system-user and admin accounts; run prechecks and remediate until they come back clean; then submit.
The mechanism is blue-green, so VCF Operations deploys a fresh instance alongside the live one and migrates data and configuration. It then switches traffic and shuts down the source nodes automatically, and the cutover carries a real downtime window to plan and communicate like any other maintenance event. The upgrade itself runs in roughly an hour once prerequisites are met, which is why the calendar goes almost entirely into preparation. For an estate carrying years of accumulated endpoints, integrations and custom extensibility, that preparation is measured in months.
The Automation upgrade also sits inside a wider VCF 9 platform move, and CloudBolt’s VCF 9 upgrade guide covers the platform prerequisites and the failure modes teams hit most, starting with DNS hygiene.
Will your existing workloads carry over
The virtual machines come across. VCF Automation 9 supports existing VM workloads provisioned on vSphere, and nothing in the upgrade asks a team to rebuild or re-provision them. The distinction worth holding onto is between those workloads and the constructs wrapped around them, because Automation Pipelines content, the Kubernetes integrations, NSX-V accounts, NSX-T accounts in manager mode and Avi Load Balancer accounts are all unsupported and have to be dealt with before import. The VMs survive the move while a meaningful slice of the automation around them does not.
Weighing the move against staying
Teams can upgrade to VCF Automation 9, remain on 8.18.x, or move the automation layer somewhere vendor-neutral. Each path carries a cost.
Upgrading into VCF Automation 9 means accepting VCF packaging and pricing at renewal and paying for the upgrade in engineering time, covering the prerequisite hop to 8.18.1, the remediation queue, the certificate and networking work, and the rebuild of whatever sits on the unsupported list. Staying on 8.18.x past 11 October 2027 defers that spend and replaces it with audit exposure and the cyber insurance implications of running unsupported software. Moving the automation layer somewhere vendor-neutral costs a rebuild of its own, and buys the ability to make the next infrastructure decision without repeating the exercise. Option three has a cheap first step: run your own catalog and approval chain in CloudBolt CMP, free for up to 100 resources, before committing to a rebuild.
CloudBolt commissioned an independent research firm to field the CII Reality Report 2026, “The Mass VMware Exodus That Never Was: The Squeeze Is Just Beginning,” in January 2026, surveying 302 IT decision-makers at director level and above with primary decision-making authority at North American organizations of 1,000 or more employees. It found that 86% are actively reducing their VMware footprint while 4% have completed a full migration away, a pairing that describes the market better than either figure alone. On cost, 85% are concerned about future increases and 59% have already absorbed increases above 25%, measured against a 2024 baseline in which 73% expected increases of 100% or more and 14% got them, and 63% have changed strategy two or more times since the acquisition. Because that baseline was taken six months after the acquisition closed, the study measures change over time rather than offering a snapshot.
After the migration decision, 52% now name multi-platform complexity as a new challenge, and 33% name skills gaps.
What VMware migration plans usually miss
Migration teams build plans around workloads, and their tools do not move the automation layer. Platform teams encode cloud templates, custom Orchestrator workflows, ABX actions, approval logic, naming templates, IPAM and CMDB integrations and Day-2 operations in formats specific to this product, and no tool converts those assets automatically, so engineers redesign or rebuild each one by hand.
Moving VMs to another hypervisor has mature tooling behind it. Moving years of accumulated provisioning logic does not, and the gap usually surfaces after project leaders have already scoped and budgeted the workload migration. At that point the same people keeping production running are also staffing a second project nobody sized.
Where CloudBolt CMP fits
CloudBolt CMP is the control and orchestration layer above the infrastructure, connecting vSphere alongside AWS, Azure, Google Cloud, Nutanix, Hyper-V, OpenStack, OpenShift and Kubernetes through one control plane. Blueprints carry approval chains and cost limits. They also carry tagging and post-deployment actions, so enforcement runs inside the delivery path rather than as a review behind it. CMP calls Terraform and Ansible underneath, where Terraform still provisions and Ansible still configures, and CMP applies the business rules and lifecycle controls around both.
The layer is vendor-neutral by design, so an infrastructure decision does not invalidate the automation built on top of it, and extensibility is standard Python, which keeps business logic portable and Git-backed.
VCF Automation 9 changes the APIs and blueprint model, so teams must rebuild the automation layer either way. A team already committed to that work has a natural moment to decide whether the rebuilt layer should be VMware-specific at all. Rebuilding into a stack the organization may need to leave again is the outcome worth avoiding. That makes CMP a practical fit for teams already running something besides VMware, and for teams that want to test alternative hypervisors alongside their existing automation before committing.
Decision plan
- Inventory the current estate. Record the deployed version, license terms, identity dependencies, cloud accounts, integrations, Automation Pipelines content, workflows, and the external systems that participate in provisioning or Day-2 actions.
- Remediate upgrade blockers. Move supported environments to 8.18.1, replace certificates expiring within a year, work the KB 389563 list, reserve the VCF Automation 9 networking, and decide how to replace unsupported endpoints and integrations.
- Validate the target workflow. Run Phase 3 prechecks, then test authentication, catalog requests, policies, external integrations and Day-2 actions before switching production traffic. If another platform is under consideration, test the same representative workflows there instead of comparing feature lists.
- Make the stay-or-exit decision. Compare the validated VCF Automation 9 path against the cost and effort of rebuilding the automation layer elsewhere, and land it before 11 October 2027.
Test a vendor-neutral automation layer before October 2027
Get CloudBolt CMP free
FAQ
Is vRealize Automation discontinued?
As a standalone product, yes. Perpetual sales and SnS renewals stopped on 11 December 2023, the 22 January 2024 announcement retired the Aria Suite, Aria Universal Suite, Aria Automation, Aria Operations and vCloud Suite SKUs, and the final release was Aria Automation 8.18.1 on 9 October 2024. Existing licences stay valid on their existing terms. The functionality continues as VMware Cloud Foundation Automation inside VCF 9, and Broadcom supports 8.18.x until 11 October 2027.
What’s the difference between vRealize Automation and Aria Automation?
Only the name. Broadcom KB 318130 labels versions through 8.11.x vRealize Automation and versions 8.12 through 8.18.1 VMware Aria Automation. VMware rebranded the product in April 2023, more than a year before the Broadcom acquisition closed.
Which product replaced vRealize Automation?
VMware Cloud Foundation Automation, a component of VCF 9 organized around Cloud Services, Provider Management, Organization Management and vSphere Supervisor. Broadcom does not sell it separately, and the capabilities ship inside VMware Cloud Foundation and VMware vSphere Foundation.
Are vRealize Automation and vRealize Orchestrator the same product?
Orchestrator is the workflow engine that vRealize Automation calls for extensibility. It became Automation Orchestrator in 8.x and is now VCF Operations Orchestrator in VCF 9, filed under VCF Operations, though VCF Automation embeds a predeployed instance.
Can I still get support for vRA 8?
Broadcom supports only 8.18.0 and 8.18.1, both until 11 October 2027. Every release from 8.0 through 8.17.0 is out of general support, as is all of vRA 7.x, and the SaaS service ceased on 6 December 2024.
Did vRA 8 remove features that vRA 7 had?
Less than commonly claimed. Multi-organization tenancy, Ansible integration, resource quota policies and custom Day-2 actions all exist in 8.x, and constructs such as reservations were restructured into cloud zones rather than removed. Approval policies are the real reduction, losing post levels, multi-levels, nested criteria and email approvals. Kubernetes integrations also exist in 8.x, though TKG, PKS, OpenShift and TMC do not carry into VCF Automation 9.
How does vRealize Automation integrate with Ansible, Terraform and ServiceNow?
Ansible Automation Platform and Ansible Open Source are both documented in 8.18. Terraform runs inside a cloud template through the Cloud.Terraform.Configuration resource type, backed by a runtime integration that executes the CLI on a Kubernetes cluster, one per organization. ServiceNow integration comes through a Broadcom plug-in on the ServiceNow Store that imports catalog items, supports approval groups, reconciles the CMDB and carries Day-2 actions. All three continue into VCF Automation 9, with the ServiceNow plug-in limited to VM Apps organizations.
Does vRealize Automation support non-VMware hypervisors?
Broadcom documents vSphere, AWS, Azure and Google Cloud as the provisioning targets, with vSphere the only documented on-premises hypervisor. VCF Automation 9 aligns more tightly with VMware’s private-cloud stack, so a mixed estate running Nutanix, Hyper-V or OpenStack alongside VMware needs a separate automation layer to cover the rest.
Related Blogs
VMware Aria alternative for VCF 9: Aria vs CMP – Part 2
Part 2 of 3. Read Part 1: why companies are making the move | Read Part 3: testing VMware alternatives…
