vD vDan VMware · VCF · NSX · K8S

VCF JSON Builder

Short answer: fill in the environment planner once (prefix, domain, host count, release, IP scheme), click pre-fill, correct the details, and export the VCF Installer JSON spec that the installer accepts under Deploy using JSON spec. The builder targets VCF 9.1.1 / 9.1 (VCF Management Services runtime, License Server, Identity Broker) or VCF 9.0.x (Fleet Management and Collector appliances) and covers vCenter, NSX (TEP pool or TEP-less, Distributed Transit Gateway), ESX hosts, distributed switches with two to six pNICs and LACP, vSAN ESA/OSA, VMFS on FC and NFS principal storage, VCF Operations (single node or master/replica/data) and VCF Automation. Every field is checked in real time against the official VCF Installer API schema and against the installer’s own sizing and networking rules, and an existing spec can be imported, edited and exported again. Nothing leaves your browser.

Prefer a full window? Open the builder full screen →

How the VCF Installer JSON spec builder works

  1. Plan. The environment planner derives every name from one prefix (for example vdan-m01-vc01, vdan-m01-nsx01a, vdan-m01-cl01-vds01), the gateways from the CIDRs, the vMotion, vSAN and TEP ranges from the host count, and the Management Services and Automation pools from the management subnet. The DNS checklist lists every forward and reverse record you must create before the installer runs.
  2. Edit. Eight sections mirror the installer wizard: SDDC, ESX hosts, vCenter and SDDC Manager, networking (port groups, teaming, distributed switches, vmnic mapping, LAG), NSX, storage, Operations (with the 9.1 Management Services or the 9.0 fleet management appliance) and Automation. Switching the target release rewrites the JSON with the right blocks.
  3. Validate. Two layers: the official SddcSpec schema of the VCF Installer API (required keys, patterns, lengths, allowed values for 9.0 and 9.1.1) and the installer rules that the schema cannot express: gateways and ranges inside their subnets, enough addresses for the hosts and TEPs, FTT versus host count, one or three NSX Managers and Operations nodes, a 12 to 30 address Management Services pool, Automation pool sizes, password lengths and complexity, duplicate FQDNs, MTU for the overlay switch, every network on exactly one switch.
  4. Export. Copy or download the JSON (passwords are masked in the preview only) and upload it in the VCF Installer under Deploy using JSON spec; the installer’s own validation then checks the live environment.

9.1 versus 9.0 blocks

  • VCF 9.1 / 9.1.1: vspClusterSpec (platform, instance and fleet FQDN, IPv4 pool range, size, internal cluster CIDR), licenseServerSpec, optional vidbSpec, the empty service blocks fleetLcmSpec, sddcLcmSpec, fleetDepotSpec, telemetryAcceptorSpec, saltSpec and saltRaasSpec as in VMware’s exported specs, vcfAutomationSpec.platformFqdn, the NSX vpcSpec for the Distributed Transit Gateway and the TEP-less overlayVtepSpec (9.1.1).
  • VCF 9.0.x: vcfOperationsFleetManagementSpec and vcfOperationsCollectorSpec instead, an Automation pool of two or four addresses, no license server or identity broker.
  • Both: set useExistingDeployment on SDDC Manager when the installer appliance runs on a management host and converts itself (the pattern used by VMware’s in-a-box labs); leave it off when the installer runs outside and deploys a new SDDC Manager.

Sources