VCF JSON Builder

The VCF JSON Builder is a browser-based form that produces a validated VCF 9 deployment JSON — the payload the VCF Installer consumes to bootstrap your SDDC. Start fresh, or paste an existing JSON to edit it visually. Everything validates as you type.

When to use this tool

Use the VCF JSON Builder when you need a valid deployment JSON for:

• Initial VCF 9 bootstrap — the VCF Installer takes a JSON spec as input for the first management domain.
• PoC environments — 3-host clusters with reduced sizing requirements.
• Automated redeploys — keep a canonical JSON in version control and re-emit it when rebuilding labs.
• Translating an existing design into JSON — you already know the IP plan, VLANs, and host layout; this tool turns them into the exact schema VCF expects, without hand-editing JSON in a text editor.

It is not a design tool. It assumes you already know:

• Your IP ranges for management, vMotion, vSAN, VM management, and overlay/TEP networks
• Your VLAN IDs
• DNS and NTP server addresses
• Host hardware details (FQDNs, IPs, root passwords, disk layout if using vSAN)

How it works

The builder is a form with eight tabs, each mapped to a section of the VCF deployment JSON. As you type, it builds the JSON in memory and shows a live preview on the right with validation state. Required fields get red borders when empty; invalid values (bad IPs, malformed CIDRs, short passwords) get red borders and tooltips.

The top defaults block is special — it doesn’t map to a single JSON field. Instead, when you click Apply, it fills in sensible defaults across every other tab (hostnames, IPs, VLANs, DNS, NTP). You can always override any propagated value afterward.

The final output is a single JSON document that matches the VCF Installer schema for the version you select (VCF 9.0.2 by default).

Step-by-step walkthrough

1. Fill in the defaults block

At the top of the form you’ll see a block labelled with prefix, domain, host count, and network/VLAN inputs. Fill in:

Hit Apply. The tool populates host tables, IP addresses, and VLAN fields across every other tab based on these defaults.

2. Overview tab

High-level SDDC identity and shared settings:

• SDDC ID and VCF Instance Name — logical identifiers used by SDDC Manager.
• Workflow Type — VCF (full) or VVF (VMware vSphere Foundation, lighter stack without NSX/Operations).
• DNS and NTP servers — at least one primary of each is required.
• Datacenter and Cluster names — match whatever naming convention you’re using.
• Global Password — optional convenience. If set, this password is used for every component that doesn’t have an explicit password.

3. Hosts tab

Per-host inventory. Each row corresponds to one ESXi host and includes:

• Hostname (esx01.corp.local), management IP, root password
• vMotion IP, vSAN IP (if using vSAN), TEP IP
• If using vSAN: cache and capacity disk identifiers (for OSA) or storage tier devices (for ESA)

Use the Paste buttons if you have the host list elsewhere (spreadsheet, CSV) — they accept columns of IPs and will populate the rows.

4. vCenter tab

• vCenter FQDN — must resolve in your DNS (or SDDC Manager will fail pre-checks).
• VM Size — tiny, small, medium, large, xlarge. Match to your scale; see the VMware Config Maximums for limits.
• SSO Domain — default vsphere.local. If you use a different SSO domain convention, set it here.
• Root and SSO Admin passwords.

5. Networking tab

The vDS (Distributed Virtual Switch) and network segment configuration:

• DVS name (default <prefix>-cl01-vds01)
• MTU — 9000 for jumbo frames (recommended). Must match your physical switch config.
• Load balancing policy — typically Route based on originating virtual port (Source Port ID) unless you have a specific reason (LAG, source MAC hash).
• Network segments — the CIDR/VLAN pairs from the defaults block, already populated.

6. NSX tab

NSX Manager cluster config:

• Three-node NSX Manager cluster with VIP (production). For labs, a single node is acceptable.
• Shared credentials — admin, audit, root, CLI passwords.
• TEP & Transport — the TEP network from the defaults block. Transport type is OVERLAY for VXLAN/GENEVE tunnels or VLAN if you’re not doing overlay.

7. Storage tab

See Choosing a storage type below. Pick one:

• vSAN ESA — recommended for new all-NVMe deployments on VCF 9.
• vSAN OSA — legacy hybrid/all-flash with cache+capacity disk groups.
• NFS — external NFS array. Requires server IP, export path, and datastore name.
• VMFS on FC — existing FC SAN. Requires LUN/WWN mapping details.

8. Operations tab

Only applies if you’re deploying VCF (not VVF):

• VCF Operations — the unified ops console (formerly vRealize Operations Manager).
• Fleet Management — lifecycle and patching.
• Operations Collector — if you need a separate collector appliance.

9. Automation tab

VCF Automation (formerly vRealize Automation) for self-service VM provisioning. Optional — skip if you’re not using it.

10. Export

Click Copy JSON to copy to clipboard, or Export JSON to download a .json file. The JSON is ready to feed directly into the VCF Installer.

Section-by-section reference

Top defaults block — all fields

Tabs

• Overview — SDDC identity, DNS/NTP, datacenter & cluster names, CEIP opt-in, global password.
• Hosts — per-host FQDNs, IPs (mgmt/vMotion/vSAN/TEP), root passwords, vSAN disk claims.
• vCenter — vCenter FQDN, VM size, SSO domain, root & SSO admin passwords.
• SDDC Manager — SDDC Manager FQDN, root/SSH/local passwords (under Overview).
• Networking — DVS name, MTU, load-balancing policy, network segments.
• NSX — NSX Manager cluster (3-node + VIP), credentials, TEP configuration, transport type.
• Storage — vSAN ESA/OSA, NFS, or VMFS-FC with specific fields per type.
• Operations — VCF Operations, Fleet Management, Operations Collector appliances.
• Automation — VCF Automation appliance details.

Choosing a storage type

The Storage tab changes its inputs based on the storage type you select:

vSAN ESA (Express Storage Architecture)

VCF 9 default for new all-NVMe deployments. Single tier — every disk is a storage device, no cache/capacity split.

• Pros: simpler config, better performance with NVMe, native compression
• Requires: all-NVMe hosts on the vSAN ESA HCL
• Fields: per host, list the NVMe device paths (naa.xxxx) that back vSAN

vSAN OSA (Original Storage Architecture)

The classic hybrid/all-flash model with cache + capacity disk groups.

• Pros: works with mixed hardware
• Fields: per host, cache device + list of capacity devices per disk group
• Limit: up to 5 disk groups per host

NFS

External NFS array mounted as the primary datastore.

• Fields: NFS server IP or FQDN, export path (/vol/vcf01), datastore name, read-only flag

VMFS on Fibre Channel

Existing FC SAN presenting LUNs to all hosts.

• Fields: LUN WWN, datastore name, shared across all hosts in the cluster

Examples

Common mistakes

Related tools

Tools that pair well with the JSON Builder:

FAQ