VCF Automation 9.x Explained: Traditional VM Provisioning, Supervisor Based Consumption, and the New Tenant Model

Introduction

VCF Automation 9.x is easy to misunderstand if your mental model was built around vRealize Automation or Aria Automation. The familiar product lineage is still present, but the platform now exposes two materially different consumption paths. One path preserves the established VM-centric automation model. The other places organizations, projects, vSphere Namespaces, and Supervisor-backed services at the center of private cloud consumption.

That distinction is more important than the product rename. It changes how architects define tenancy, allocate capacity, structure networks, delegate administration, publish services, and decide where policy is enforced. It also changes what a virtual machine represents operationally. A VM can still be delivered through a traditional template and deployment workflow, or it can be delivered through VM Service as a declarative resource governed through a namespace and the Kubernetes API.

This article translates VCF Automation 9.x into concepts familiar to architects who worked with vRealize Automation and Aria Automation. It explains both the infrastructure-provider and consumer perspectives, shows where the two operating models overlap, and identifies where they should remain deliberately separate. The source baseline is VCF 9.1 documentation and current Broadcom guidance available on July 24, 2026. Version-sensitive restrictions should still be revalidated against the exact VCF Automation build planned for deployment. [1], [2]

TL;DR

VCF Automation 9.x is not simply Aria Automation with a new name and interface. It is a provider-oriented private cloud automation platform with two consumption models:

• VCF Automation for VM Apps preserves the mature Aria-style model built around cloud accounts, cloud zones, projects, templates, deployments, catalog items, approval policies, and established integrations.
• VCF Automation for All Apps introduces a new tenant model built around provider organizations, Regions, Region Quotas, Projects, Namespace Classes, vSphere Namespaces, VM Service, VKS, and other Supervisor-backed services.
• Traditional VM provisioning is the better choice when compatibility with existing Aria content, public-cloud endpoints, custom forms, ABX, event subscriptions, IPAM, ServiceNow, and mature day-2 automation matters more than adopting a namespace-led platform model.
• Supervisor-based consumption is the better choice when the target is a modern internal developer platform that must deliver VMs, Kubernetes clusters, GPU-backed compute, data services, or AI services through consistent projects, namespaces, APIs, policies, and quotas.
• Imported Aria Automation environments remain a VM Apps continuity lane. Importing and upgrading does not automatically convert existing projects, templates, integrations, tenants, or deployments into the All Apps model.
• Bimodal operation is valid, but it must be designed as two controlled service lanes. Architects should not assume that the same infrastructure assignment, network design, policy model, or integration can be shared transparently between VM Apps and All Apps.

The practical recommendation is to preserve VM Apps where it protects proven automation investments, build All Apps for new namespace-based services, and migrate individual service offerings only when their governance, networking, identity, content, and day-2 requirements have been reproduced and validated in the new model.

Scope, Version Baseline, and Terminology Guardrails

This article focuses on the VCF Automation operating model in the VCF 9.x release family, with current terminology aligned to VCF 9.1. It covers provider and tenant architecture, VM and Kubernetes consumption, policy, catalog, identity, networking, extensibility, and migration from Aria Automation.

It does not attempt to document every screen, API field, or patch-specific limitation. VCF Automation is evolving quickly, and some capabilities differ between 9.0, 9.0.x, 9.1, and asynchronous component releases. Product documentation, release notes, and support guidance should govern the final design. Community discussions are useful for identifying real architectural questions, but they are not substitutes for supported design documentation. [2], [3], [4]

Several terms need guardrails before the comparison begins:

• VCF Automation is the current product name for the automation capability formerly known as VMware Aria Automation. [1]
• VM Apps organization is the VCF Automation organization type that preserves the established Aria Automation VM provisioning model.
• All Apps organization is the organization type intended to consume a broader set of services through the VCF Automation provider and organization model, including Supervisor-backed VM and Kubernetes services.
• Traditional VM provisioning means the cloud-account, cloud-zone, project, template, deployment, and catalog model inherited from Aria Automation.
• Supervisor-based consumption means that vSphere Supervisor and Kubernetes-style APIs participate in infrastructure delivery and governance.
• VM Service VM is still a vSphere virtual machine. Kubernetes provides the declarative control interface and lifecycle object model. The guest workload is not converted into a container or a pod.
• Tenant is used here as an architectural boundary. In VCF Automation, the formal top-level tenant or line-of-business construct is an organization.

The Shortest Possible Translation

Architects coming from Aria Automation can use the following summary as an initial map:

The most important correction is this: All Apps does not replace VMs with Kubernetes. It uses Kubernetes constructs to standardize how infrastructure services, including VMs, are requested and governed. VM Apps remains a supported VM-centric automation path in VCF Automation 9.0 and 9.1. [5], [6]

VCF Automation Is a Two-Track Operating Model

The platform is easiest to understand as two consumption tracks below one provider-oriented automation service. The tracks can coexist, but they do not have identical resource models, integrations, or governance semantics.

What the diagram should make clear is that the difference is not simply which button creates a VM. The two tracks represent different control-plane assumptions.

The VM Apps track assumes the automation platform owns a set of cloud endpoints and exposes governed deployments to projects. The All Apps track assumes the provider exposes capacity and services to organizations, and that projects and namespaces become the consumer-facing boundaries through which infrastructure is requested.

This distinction affects almost every design decision that follows.

Provider and Tenant Responsibilities

Aria Automation administrators often performed both platform administration and tenant configuration in the same conceptual product space. VCF Automation 9.x makes the provider role more explicit. The default provider organization is named System, and the Provider Management UI is the administrative interface used to create and govern consumer organizations. Broadcom clarified this provider context in both documentation and the community discussion that followed early VCF 9.0 deployments. [7], [8]

Infrastructure-provider responsibilities

The provider team operates the private cloud supply side. Typical responsibilities include:

• Deploying, patching, monitoring, backing up, and recovering VCF Automation.
• Managing the System provider organization and provider administrators.
• Integrating enterprise identity providers and defining provider-level roles.
• Registering and exposing infrastructure capacity through Regions and related provider constructs.
• Enabling and operating vSphere Supervisor where All Apps consumption is required.
• Designing NSX, VPC, subnet, external connectivity, load-balancing, IPAM, DNS, certificate, and security services.
• Creating organizations and assigning Region Quotas or other capacity entitlements.
• Publishing or enabling shared orchestration, content, service, and observability capabilities.
• Defining platform-wide guardrails, support boundaries, service classes, and chargeback or showback inputs.
• Deciding which workload domains or infrastructure pools support VM Apps, All Apps, or a deliberately separated bimodal design.

Organization and consumer responsibilities

The organization team operates within the boundary assigned by the provider. Responsibilities vary by delegated role, but commonly include:

• Managing organization users, groups, and role assignments.
• Creating and managing projects.
• Consuming or subdividing assigned Region Quotas.
• Selecting or administering Namespace Classes.
• Creating and governing vSphere Namespaces when delegation is enabled.
• Curating project content libraries, images, blueprints, and catalog items where permitted.
• Applying organization or project policies.
• Managing application deployments and authorized day-2 operations.
• Operating VKS clusters, VM Service workloads, or catalog-based VM Apps deployments within the assigned service boundary.
• Providing application-level ownership, data protection requirements, monitoring, and support escalation information.

Responsibility boundary

The operating-model lesson is that VCF Automation should not be deployed as a portal first and governed later. Provider and organization responsibilities must be agreed before services are published, because those responsibilities are encoded into the organization, quota, project, namespace, identity, and network structure.

How Organizations, Projects, Namespaces, and Catalogs Fit Together

The new tenant model becomes much clearer when the constructs are placed in order.

Organization

An organization is the top-level consumer isolation boundary. It normally represents a tenant, business unit, line of business, regulated boundary, customer, or other major administrative partition. Broadcom describes the organization as the top-level construct created by the provider administrator, with Projects and Namespaces subdividing resources for application teams. [9]

An organization should be large enough to justify separate identity, quota, policy, catalog, and support boundaries. Creating an organization for every application usually produces unnecessary administrative fragmentation. Using one organization for the entire enterprise can create the opposite problem by weakening delegation and chargeback boundaries.

Region and Region Quota

A Region is a provider abstraction over infrastructure capable of hosting organization workloads. In the All Apps model, the Region and Region Quota are part of the supply contract between provider and organization. The provider exposes eligible capacity, and the organization receives a controlled entitlement rather than direct administrative control over the underlying workload domain.

A Region Quota is not merely a CPU and memory number. It is also a governance and placement boundary. It determines which organization can consume which regional resources, under what reservations or limits, and through which approved services.

Project

A Project groups users, resources, policies, and service consumption around a team or workload purpose. Projects remain familiar to Aria Automation users, but their context is broader in All Apps. A Project can become the collaboration and delegation point for namespace-backed infrastructure, project content libraries, blueprints, policies, and service access. [10]

A useful project model is usually aligned to a product team, application portfolio, environment boundary, or platform service consumer group. Projects should not be used as a substitute for every other boundary. Regulated separation, customer isolation, or fundamentally different identity ownership may justify separate organizations instead.

Namespace Class

A Namespace Class is an approved pattern for namespace creation. It lets the provider or organization define which storage, networking, capacity, service, and security characteristics are available to consumers. The class becomes a guardrail for self-service rather than requiring every project administrator to understand the complete infrastructure design.

The class is where architects can encode service tiers such as:

• General-purpose application namespace.
• Regulated namespace with restricted networking and storage.
• GPU-enabled namespace with approved VM classes.
• Development namespace with lower quotas and shorter leases.
• Production namespace with stronger reservations, monitoring, and backup requirements.

vSphere Namespace

The vSphere Namespace is the execution and enforcement boundary for Supervisor-backed consumption. It is where infrastructure quota, Kubernetes RBAC, storage policies, networking, service access, and workload objects converge. The namespace is therefore more than a folder or naming construct. It becomes a service boundary shared by infrastructure and application teams. [11]

Catalog

The catalog is the user-facing consumption layer. It can expose VM templates, blueprints, workflows, and other services, but it is not the fundamental resource boundary. A catalog item should be treated as a governed product interface built on top of organization, project, quota, namespace, network, image, and policy decisions.

This distinction prevents a common design error: assuming that publishing a form creates a service. A real service also needs capacity ownership, entitlement, lifecycle, observability, data protection, cost, support, and decommissioning rules.

Traditional VM Provisioning Through VM Apps

VCF Automation for VM Apps is the closest continuation of Aria Automation 8.x. It is built around cloud accounts, cloud zones, projects, mappings, templates, catalog items, deployments, policies, and extensibility.

How the traditional path works

A typical VM Apps request follows this sequence:

1. A cloud administrator configures a vSphere or public-cloud account.
2. Eligible compute, storage, and network resources are grouped and constrained through cloud zones, profiles, tags, and mappings.
3. A project receives access to one or more zones and associated limits.
4. A template defines the requested machine, network, storage, customization, and optional application components.
5. The template or another content source is published to the catalog.
6. A user submits the request through the catalog, API, or infrastructure-as-code workflow.
7. Approval, lease, deployment-limit, quota, and other policies are evaluated.
8. VCF Automation provisions the deployment and invokes configured extensibility subscriptions.
9. Authorized day-2 actions remain available through deployment and resource actions.

This is recognizable to anyone who designed Cloud Assembly, Service Broker, and Code Stream workflows. The names and surrounding platform have changed, but the underlying service pattern remains familiar.

Where VM Apps remains the right answer

VM Apps is usually the stronger choice when one or more of the following are true:

• The organization has a large, proven Aria Automation estate with production templates, custom forms, property groups, image mappings, flavor mappings, cloud-zone tags, subscriptions, ABX actions, and Orchestrator workflows.
• Public-cloud accounts or heterogeneous endpoints are part of the service catalog.
• Existing integrations with IPAM, DNS, ServiceNow, Ansible, Git, configuration-management platforms, secrets systems, or ticketing workflows are business-critical.
• The service requires complex form logic or highly customized deployment-time inputs.
• The current governance process depends on established approval, lease, deployment-limit, resource-quota, and day-2 action policy behavior.
• vSphere Supervisor is not enabled, not yet operationally accepted, or not appropriate for the target infrastructure.
• The requested outcome is primarily VM lifecycle automation rather than a unified VM, Kubernetes, data, GPU, and AI service platform.
• A migration program must protect service continuity before redesigning the operating model.

What VM Apps does not provide by itself

VM Apps should not be mistaken for the complete VCF Automation 9.x target model. It does not make namespaces the universal execution boundary, and it does not automatically create a consistent Kubernetes-style API across VMs, VKS clusters, networking, and adjacent services.

It also carries tenancy and management constraints that must be understood. Broadcom currently documents that the VCF Automation 9.0 and 9.1 UI supports creating only one classic VM Apps organization, although additional VM Apps organizations can be created through the REST API. That is not a minor interface detail for service providers or large enterprises. It affects tenant onboarding, automation, support procedures, and the design of imported multi-tenant Aria environments. [12]

The correct posture is not to dismiss VM Apps as obsolete or assume an undocumented deprecation. It remains supported and operationally valuable. The correct posture is to recognize that it is a distinct consumption model with different strengths from All Apps.

Supervisor-Based Consumption Through All Apps

The All Apps model is the more substantial architectural shift. It uses vSphere Supervisor and Kubernetes-style APIs to expose infrastructure services through Regions, Projects, Namespace Classes, vSphere Namespaces, and service-specific resources.

The role of vSphere Supervisor

The Supervisor connects the VCF Automation consumption model to vSphere infrastructure and services. Broadcom describes the Supervisor as the component that owns the physical infrastructure resources used to run organization workloads. VCF Automation then abstracts eligible Supervisors and infrastructure through Regions, quotas, projects, classes, and namespaces. [11]

The Supervisor provides several capabilities that materially change the service model:

• A Kubernetes API surface for infrastructure resources.
• vSphere Namespaces as policy and tenancy boundaries.
• VM classes, images, storage policies, and networking exposed through VM Service.
• Lifecycle-managed Kubernetes clusters through VKS.
• Consistent integration points for policy, identity, quota, and declarative automation.
• A foundation for adjacent platform services, including GPU-enabled compute, data services, and private AI capabilities where licensed and configured.

VM Service

VM Service exposes vSphere-backed virtual machines through declarative resources. A consumer selects an approved VM class, image, storage policy, network configuration, and namespace context. The platform creates and manages the VM while enforcing provider and organization controls. [5]

This does not eliminate vSphere. It makes vSphere infrastructure consumable through a Kubernetes-native control model.

The operational differences are significant:

• The namespace, not only the automation project, participates in access and resource control.
• VM classes replace some traditional flavor-selection patterns.
• Content libraries and VM images become part of the service supply chain.
• Kubernetes RBAC and infrastructure RBAC must be designed together.
• Admission policies can validate resource requests before the workload is created.
• kubectl, VCF CLI, Terraform, API clients, or catalog blueprints can become legitimate consumption interfaces.

VKS consumption

The vSphere Kubernetes Service provides lifecycle-managed, upstream-compatible Kubernetes clusters as first-class VCF resources. In the All Apps model, a project can request a VKS cluster within an approved namespace and service boundary. Networking, storage, identity, resource limits, cluster classes, and lifecycle behavior are inherited from the surrounding VCF design. [5]

The provider still owns the infrastructure and service supply chain. The consumer owns cluster-level use, application deployment, and any responsibilities not explicitly included in the platform service. A CaaS offering therefore needs a clear line between:

• Supervisor and VKS lifecycle.
• Cluster configuration and supported versions.
• Worker-node images and capacity.
• Ingress, load balancing, DNS, certificates, and egress.
• Kubernetes platform add-ons.
• Application namespaces inside the VKS cluster.
• Backup, restore, observability, and incident escalation.

Where All Apps is the better answer

All Apps is generally the stronger choice when the target architecture requires:

• A new multi-tenant private cloud service rather than a direct recreation of Aria Automation.
• Unified delivery of VM, Kubernetes, GPU, data, and AI services.
• Namespace-based isolation and delegated platform administration.
• Declarative consumption through Kubernetes APIs, Terraform, VCF CLI, and GitOps workflows.
• Consistent provider, organization, project, and namespace hierarchy.
• Policy-as-code for infrastructure resource validation.
• Standardized service classes instead of unrestricted infrastructure selection.
• Project-scoped content and delegated platform-engineering workflows.
• A service catalog that composes multiple runtime and infrastructure services.
• Stronger alignment between infrastructure automation and modern application delivery.

The All Apps path is not automatically simpler. It replaces some familiar automation complexity with platform-engineering complexity. The organization must be ready to operate Supervisor, Kubernetes-style APIs, namespaces, VPC networking, content supply chains, policy-as-code, and a more explicit provider-consumer model.

Traditional VM Provisioning Versus Supervisor-Based Consumption

The following comparison focuses on architectural fit rather than attempting to declare a universal winner.

A useful decision rule is this: select the model based on the service contract, not the workload label. A Windows or Linux VM may fit All Apps when it is part of a namespace-based application platform. A Kubernetes worker node or appliance may fit a traditional deployment workflow when the service depends on established Aria integrations and lifecycle logic. The VM-versus-container distinction alone is not sufficient.

VMaaS, CaaS, GPUaaS, and AIaaS Patterns

VCF Automation can support several service patterns, but the acronym should describe what the consumer receives, not merely what infrastructure exists underneath.

VMaaS is not one implementation

VMaaS can be delivered through both paths. Traditional VMaaS may expose a request form backed by a VCF Automation template, an approval, an IPAM reservation, guest customization, configuration management, backup enrollment, and a ServiceNow record. Supervisor-based VMaaS may expose an approved VM class and image inside a namespace, with policy enforced through quota and admission controls.

The consumer may perceive both as “request a VM,” but the provider operating model is different. The correct design depends on which workflow, control points, APIs, and support boundaries the service requires.

CaaS requires more than cluster creation

A VKS cluster is not a complete CaaS product by itself. A production CaaS offering also needs:

• Supported cluster versions and upgrade policy.
• Node class and scaling limits.
• Network, DNS, ingress, load balancing, egress, and proxy design.
• Registry access and image policy.
• Secrets and certificate integration.
• Monitoring, logging, alerting, and audit retention.
• Backup and recovery expectations.
• Platform add-on ownership.
• Incident and support escalation.

VCF Automation can expose the request and enforce the infrastructure boundary, but the service owner must define the complete product.

GPUaaS and AIaaS are composed services

Broadcom positions VMware Private AI Foundation with NVIDIA as a foundation for GPU-backed development and private AI services. GPUaaS may be implemented through Deep Learning VMs, vGPU profiles, GPU-enabled VM classes, or Kubernetes-based AI runtimes. AIaaS may expose model, inference, data-indexing, or agent capabilities rather than raw GPUs. [13]

The important design distinction is between allocation mechanism and service abstraction. A vGPU profile is not a GPUaaS operating model. A model container is not an AIaaS operating model. VCF Automation provides the catalog, policy, identity, quota, namespace, and orchestration framework that can turn those technical components into governed services.

Identity and RBAC Across the New Tenant Model

Identity design becomes more layered in VCF Automation 9.x because users may interact with provider management, organization management, projects, namespaces, the Kubernetes API, VKS clusters, and guest workloads.

Provider identity

Provider administrators operate through the System organization and Provider Management UI. This role should be tightly controlled because it can create organizations, expose capacity, configure networking, manage provider groups, and influence the entire tenant estate. [7], [8]

Provider administration should use:

• Federated enterprise identity where supported and operationally accepted.
• Named administrative accounts rather than shared accounts.
• Privileged-access workflows and time-bound elevation where available.
• Separation between platform administration, identity administration, network administration, and support roles.
• Break-glass credentials stored, monitored, and tested through an approved process.

Organization and project identity

Organization administrators manage the consumer boundary. Project roles should then delegate the minimum rights required to application teams, platform engineers, catalog curators, and operators. VCF Automation includes predefined roles for the All Apps experience, but architects should still map those roles to real enterprise personas and support procedures. [14]

A practical persona model might include:

• Organization Administrator: manages projects, delegated policy, content, identity mappings, and organization-level service configuration.
• Project Administrator: manages project membership, project-scoped resources, and delegated namespaces.
• Platform Engineer: builds images, blueprints, VKS patterns, VM classes, or application stacks within an approved scope.
• Application Operator: deploys and operates authorized services but cannot alter provider guardrails.
• Auditor or Read-Only Operator: reviews configuration, deployment state, cost, events, and policy evidence.

Kubernetes RBAC and infrastructure RBAC

In the All Apps model, a user may have permission to request a namespace but not administer every resource inside it. Another user may have Kubernetes rights inside the namespace but no VCF Automation organization-administration rights. A VKS cluster introduces another RBAC layer inside the guest cluster.

Architects should explicitly document:

• Who may create a Project.
• Who may request or create a vSphere Namespace.
• Who may bind users and groups to the namespace.
• Who may create VM Service resources.
• Who may create or administer VKS clusters.
• Who receives cluster-admin inside a VKS cluster.
• Who may change catalog, blueprint, content, or policy definitions.
• Which actions require approval or privileged elevation.

Without this mapping, self-service often becomes accidental privilege expansion.

Quotas, Policy, and Governance

VCF Automation 9.x has multiple policy and quota mechanisms because the two consumption models enforce governance at different layers.

VM Apps governance

VM Apps retains familiar policy types such as:

• Approval policies.
• Lease policies.
• Deployment-limit policies.
• Resource-quota policies.
• Day-2 action policies.
• Project limits and zone-based allocation.
• Template constraints, tags, mappings, and profiles.

These controls are mature and often embedded into existing enterprise processes. Approval policies can govern both initial deployment and day-2 requests before execution. Resource quota policies can limit consumption by user, project, or organization. [15], [16]

All Apps governance

All Apps adds a different enforcement hierarchy:

• Provider capacity is exposed through Regions.
• Organizations receive Region Quotas.
• Projects group users, policies, content, and namespaces.
• Namespace Classes constrain the shape of namespaces.
• vSphere Namespaces enforce resource, storage, network, and service boundaries.
• IaaS resource policies can validate Kubernetes-style infrastructure resources.
• Approval, lease, and day-2 controls can govern catalog and lifecycle actions.
• Kubernetes RBAC and admission controls participate in authorization and validation.

Broadcom introduced IaaS resource policies using Kubernetes Validating Admission Policy concepts and CEL expressions. These policies can evaluate infrastructure resources such as VM Service VMs and VKS clusters before admission. [17], [18]

A layered policy model

A mature design should classify controls into layers:

The important operational implication is that duplicated controls can conflict. A request may satisfy a catalog approval but fail namespace quota. It may pass quota but fail an admission rule. It may create successfully but fail a downstream DNS or configuration-management workflow.

Every published service should therefore document the order of policy evaluation and the diagnostic owner for each failure stage.

Networking and NSX Dependencies

Networking is one of the strongest reasons the VM Apps versus All Apps decision must be made early. The choice can affect workload-domain design, Supervisor enablement, NSX topology, VPCs, subnets, routing, ingress, load balancing, IPAM, DNS, and security operations.

VM Apps networking

VM Apps uses the familiar cloud-account and cloud-zone networking model. Depending on the endpoint and integration, architects may use:

• Existing vSphere networks.
• NSX-backed networks and security groups.
• Network profiles and tags.
• Static or external IPAM.
• Provider-specific IPAM integrations.
• Custom workflow-based DNS or firewall automation.
• Public-cloud networks for non-vSphere endpoints.

This flexibility is valuable when the enterprise has established network integrations or must automate heterogeneous environments.

All Apps networking

All Apps consumption is tightly related to the Supervisor and provider networking design. The provider may expose NSX VPC-backed networking, organization-level networks, subnets, gateway services, and other approved connectivity patterns. The namespace and requested service then consume networking within that provider-defined boundary. [19], [20]

The design must answer:

• Which Supervisor networking model is used.
• Which NSX VPCs, subnets, or organization networks are available to each organization.
• How routing reaches shared services, external networks, and legacy VLANs.
• How IP addresses are allocated and reclaimed.
• How DNS records and certificates are created.
• Which load-balancing or ingress service is offered.
• How north-south and east-west policy is enforced.
• How overlapping address space is prevented between organizations and projects.
• How proxy and egress restrictions affect VKS, container registries, OS repositories, and AI model access.
• Who owns troubleshooting across the provider gateway, namespace, VKS cluster, guest OS, and application layers.

NSX is not a checkbox

All Apps does not merely add an NSX dependency to an existing Aria design. It changes how networking is consumed and delegated. The provider must create a network product that is safe for tenant self-service. That means standardized subnet patterns, route control, firewall ownership, address management, observability, and support boundaries.

A greenfield All Apps deployment that ignores network operating procedures is not production-ready, even if the first VM Service VM or VKS cluster provisions successfully.

Image, Template, Blueprint, and Catalog Management

The content model also changes between the two paths.

VM Apps content

VM Apps commonly uses:

• vSphere templates and snapshots.
• Image and flavor mappings.
• Cloud templates.
• Property groups.
• Custom forms.
• Git-backed template sources.
• Orchestrator workflows.
• Catalog entitlements and content sources.

The primary challenge is lifecycle coordination. A template version, guest customization specification, configuration-management playbook, IPAM workflow, and catalog form may all need to change together.

All Apps content

All Apps expands the content supply chain to include:

• Content Hub.
• Organization and project content libraries.
• VM images used by VM Service.
• Blueprints that compose namespaces, VMs, VKS clusters, networks, and services.
• Namespace Classes.
• VM classes and service-specific classes.
• Terraform configurations and API-driven resources.
• Catalog items built from blueprints, images, workflows, and services.

VCF Automation 9.1 supports project-scoped content libraries, allowing organization administrators to scope content management to selected projects and delegate image publishing more closely to platform teams. [21]

Content governance questions

For each content type, define:

• Who builds it.
• Who validates it.
• Who signs or approves it.
• Where it is stored.
• How versions are promoted.
• Which projects can consume it.
• How vulnerabilities are handled.
• How rollback works.
• When it is retired.
• Which deployed workloads depend on it.

A content library is not a release process. A blueprint is not automatically a supported service. The content supply chain needs ownership, evidence, and lifecycle controls just like application code.

Imported Aria Automation Environments

The import and upgrade path is one of the areas most likely to be oversimplified.

Broadcom documents an upgrade sequence in which an existing Aria Automation 8.18.1 or later instance is first imported into VCF Operations and then upgraded to VCF Automation 9.1. [22]

The community discussion about this path reached an important practical conclusion: an imported Aria Automation environment should be understood as a VM Apps organization, preserving the VM-centric operating model. The greenfield feature flag for classic tenant creation is not the mechanism that converts an imported Aria estate into All Apps. [3]

What the import preserves conceptually

The import path is designed to preserve continuity for existing Aria Automation investments, including the concepts of:

• Existing projects and users.
• Cloud accounts and zones.
• Templates and deployments.
• Catalog content.
• Policies.
• Integrations and subscriptions.
• Orchestrator and ABX-based extensions.
• Public-cloud and vSphere endpoint relationships.

Preservation does not mean every element is automatically compatible or operational after the platform transition. It means the migration lane is intended to carry the existing VM Apps model forward.

What the import does not do

Importing Aria Automation does not automatically:

• Create an All Apps organization.
• Enable vSphere Supervisor.
• Convert cloud templates into VM Service resources.
• Convert projects into namespace-backed service boundaries.
• Translate network profiles into VPC and namespace networking.
• Convert Aria policies into Kubernetes admission policies.
• Rebuild custom forms as All Apps blueprints.
• Replace ABX or event subscriptions with equivalent All Apps integrations.
• Validate IPAM, DNS, ServiceNow, Ansible, Git, Terraform, secrets, or custom resource integrations.
• Redesign identity and RBAC for provider, organization, project, namespace, and VKS layers.
• Establish a new support model for VKS, GPU, data, or AI services.

The upgrade changes the platform. Modernization changes the service model. Those are related programs, but they are not the same activity.

Existing Integrations and Extensibility

VCF Automation 9.x remains extensible, but the extensibility model is path-specific.

VM Apps extensibility

The VM Apps path retains the mature Aria ecosystem, including many combinations of:

• VCF Operations Orchestrator workflows.
• ABX actions.
• Event Broker-style subscriptions and event topics.
• Custom resources and resource actions.
• External IPAM.
• ServiceNow ITSM integration.
• Ansible and configuration-management integrations.
• Git repositories.
• Public-cloud accounts.
• REST-based integrations.
• Custom forms and property logic.

These integrations are often the hidden reason an apparently simple VM service took years to mature. They encode enterprise requirements such as naming, DNS, firewall policy, ticketing, CMDB registration, backup, monitoring, vulnerability scanning, and decommissioning.

All Apps extensibility

All Apps uses a different combination of mechanisms:

• VCF Operations Orchestrator integration.
• Event subscriptions for application and resource events.
• Blueprints and workflow composition.
• Terraform provider capabilities.
• VCF APIs and CLI.
• Kubernetes resources and admission policy.
• Project and namespace content.
• Service-specific integrations for networking, storage, AI, and data services.

Broadcom documents provider-managed VCF Operations Orchestrator integration and event subscriptions for All Apps organizations. [23], [24]

Do not assume one-to-one parity

A migration assessment must test each integration by use case, trigger, input, output, failure behavior, and ownership. The same external system may be supported in both paths but through different mechanisms.

For example, an existing VM Apps subscription may trigger after compute allocation, call IPAM, write to a CMDB, invoke an Orchestrator workflow, and expose a custom day-2 action. Reproducing that service in All Apps may require a blueprint, event subscription, provider service, namespace policy, external controller, or GitOps workflow. The business outcome can remain the same while the implementation changes substantially.

Migration Risks and Failure Modes

The most dangerous VCF Automation migrations are the ones treated as appliance upgrades.

Tenant semantics are different

An Aria tenant or project does not map mechanically to an All Apps organization or namespace. Architects must decide whether the original boundary represented identity, cost, compliance, infrastructure allocation, application ownership, or only portal organization.

A weak mapping can create too many organizations, too few isolation boundaries, or inconsistent project and namespace ownership.

Bimodal infrastructure can be undersized

Broadcom publishes a bimodal consumption design for VM Apps and All Apps workloads. The design implication is that bimodal operation must be planned as an infrastructure assignment and capacity decision, not assumed to be a free overlay. [4]

The starting community discussion highlighted the practical concern that VM Apps and All Apps choices affect workload-domain sizing, Supervisor deployment, and NSX design. Architects should verify the current supported sharing and assignment rules for the exact VCF release before committing a workload domain to either lane. [6]

Network integration may be the real critical path

A VM can provision successfully and still fail operational acceptance because:

• The requested network is unavailable in the new organization.
• IPAM or DNS is not integrated.
• Routing to shared services is missing.
• Firewall ownership is unclear.
• VKS egress cannot reach registries or repositories.
• Load-balancing and ingress services are not standardized.
• Existing VLAN dependencies do not map cleanly to VPC-backed services.

Network and security design should therefore be completed before large-scale content migration.

Identity translation can expand privilege

Moving from project-centric Aria permissions to provider, organization, project, namespace, and Kubernetes RBAC can create hidden privilege paths. Existing groups should not be copied blindly. Each role assignment must be mapped to required actions and reviewed for separation of duties.

Policy behavior can change

An approval in VM Apps and an admission rule in All Apps solve different problems. One governs whether a request may proceed through a workflow. The other validates whether a resource definition conforms to infrastructure rules. Replacing one with the other can remove a required human or business control.

Existing deployments can outlive their design

Imported deployments may continue to operate while their templates, images, endpoints, or integrations are being redesigned. That creates a coexistence period with mixed service contracts. Day-2 operations, support ownership, rollback, and retirement must remain available for those deployments until they are migrated or decommissioned.

API and automation clients may break

Automation clients may depend on:

• Old endpoint paths.
• Aria API schemas.
• Tenant identifiers.
• Resource types.
• Event topics.
• Authentication flows.
• Organization names.
• Catalog item identifiers.
• Custom action names.

Every integration should have a contract test before and after import, upgrade, or service redesign.

The UI can hide architectural limits

The current limitation on creating multiple VM Apps organizations through the UI is a good example. An architecture that depends on repeated tenant onboarding must include the supported API workflow, audit controls, naming standards, rollback procedure, and support ownership rather than treating the limitation as a manual workaround. [12]

A Practical Adoption Sequence

A safer VCF Automation program separates continuity, platform readiness, service redesign, and migration.

Establish the service inventory

Inventory existing Aria Automation services at the level that matters operationally:

• Catalog item and template.
• Target endpoint and cloud zone.
• Image, customization, and configuration dependencies.
• Network, IPAM, DNS, firewall, and load-balancer workflow.
• Approval, lease, quota, and day-2 policies.
• Event subscriptions, ABX, Orchestrator, ServiceNow, Ansible, Git, and external APIs.
• Secrets, certificates, and service accounts.
• Monitoring, backup, CMDB, vulnerability, and cost integration.
• Current owner, consumer, support tier, and retirement date.

This inventory becomes the migration unit. Counting templates alone misses most of the service.

Protect the VM Apps continuity lane

Import and upgrade the existing Aria environment using the supported path. Validate identity, endpoints, catalog access, deployments, policies, and integrations before introducing redesign work. Treat VCF Automation for VM Apps as a production service with its own capacity and support plan.

Build the All Apps provider foundation

Before publishing services, validate:

• Provider identity and System organization administration.
• Regions and capacity model.
• Region Quotas.
• Supervisor lifecycle and health.
• NSX and network consumption model.
• Storage policies and content libraries.
• Namespace Classes.
• Project and namespace delegation.
• VM Service and VKS baseline behavior.
• Policy, observability, cost, backup, and support integration.

Create service-class pilots

Choose a small set of services that expose the value of the new model without requiring immediate parity with every Aria workflow. Good pilots include:

• A standard Linux VM Service offering.
• A VKS development cluster.
• A GPU-enabled development VM class.
• A project-scoped content publishing workflow.
• A composed application blueprint that creates a namespace, VM, and VKS cluster.

Each pilot should have explicit pass criteria for provisioning, policy, identity, networking, day-2 operations, monitoring, recovery, and decommissioning.

Migrate services selectively

Classify services into four groups:

• Retain in VM Apps: mature service with no business reason to redesign.
• Rebuild in All Apps: new service or high-value candidate for namespace-led consumption.
• Operate bimodally: service portfolio requires both models for different consumers.
• Retire: low-value or obsolete automation that should not be carried forward.

This prevents the program from turning into a forced conversion exercise.

Establish acceptance evidence

A service should not be considered migrated until the following evidence exists:

• Request and approval succeeded.
• Placement, quota, and policy behaved as designed.
• Network, DNS, IPAM, and security controls were validated.
• Guest or cluster initialization completed.
• Monitoring, logging, backup, and cost data appeared.
• Authorized day-2 actions worked.
• Failure and rollback paths were tested.
• Support ownership and escalation were documented.
• The old catalog item was disabled or clearly distinguished.

Decision Tree: Which Consumption Model Should You Select?

The decision tree begins with the operating model, not with the workload format.

Default recommendations

• Imported Aria estate: VM Apps first.
• New conventional VM catalog with complex enterprise integrations: VM Apps unless All Apps has validated parity for the service.
• New platform-engineering service delivering VM and Kubernetes resources together: All Apps.
• VKS-based CaaS: All Apps.
• Namespace-scoped GPU and AI platform: All Apps, with explicit hardware, licensing, security, and observability design.
• Existing GPU-backed VM workflow using mature Aria integrations: VM Apps may remain appropriate.
• Enterprise with mixed modernization timelines: Bimodal design with deliberate infrastructure, catalog, naming, and support separation.

Terminology Translation: vRealize and Aria to VCF Automation

The following table is a translation aid, not a guarantee of one-to-one functional equivalence.

Architecture Recommendations by Scenario

Existing enterprise Aria Automation platform

Preserve the imported environment as VM Apps. Complete the supported import and upgrade, validate every critical integration, and establish a stable VCF Automation 9.x baseline before redesigning services. Build All Apps in parallel for new use cases rather than turning the upgrade into a forced operating-model conversion.

Greenfield private cloud focused on standard VMs

Do not assume All Apps is mandatory merely because the environment is greenfield. Compare the operational cost of Supervisor, namespace governance, NSX service networking, and Kubernetes-style APIs with the actual service requirements. A VM Apps model may be the simpler answer when the service is a conventional VM catalog with mature enterprise workflows.

However, greenfield designs should avoid creating a VM Apps-only platform by habit. If the roadmap includes VKS, GPU, AI, data services, platform engineering, or namespace-based delegation, the provider foundation for All Apps should be designed early even if initial workloads remain VM-centric.

New internal developer platform

Use All Apps as the primary model. Organize the platform around provider Regions, organization quotas, Projects, Namespace Classes, vSphere Namespaces, VM Service, VKS, content, blueprints, policy, and GitOps-compatible APIs. Treat the catalog as a product interface and build complete service classes for VMaaS, CaaS, GPUaaS, and AIaaS.

Regulated or external multi-tenant service

Use separate organizations for strong tenant boundaries and design provider-level identity, networking, quota, chargeback, evidence, and support controls. Validate the exact supported pattern for VM Apps and All Apps tenant counts, infrastructure assignment, and API-based onboarding. Avoid relying on UI behavior as the architecture contract.

Mixed application portfolio

Adopt a bimodal model. Keep existing automation-heavy VM services in VM Apps, and place new Kubernetes, GPU, AI, or composed services in All Apps. Use distinct naming, catalog presentation, infrastructure pools, network patterns, monitoring, and support runbooks so consumers understand which service contract they are receiving.

Operational Acceptance Checklist

Before declaring either model production-ready, verify the following.

Provider foundation

• Provider identity, role separation, and break-glass access are documented and tested.
• Organization creation and onboarding are automated or governed by a repeatable runbook.
• Capacity, Region, Region Quota, cloud-zone, or project allocations are monitored.
• Supervisor lifecycle, health, backup, and recovery responsibilities are defined where applicable.
• Network, DNS, IPAM, firewall, load-balancing, proxy, and egress dependencies are validated.
• Certificates, secrets, and service accounts have rotation owners.
• Monitoring, logging, cost, audit, and support integrations are operational.

Service content

• Images and templates have version, vulnerability, ownership, and retirement controls.
• Blueprints and workflows are stored in source control where practical.
• Catalog items identify service tier, owner, support scope, and lifecycle.
• Namespace Classes and VM classes are tested against intended workloads.
• VKS versions and node classes are supported and upgradeable.
• GPU classes include driver, vGPU, licensing, placement, and monitoring requirements.

Governance

• Quotas have been tested at organization, project, namespace, and resource layers.
• Approval and admission controls are not confused or duplicated without purpose.
• Day-2 entitlements match the support model.
• Identity groups have been mapped to provider, organization, project, namespace, and cluster roles.
• Exceptions have an owner, expiration, and evidence trail.

Lifecycle and recovery

• Provisioning failure produces actionable diagnostics.
• Partial deployments can be cleaned up safely.
• Day-2 operations have been validated.
• Backup and restore expectations are explicit for the automation platform, VMs, namespaces, and VKS clusters.
• Imported Aria deployments retain support until retired or migrated.
• Rollback points exist for appliance upgrade, integration change, service release, and catalog cutover.

Conclusion

VCF Automation 9.x should be understood as an operating-model expansion, not a product rename. The platform still contains the mature Aria Automation lineage, but it now places that lineage beside a provider-oriented, Supervisor-backed model that uses organizations, Regions, Projects, Namespace Classes, and vSphere Namespaces to deliver a broader private cloud service portfolio.

Traditional VM provisioning remains the right choice when an enterprise must preserve proven Aria templates, public-cloud endpoints, custom forms, IPAM, ServiceNow, ABX, Orchestrator, approval, and day-2 automation. Supervisor-based consumption becomes the stronger choice when the goal is a new platform product that must deliver VMs, VKS clusters, GPU-backed compute, data services, and AI capabilities through declarative APIs and shared namespace governance.

The two paths should not be collapsed into a simplistic legacy-versus-modern argument. A service is modern when it is supportable, governable, observable, recoverable, and aligned to consumer needs. VM Apps can meet that standard for established VM services. All Apps can meet it for a new multi-service platform, but only when Supervisor, networking, identity, quota, content, policy, and operations are designed as one system.

For most enterprises, the lowest-risk path is bimodal: import and stabilize Aria Automation as VM Apps, establish a production-grade All Apps provider foundation, and migrate service offerings only when the new model reproduces or improves their complete operational contract. That is how VCF Automation becomes a private cloud platform rather than another self-service portal.

External References

• [1] Broadcom TechDocs: VCF Automation Overview
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/overview-of-vmware-cloud-foundation-9/what-is-vmware-cloud-foundation-and-vmware-vsphere-foundation/vcf-automation-overview.html
• [2] Broadcom TechDocs: VMware Cloud Foundation 9.1
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.html
• [3] Broadcom Community: Question on Importing or Migrating Aria Automation into VCF 9
  Canonical URL: https://community.broadcom.com/vmware-cloud-foundation/discussion/question-on-importingmigrating-aria-automation-into-vcf-9
• [4] Broadcom TechDocs: Bimodal Consumption Design for VM Apps and All Apps Workloads
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/vcf-automation-deployment-models-9-x/multi-tenancy-design-patterns/shared-tenancy-design.html
• [5] VMware Cloud Foundation Blog: VMware Cloud Foundation Automation, Consume and Deploy Virtual Machines and Kubernetes Clusters
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/12/01/vmware-cloud-foundation-automation-consume-and-deploy-virtual-machines-and-kubernetes-clusters/
• [6] Broadcom Community: Traditional Versus Kubernetes-Based Provisioning of Virtual Machines in VCF Automation
  Canonical URL: https://community.broadcom.com/vmware-cloud-foundation/discussion/traditional-vs-kubernetes-based-provisioning-of-virtual-machines-in-vcf-automation-vcfa-9000
• [7] Broadcom TechDocs: Getting Started with the VCF Automation Provider Management UI
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/provider-management/getting-started-with-the-vcloud-director-service-provider-portal.html
• [8] Broadcom Community: How to Login to a New VCF 9.0 Automation Instance
  Canonical URL: https://community.broadcom.com/vmware-cloud-foundation/discussion/how-to-login-to-new-vcf-90-automation-instance
• [9] VMware Cloud Foundation Blog: VMware Cloud Foundation Automation, All Apps Organization Configurations
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/11/07/vmware-cloud-foundation-automation-all-apps-organization-configurations/
• [10] Broadcom TechDocs: Managing Projects in VCF Automation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/managing-projects-in-vcfa.html
• [11] Broadcom TechDocs: Understanding Supervisors, Regions, vSphere Zones, and vSphere Namespaces
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/vcf-automation-deployment-models-9-x/organization-consumption-model/supervisors-regions-zones-and-vsphere-namespaces.html
• [12] Broadcom Knowledge Base: Creating Additional VM Apps Organization in VCF Automation 9 via REST API
  Canonical URL: https://knowledge.broadcom.com/external/article/419781/how-to-create-additional-vm-apps-organiz.html
• [13] VMware Cloud Foundation Blog: Use Cases for VMware Private AI Foundation with NVIDIA in VCF 9.0
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/06/19/use-cases-for-vmware-private-ai-foundation-with-nvidia-in-vcf-9-0/
• [14] Broadcom TechDocs: Managing Predefined User Roles in VCF Automation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/administering-users-and-groups-in-vcf-automation-for-all-apps.html
• [15] Broadcom TechDocs: How Do I Configure Approval Policies in VCF Automation for VM Apps
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/vcfa-overview/getting-started-with-organizations-for-vm-apps-in-vcf-automation/service-broker-policies-setting-up-policies/service-broker-policies-how-do-i-configure-approval-policies.html
• [16] Broadcom TechDocs: How to Create Resource Quota Policies
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/administration-sdks-cli-and-tools/what-are-the-automation-apis-and-how-do-i-use-them_1/working-with-blueprints-cloud-templates/setting-up-policies/how-to-create-resource-quota-policies.html
• [17] VMware Cloud Foundation Blog: VMware Cloud Foundation Automation Infrastructure Resource Policy Overview
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/10/01/vmware-cloud-foundation-automation-infrastructure-resource-policy-overview/
• [18] VMware Cloud Foundation Blog: Private Cloud Redefined, Deliver a Unified Consumption Experience with VCF 9.0
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/06/17/unified-cloud-consumption-experience-with-vcf-9-0/
• [19] Broadcom TechDocs: Network Consumption Models
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/vmware-cloud-foundation-concepts/network-backing-models.html
• [20] Broadcom TechDocs: Deploy a Supervisor with VPC Networking
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/vsphere-supervisor-installation-and-configuration/supervisor-networking-with-virtual-private-clouds/deploy-a-supervisor-with-nsx-vpc.html
• [21] Broadcom TechDocs: Create a Project Content Library in VCF Automation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/setting-up-the-content-hub-in-vcf-automation-for-all-apps-organizations/adding-and-managing-content-libraries/create-a-project-content-library-in-vcf-automation.html
• [22] Broadcom TechDocs: Import an Existing VMware Aria Automation Instance in VCF Operations
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/upgrading-cloud-foundation/phase-3-import-and-upgrade-aria-automation-8-to-vcf-automation-9/import-an-existing-vmware-aria-automation-instance-in-vcf-operations.html
• [23] Broadcom TechDocs: Managing a VCF Operations Orchestrator Integration in VCF Automation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/administering-all-apps-organizations-in-vcfa-automation/integrating-vcfa-with-other-applications/integrating-vcfa-with-vcf-operations-orchestrator/manage-vcf-operations-orchestrator-integration-in-vcf-automation-for-all-apps.html
• [24] Broadcom TechDocs: Create an Event Subscription in VCF Automation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/event-subcriptions-in-vcf-automation-for-all-apps/create-an-event-subscription-in-vcf-automation-for-all-apps.html

The post VCF Automation 9.x Explained: Traditional VM Provisioning, Supervisor Based Consumption, and the New Tenant Model appeared first on Digital Thought Disruption.