VCF Automation for VMware Cloud Director Administrators: What Carries Over and What Does Not

VCF AUTOMATION FOR VCD ADMINS

An orientation guide to VCF Automation for people who already know VMware Cloud Director: the architecture, the two inheritances, the operational differences, and what your tenants will see.

If you administer VMware Cloud Director, the good news is that roughly half of VCF Automation will feel like coming home. The provider-facing layer is built on the Cloud Director codebase, so the interface and the APIs are recognisable and a decade of accumulated instinct still applies. The less good news is that the other half is a different product entirely, and it happens to be the half your tenants use.

That asymmetry is the most useful thing to understand before you plan anything. Your own retraining burden is modest. Your customers' is total. Programmes that go wrong usually do so because the team extrapolated from their own experience of the platform, which was reassuring, to their tenants' experience of it, which is not the same thing at all.

In this article

• The two inheritances and why they matter
• How VCF Automation is deployed and what it runs on
• The resource model, and the shift toward the Supervisor
• What carries over recognisably
• What carries over transformed
• What does not carry over at all
• Operational differences worth knowing before day one
• Where the real learning curve sits, with a readiness checklist

1. Two Inheritances, One Platform

VCF Automation arrived with VCF 9 and superseded both Cloud Director and Aria Automation. It is not a rebranding and it is not a merger of two codebases into a compromise. It is a new platform that took the most useful parts of each predecessor and assigned them to the audience they suited.

Tenant Manager, the provider layer

The provider-facing component is called Tenant Manager and it is built on the Cloud Director codebase. If you have spent years in the Cloud Director provider portal, this is the part of the transition that costs you least. The concepts you use to think about tenancy still work, the API shapes are familiar, and the mental model of organisations and provider administration survives.

This is genuinely significant for planning, because it means the retraining conversation with your own operations team is measured in days rather than months. It also means your provider-side automation has a shorter path forward than you might assume, though it will still need work.

The tenant layer, from Aria Automation

The tenant-facing experience draws heavily from Aria Automation. For a customer whose only reference point is the Cloud Director tenant portal, this is not an updated interface. It is a new product with a different interaction model, different terminology and different capabilities.

Cloud Director's tenant portal was built around the vApp and the organisation virtual data centre, with the tenant managing infrastructure objects directly. Aria Automation was built around requesting and consuming services from a catalogue. VCF Automation's tenant experience sits closer to the second, and the tenants who find the transition hardest are the ones most fluent in the first.

2. How It Is Deployed and What It Runs On

VCF Automation is normally deployed through VCF Operations Fleet Management, the lifecycle component that succeeded the embedded Aria Suite Lifecycle. It can alternatively be deployed by the VCF Installer as a day zero action during platform bring-up, though that route gives you less flexibility over networking topology. For a provider building alongside an existing Cloud Director estate, the Fleet Management route is generally the right choice because it lets you place and shape the deployment deliberately rather than accepting bring-up defaults.

Architecturally, VCF Automation consists of one or more VMware Management Services Platform appliances running containerised services in a Kubernetes cluster. That sentence carries more operational consequence than its length suggests.

• Sizing thinking changes. You are sizing a management services platform running a Kubernetes cluster, not a set of load-balanced cells behind a virtual IP.
• Patching moves into fleet lifecycle. Updates come through VCF Operations Fleet Management as part of platform lifecycle rather than as an independent product upgrade you schedule in isolation.
• Troubleshooting has a new layer. When something misbehaves, the containerised services and the cluster hosting them are part of the diagnostic path, which is unfamiliar territory for most Cloud Director teams.
• Certificate and share management differ. Routine operational tasks such as certificate replacement and expanding the transfer share have their own procedures that are worth rehearsing before you need them.

3. The Resource Model Has Moved

In Cloud Director, provider virtual data centres carved resources from vSphere, organisation virtual data centres allocated those resources to tenants, and tenants consumed them by creating vApps and virtual machines on organisation networks behind Edge Gateways. Everything descended from that hierarchy.

In VCF Automation, infrastructure is presented to consumers substantially through Namespaces, which are Kubernetes namespaces managed by the vSphere Supervisor with assigned compute resources, storage classes and NSX VPCs. Organisations persist as the tenancy boundary. Projects appear as an organising layer. The Supervisor, rather than the Cloud Director hierarchy, is increasingly where consumption is expressed.

The practical consequence is that the vApp, which was the unit almost every Cloud Director process was built around, has no direct equivalent. Anywhere your operational documentation, your automation or your tenant guidance treats the vApp as the primary object, that content needs rethinking rather than translating. This is the single most common source of surprise for experienced Cloud Director administrators.

4. What Carries Over Recognisably

• Organisations as the tenancy boundary, and as the natural unit for migration sequencing.
• The provider administration model, including the separation between provider and tenant scope.
• Role-based access control as a concept, though the model itself is worth rebuilding rather than transliterating.
• Blocking tasks, which work as they did in Cloud Director but are tied to provider workflows in Tenant Manager. Their purpose is unchanged: inserting external automation such as CMDB updates or metadata tagging into a workflow.
• The general shape of the provider API, which means provider-side automation has a shorter path forward than tenant-side automation does.
• Catalogue as a concept, delivered through content libraries and catalog items rather than the Cloud Director catalog model.

5. What Carries Over Transformed

Table 1 - Constructs that exist in both platforms but behave differently.

The networking row deserves emphasis. VCF Automation 9.1 introduced vDefend Distributed Firewall and Gateway Firewall support directly within the platform, allowing provider administrators to delegate firewall services to organisation administrators, with out-of-the-box security profiles and role-based access control labelling for dynamic security groups. For providers who have been fielding tenant requests for firewall self-service, this is one of the genuine gains of the transition rather than merely a change to absorb.

6. What Does Not Carry Over

• The tenant experience. Your customers get a new product. Every runbook, screenshot and training document they hold becomes wrong on cutover day.
• Tenant API integrations. Anything a customer automated against the Cloud Director tenant API needs rework, by them, at their expense, on their schedule.
• Custom UI plugins. Provider extensions built for the Cloud Director interface do not transfer. Catalogue them early and record a decision for each rather than discovering them during cutover.
• vApp-centric process. Any operational procedure, automation or tenant-facing documentation built around the vApp needs redesign.
• Assumptions about the cell model. Runbooks that describe restarting cells, load balancer behaviour or cell-specific troubleshooting do not apply to a containerised platform.

7. Operational Differences Worth Knowing Early

• Lifecycle is fleet-managed. Updates arrive through VCF Operations Fleet Management as part of platform lifecycle, which changes who schedules them and how they are tested.
• Health and diagnostics span two layers. A symptom in the interface may originate in a containerised service or in the cluster beneath it, so the diagnostic path is longer than it was with cells.
• Platform resource consumption needs its own monitoring, including behaviours specific to certain CPU generations that have needed tuning in some deployments.
• Routine tasks have new procedures. Certificate replacement and expanding the transfer share are both worth rehearsing in a non-production environment before you need them at speed.
• Blocking tasks are provider-scoped. If your existing extensibility relies on blocking tasks in tenant workflows, that assumption needs revisiting.
• Workload mobility differs by version. VCF 9.0 required a reboot and re-addressing to bring a vCenter-managed virtual machine under VCF Automation management. VCF 9.1 introduced the Mobility Operator, a Supervisor service enabling non-disruptive migration of running virtual machines.

That last point is worth treating as a version selection criterion rather than a detail. For a provider, the difference between a tenant migration requiring an outage and one that does not is a commercial difference, not a technical one.

8. Where the Real Learning Curve Sits

• Small: the provider interface. Tenant Manager is built on the Cloud Director codebase and experienced administrators become productive quickly.
• Moderate: the containerised platform. New deployment, lifecycle and troubleshooting patterns. A few weeks of deliberate practice, best acquired in a lab rather than in production.
• Large: the resource model. Genuinely rethinking allocation and consumption around Projects, Namespaces and VPCs rather than reproducing the organisation virtual data centre model. This is design work, not training - see our construct mapping reference.
• Largest, and not yours: the tenant experience. Your customers carry this and you cannot do it for them. What you can do is give them lead time, documentation and a person to talk to.

Team Readiness Checklist

Before you design anything

• A lab deployment of VCF Automation stood up and used, not just read about
• Tenant Manager explored by the people who administer Cloud Director today
• The tenant portal explored by whoever will support your customers on it
• Namespace, Project and VPC concepts understood well enough to explain to a tenant
• Deployment route decided: VCF Operations Fleet Management or day zero via the installer

Before you migrate anything

• Provider-side automation reviewed against the Tenant Manager API
• Custom UI plugins and provider extensions catalogued with a decision recorded for each
• Operational runbooks audited for cell-model and vApp-centric assumptions
• Certificate replacement and transfer share expansion rehearsed in a lab
• Monitoring extended to the containerised platform and the cluster beneath it
• Target version confirmed, with 9.1 or later where non-disruptive workload mobility matters

Before your tenants see it

• Tenant-facing documentation rewritten rather than amended
• Service desk trained on the tenant portal, not only the provider interface
• Tenants with API integrations identified and contacted individually
• A sandbox offered to technically engaged tenants ahead of their migration
• Escalation path agreed for tenant issues during the parallel running period

Frequently Asked Questions

Is VCF Automation just Cloud Director with a new name?

No. It is a new platform that superseded both Cloud Director and Aria Automation. It reuses substantial components from each: the provider layer, Tenant Manager, is built on the Cloud Director codebase, while the tenant experience derives from Aria Automation. Familiar in parts, new in others, and the new parts are the ones your customers use.

How much retraining will our operations team need?

Less than you would expect for the provider interface, because Tenant Manager inherits the Cloud Director codebase. More than you would expect for the platform underneath, because it is a containerised Kubernetes-based deployment with different lifecycle, monitoring and troubleshooting patterns. Budget lab time rather than classroom time.

What happened to vApps?

There is no direct equivalent. Workloads are presented through Namespaces with assigned compute, storage classes and NSX VPCs. Any process, automation or documentation built around the vApp as the primary unit needs rethinking rather than translating.

Do blocking tasks still exist?

Yes, and they serve the same purpose of inserting external automation such as CMDB integration or metadata tagging into a workflow. The difference is that they are tied to provider workflows in Tenant Manager, so extensibility that relied on blocking tenant workflows needs a different approach.

How is VCF Automation deployed?

Usually through VCF Operations Fleet Management, which succeeded the embedded Aria Suite Lifecycle. It can also be deployed by the VCF Installer as a day zero action during platform bring-up, at the cost of less flexibility over networking topology.

Will our provider-side automation still work?

It will need work, but less than tenant-side automation does, because the provider API shapes are familiar. Review it against the Tenant Manager API early, since that assessment also tells you how much of your operational tooling is affected.

What is the single biggest thing to prepare for?

The tenant experience, because it is the largest change and the one you cannot absorb on your customers' behalf. The technical migration is the part you control. The customer transition is the part that determines whether the programme is judged a success.

Where Consult Circle Fits

Most of what makes this transition difficult is not learning the new platform. It is deciding how your existing tenancy model should be expressed in a resource model that works differently, and doing that without simply recreating the old design on new foundations.

We work with providers on exactly that: construct mapping, platform design, operational readiness and the tenant transition. Where a team is confident and simply wants the design reviewed before it becomes concrete, we do that as a standalone engagement.

Related guides in this series

• VMware Cloud Director to VCF Automation Migration: The Complete Guide for Service Providers
• VMware Cloud Director End of Life: What the VCF Automation Transition Means for Your Provider Business
• Mapping VMware Cloud Director Constructs to VCF Automation: Org VDCs, Edge Gateways, Catalogs and IP Spaces
• VMware Cloud Director 10.x vs VCF Automation 9.1: A Feature Parity Comparison for Service Providers
• The Complete VCD to VCF Automation Migration Checklist: 72 Checks for Service Providers
• The VMware Cloud Director API for Day-to-Day Operations: The Calls You Will Actually Use
• VMware Cloud Director Common Errors and Known Issues: Symptoms, Causes and Workarounds