“Manual vSphere template deployment forces cloud administrators to perform 40 click-through wizard steps per virtual machine. Declarative vRealize Automation (vRA 8.2) Cloud Templates reduce complex multi-tier tenant environments to a single API payload delivered in 15 minutes.”

In January 2021, during my tenure as Systems Integration Advisor at NTT Data, we were scaling out an enterprise private cloud platform for multi-tenant enterprise clients.

Onboarding a new client tenant required provisioning a standardized multi-tier application environment:

• 8 Linux Web/App virtual machines.
• 2 Windows Oracle Database virtual machines.
• 3 NSX-T logical routed subnets with gateway load balancing.
• Custom vSAN Storage Policies (RAID-1 mirrored for databases, RAID-5 erasure coding for web tiers).

The delivery SLA promised to clients was 48 hours.

The operational reality was 10 business days.

---

The 40-Click vSphere Wizard Nightmare

The bottleneck wasn’t hardware capacity—it was manual human clicking inside vSphere Client.

For every single VM, a systems engineer had to:

1. Right-click an OVF template and launch the 40-step vSphere deployment wizard.
2. Select a target ESXi host cluster and datastore.
3. Manually select guest customization specifications and type IP addresses.
4. Manually attach vNICs to NSX-T logical switches.
5. Manually apply vSAN storage policy tags.

Because engineers performed these steps by hand under ticket pressure, human errors were everywhere.

Engineers regularly assigned cheap RAID-0 storage policies to production database disks, selected wrong VLAN portgroups, or made typos in default gateway subnets.

When an environment failed QA validation due to a mistyped IP address, the ticket was kicked back, and the 10-day waiting game restarted.

---

The Mess: The Day-1 Config Drift Crisis

During a major client onboarding in late 2020, an engineer provisioned a 12-node database cluster by hand.

On Node 07, he forgot to select the Production-vSAN-RAID1 policy, leaving the VM on the default un-replicated datastore.

Three weeks later, a physical SSD drive failed in the storage pool.

Nodes 01 through 06 survived without data loss due to RAID-1 mirroring. Node 07 crashed, corrupting a 4TB production database because of a single missed dropdown click during manual setup three weeks earlier!

Manual GUI clicking was an unacceptable risk to enterprise cloud operations. We had to automate environment delivery end-to-end.

---

The Solution: Declarative vRA 8.2 Cloud Templates & ABX Extensibility

We replaced manual vSphere deployment steps with modular vRealize Automation (vRA 8.2) Cloud Templates engineered using declarative YAML.

# vRA 8.2 Cloud Template YAML Snippet for Multi-Tier App Pod
formatVersion: 1
inputs:
  environment:
    type: string
    title: Deployment Environment
    enum:
      - Development
      - Production
  db_size:
    type: string
    title: Database Sizing Profile
    enum:
      - small
      - medium
      - large

resources:
  # 1. NSX-T Routed Logical Network
  Cloud_NSX_Network_1:
    type: Cloud.NSX.Network
    properties:
      networkType: routed
      supportPublicIp: true

  # 2. Automated vSphere Database VM Instance
  vSphere_DB_Machine:
    type: Cloud.vSphere.Machine
    properties:
      image: Windows-2019-Template
      flavor: '${input.db_size}'
      storage:
        type: datastore
        # Dynamic vSAN Storage Policy Binding based on environment input
        storagePolicy: '${input.environment == "Production" ? "vSAN-RAID-1-Mirror" : "vSAN-RAID-5-EC"}'
      networks:
        - network: '${resource.Cloud_NSX_Network_1.id}'
          assignment: static

Action-Based Extensibility (ABX) Integration

To eliminate manual IP allocation, we integrated vRA Cloud Templates with vRealize Action-Based Extensibility (ABX) Python microservices:

# ABX Python Microservice: Dynamic IPAM Reservation (Infoblox / iTop)
import requests

def handler(context, inputs):
    vm_name = inputs['resourceNames'][0]
    # Issue REST API request to IPAM for next available IP in subnet
    ipam_response = requests.post("https://ipam.corp.local/api/v1/reserve", json={"host": vm_name})
    allocated_ip = ipam_response.json()['ip_address']

    # Inject allocated IP into vRA VM customization spec dynamically
    outputs = inputs
    outputs['customProperties']['ipAddress'] = allocated_ip
    return outputs

The 15-Minute Automated Lifecycle

When a client requests a new environment:

1. Client selects a T-Shirt sizing profile (Small, Medium, Large) in the vRA Service Broker catalog.
2. vRA executes the Cloud Template YAML payload.
3. ABX Python scripts reserve IP addresses in IPAM automatically.
4. NSX-T provisions logical switches and firewalls in 45 seconds.
5. vSphere clones templates, applies vSAN-RAID-1 policies, and customization specs in sub-10 minutes.

---

The Impact

• 15-Minute Provisioning: Reduced tenant environment delivery time from 10 business days down to 15 minutes.
• Zero Configuration Drift: Eliminated 100% of human GUI clicking errors; all storage policies and NSX subnets are enforced declaratively via code.
• Self-Service Catalog: Empowered application teams to request and tear down dev/test environments on demand without opening IT tickets.

Key Takeaway

Standardize Private Cloud Provisioning with Declarative vRA Blueprints.

Never allow system administrators to provision production enterprise VMs by manually clicking through vSphere Client wizards. Deploy vRealize Automation (vRA 8.2) Cloud Templates with ABX Python extensibility to automate IPAM reservations, NSX-T network creation, and vSAN storage policy bindings declaratively in code.

---

Architecture and decisions: mine. Debugging sessions at odd hours: mine. AI assistance: structure, syntax, first draft. — Sachin