VCF Automation — Purpose & Functionality
Objectives
- Describe VCF Automation building blocks (Regions, Organizations, Projects)
- Differentiate provider vs consumer roles and organization types
- Explain VCF Automation networking (IP Spaces, Provider Gateway, VPCs)
- Configure governance policies (approval, leases, Kubernetes admission policies)
- Deploy VMs through self-service catalog with IaC templates
- Integrate with Terraform and version control (GitHub/GitLab/BitBucket)
Prerequisites
Active Holodeck VCF 9.0 lab or access to VCF documentation
Required skills:
- Basic VMware terminology
Tasks
Task 1 VCF Automation Architecture & Roles
Understand VCF Automation building blocks, tenancy, and role-based access
Core constructs: Regions (logical groupings of vCenter clusters providing compute/network/storage), Organizations (tenants with isolated environments), Projects (subdivisions within organizations). Provider vs Consumer model: Providers manage infrastructure and create resources; Consumers deploy workloads through self-service.
[HOLODECK NOTE] VCF Automation in Holodeck is resource-intensive — the Automation appliance requires significant CPU and memory. Self-service VM deployment from catalogs works in Holodeck but provisioning times are slower due to nested I/O. VMware Supervisor deployment in Holodeck is possible but requires careful resource planning — Supervisor control plane VMs need dedicated resources, and nested Kubernetes adds another virtualization layer.
System Org (provider): manages regions, organizations, content libraries. Organization types: All Apps (full capabilities), VM Apps (VM-only), Provider Consumption (provider self-consumption). Provider Content Library: curated templates and catalog items for organizations. Regions mapped to vCenter clusters — determine where workloads can be deployed.
Multitenancy: project-based isolation within organizations. Predefined roles: Org Admin (organization-level management), Project Admin (project-level management), Project Member (consume resources). Each tenant gets isolated, dedicated environment. Self-service catalog: IaC templates → catalog items for low-tech users.
VMware Supervisor enables Kubernetes-based workload management within VCF. Supervisor activates on a vSphere cluster, creating a Supervisor Namespace that can run both VMs (via VM Service) and containers (via VMware Kubernetes Service (VKS)). In VCF Automation, Supervisor integration enables: content libraries with VM classes and storage classes for self-service provisioning, Regional Networks for cross-zone connectivity, and Provider Management for multi-tenant resource allocation. Troubleshooting: Supervisor deployment failures often relate to NSX networking (Tier-0/Tier-1 not configured), insufficient cluster resources, or storage policy mismatches.
Validation Gate
Check: Name three governance controls available in VCF Automation and why each matters
Expected: 1. Quotas (CPU/memory/storage per project — prevent resource exhaustion). 2. Lease policies (auto-expire deployments — prevent zombie VMs). 3. Approval policies (require manager approval for large deployments — cost control).
Common Errors
Task 2 VCF Automation Networking & Governance
Understand networking constructs and governance policies in VCF Automation
Provider Network: IP Spaces (IP address management), Provider Gateway (connects to physical network), NSX Edge nodes/clusters (provide routing services). Organization Network: VPC (Virtual Private Cloud) architecture — default network components per organization. VPC architecture: Organization → VPC → subnets (public/private). Configuration workflow: IP Spaces → Provider Gateway → Edge Cluster → Provider Network → Organization → VPC.
Organization Portal: admin interface for org-level management. Namespace creation for Kubernetes workloads. Orchestrator integration: Embedded Orchestrator (on VCF Automation) or Stand-alone Orchestrator (separate deployment). Governance policies: approval policies, resource leases, day-2 action controls. Kubernetes policies: Validating Admission Policy (CNCF-compliant), Policy as Code (YAML), predefined templates available. Organization types in VCF Automation: Three organization types in VCF Automation: (a) All Apps Organization (default in VCF 9.0) — uses supervisor-based approach with strict namespace-level tenant isolation; each org mapped to one or more Supervisor clusters via regions; consumers deploy VMs, containers, and Kubernetes workloads; (b) VM Apps Organization — classic Automation 8.x experience using cloud accounts, cloud zones, projects, flavor mappings, and blueprints; does NOT require Supervisor; only ONE VM Apps org allowed per VCF Automation system; intended for customers upgrading from Aria Automation 8.x; (c) Provider Consumption Organization (PCO) — special-purpose org for providers to consume their own infrastructure and publish catalog items/blueprints to All Apps organizations. For exam: understand that Supervisor clusters must be configured and mapped to regions before All Apps organizations can be created, that storage classes and VM classes are selected during region creation and define resource policies available to consumers, and that VM Apps organizations use classic cloud zones instead of regions/supervisors.
Catalog management: create catalog items from IaC templates (visual canvas rendered in YAML). Terraform integration: HashiCorp provider for extended automation. Version control: GitHub/GitLab/BitBucket integration for blueprints and action scripts. VM deployment workflow: select catalog item → configure → deploy → monitor creation progress → verify successful deployment. History tab: complete audit trail of provisioning steps.
Validation Gate
Check: What IaC integrations does VCF Automation support?
Expected: 1. Cloud Templates (native YAML blueprints with visual canvas). 2. Terraform provider (HashiCorp ecosystem integration). 3. Git integration (version control for templates). 4. VCF Operations Orchestrator (event-driven automation workflows).
Common Errors
Design Reflection (VCDX)
Consumption architecture is a growing focus in VCDX defense. Panelists test whether your design includes self-service, governance, and IaC — not just infrastructure provisioning. A design that requires admin intervention for every VM request is operationally unsustainable.
Requirements
- Design self-service catalog with T-shirt sizes and governance controls
- Implement IaC workflows with Git integration
- Configure Day-2 actions for deployed resources
Constraints
- Quotas must align with cluster capacity planning
- Lease policies must balance resource reclamation with user needs
- Cloud Templates must be tested before catalog publication
Assumptions
- Development team can consume self-service catalog without infrastructure knowledge
- Git repository is available for template version control
Risks
- Ungoverned self-service exhausting cluster resources
- Failed catalog items eroding user trust in self-service platform
- Shadow IT if self-service is too restrictive or unreliable
⚠ Known Pitfalls (from Community KB)
References
- VCF Automation Administration GuideTier 1 — Official