← Back to Engineering Blog
🗓️ Jun 15, 2021 ⏱️ 2 min read

1-Click Nested SDDC: How I Built an Automated VMware Lab Engine with Ansible & BGP

How I engineered a 1-click Ansible automation pipeline to deploy complete nested VMware SDDC environments (vCenter, ESXi, NSX-T, BGP).

🎙️ Listen to Article READY
AI Audio Synthesis Narrator
Share Post:

“Spinning up a multi-node VMware SDDC environment manually used to take 3 days of tedious ISO mounts and VLAN mapping. So I built an open-source Ansible engine to do it in 1 click.”

During my tenure scaling private clouds at NTT Data, enterprise client testing required frequently standing up and tearing down isolated multi-tenant SDDC pods.

Doing this manually meant human error at every stage—misconfigured DNS forwarders, MTU mismatches on overlay vDS switches, or dropped BGP neighbor peerings. I built the open-source repository VMware-SDDC-LAB to turn full nested SDDC provisioning into a single Ansible execution.


The SDDC Architecture

The engine provisions a complete, fully wired nested SDDC pod over physical infrastructure:

  • Control Plane: vCenter Server appliance + NSX-T Local Manager.
  • Compute Layer: Nested ESXi hypervisors deployed via automated ovftool answerfiles.
  • Network Fabric: NSX-T Tier-0 / Tier-1 Edges with dynamic BGP and OSPF peering over a Lab-Routers transit segment.
# # Sample Pod Orchestration from deploynsxtInfra.yml
- name: "Deploy NSX-T Local Manager Appliance"
  community.vmware.vmware_deploy_ovf:
    hostname: "{{ esxi_physical_host }}"
    username: "{{ esxi_user }}"
    password: "{{ esxi_password }}"
    datacenter: "{{ datacenter_name }}"
    datastore: "{{ target_datastore }}"
    name: "Pod1-NSXT-LM01"
    ovf_path: "/Software/NSX-T/nsx-unified-appliance.ova"
    networks:
      "Management": "Lab-Mgmt-VLAN10"
    deployment_option: "medium"
    properties:
      nsx_passwd_0: "{{ nsx_admin_password }}"
      nsx_cli_passwd_0: "{{ nsx_cli_password }}"
      nsx_hostname: "nsxt-lm01.sddc.lab"
      nsx_ip_0: "192.168.10.20"
      nsx_netmask_0: "255.255.255.0"
      nsx_gateway_0: "192.168.10.1"
      nsx_dns1_0: "192.168.10.2"
  delegate_to: localhost

Physical-to-Virtual BGP Routing

One of the biggest hurdles in nested SDDC labs is route leaking between the virtual Geneve overlay and the physical physical core network.

We solved this by creating a dedicated Lab-Routers transit segment configured with MTU 9000 (Jumbo Frames). The NSX-T Tier-0 Edge nodes establish eBGP neighbor relationships directly with the physical L3 switch, advertising synthetic pod subnets (10.240.0.0/16) dynamically.

# # Verifying BGP Neighbor Status on Physical Layer-3 Transit Switch
NetLab-L3-Switch# show ip bgp summary
BGP neighbor is 192.168.200.2, remote AS 65001, external link
  BGP state = Established, up for 04:12:35
  Using index 1 for neighbor 192.168.200.2
  16 prefixes received, 16 accepted, 0 rejected

# # Verifying Sub-Second BFD Polling
NetLab-L3-Switch# show bfd neighbors
OurAddr         NeighborAddr    LD/RD   RH/RS   State   Int
192.168.200.1   192.168.200.2   1/2     Up/Up   Up      Vlan200

The Verdict

Key Takeaway

Treat Infrastructure Labs as Immutable Software Products.

Do not build manual test environments. Packaging your nested SDDC topology into Ansible Playbooks & Answerfiles guarantees that your staging environment is 100% identical to production.

Source Code Available at: github.com/virtualsachin/VMware-SDDC-LAB

SKS

Sachin Kumar Sharma

Associate Director (Infrastructure & Cloud Architecture Strategy) | 20+ Yrs Exp

Architecting resilient multi-cloud enterprise landing zones, SDN overlay fabrics, DevSecFinOps automation pipelines, and autonomous Agentic AI platforms.