Before you start the VMware Cloud Foundation (VCF) Installer, spend a few minutes on pre-checks. The installer does run its own validation, but the two issues that cause most failed deployments, DNS (both forward and reverse) and time sync, are far easier to fix on the ESX host shell than halfway through a deployment. Below is a checklist for a fresh VCF 9.x management domain deployment: the host-level pre-checks, the firewall and port rules the customer must open, MTU per traffic type, and password rules. Every item can be verified or prepared before deployment day.
A. Pre-Installation Checks
Run these on each ESX host shell (SSH) unless noted otherwise.
| # | Check | How to verify | Pass criteria |
|---|---|---|---|
| 1 | Depot connectivity | nc -zv dl.broadcom.com 443 then curl -v https://dl.broadcom.com | Port open and TLS handshake completes |
| 2 | ESX build matches VCF 9.x BOM | vmware -v | Matches the BOM for your target 9.x build |
| 3 | Forward DNS (hosts and mgmt VMs) | nslookup <esxi-fqdn> | Returns the correct IP |
| 4 | Reverse DNS (PTR) | nslookup <esxi-ip> | Returns the correct FQDN |
| 5 | DNS servers set | cat /etc/resolv.conf | Correct nameservers and domain |
| 6 | Hostname / FQDN correct | hostname -f | Full FQDN, matches DNS |
| 7 | NTP reachable and running | esxcli system ntp test | Reachable, offset near 0 |
| 8 | Time in sync across hosts | date on each host | All within 1 to 2 seconds |
| 9 | Host cert has FQDN (CN) | openssl x509 -in /etc/vmware/ssl/rui.crt -noout -subject | CN matches host FQDN; if not, run /sbin/generate-certificates, restart hostd/vpxa |
| 10 | SSH / Shell enabled | esxcli network firewall ruleset list -r sshServer | SSH enabled (the installer needs it) |
| 11 | Physical NICs up | esxcli network nic list | Required vmnics Link=Up, correct speed |
| 12 | Mgmt VMkernel and gateway reachable | vmkping -I vmk0 <gateway-ip> | Replies |
| 13 | Deploy host port group matches mgmt network | esxcli network vswitch standard portgroup list | Port group / VLAN matches mgmt subnet |
| 14 | Jumbo MTU end to end (vMotion/vSAN) | vmkping -I vmkX -d -s 8972 <peer-ip> | Replies, no fragmentation (see Section C) |
| 15 | Overlay / TEP minimum MTU (1600) | vmkping -I vmkX -d -s 1572 <peer-ip> | Replies, confirms a 1600 or higher path |
| 16 | Mgmt IPs free (Installer, vCenter, SDDC Mgr / Operations, NSX mgrs and VIP, Automation) | ping <ip> for each | No reply (IP unused / reserved) |
| 17 | Storage ready | vSAN: disks eligible / external: esxcli storage filesystem list | Datastore mounted or vSAN disks claimable |
| 18 | Firewall / ports open | Validate per Section B | Depot, management, and infra ports reachable |
| 19 | Passwords meet rules | Pre-stage per Section D | All accounts compliant |
| 20 | Download token and licenses | Generate token at support.broadcom.com | Token valid, license keys on hand |
B. Firewall and Port Requirements
Open these source-to-destination flows before deployment day. The depot egress to dl.broadcom.com on TCP 443 is the one customers most often miss. Validate the depot reachability first, then the management and infrastructure flows. The live, always-current reference is the VMware Ports and Protocols tool (select VCF 9.0).
| Source | Destination | Protocol / Port | Purpose | Direction |
|---|---|---|---|---|
| Depot / Internet (validate depot configuration) | ||||
| VCF Installer | dl.broadcom.com | TCP 443 (HTTPS) | Online depot during bring-up (download binaries) | Outbound |
| SDDC Manager | dl.broadcom.com | TCP 443 (HTTPS) | Online depot: vCenter / ESXi / NSX binaries | Outbound |
| Fleet Manager (VCF Operations) | dl.broadcom.com | TCP 443 (HTTPS) | Depot: VCF Operations / Automation / Identity Broker binaries | Outbound |
| SDDC Manager / Fleet Manager | Proxy server (if used) | TCP <proxy port> | Internet via proxy (no Kerberos / NTLMv2) | Outbound |
| VCF components | Offline depot host (if used) | TCP 443 / 80 | Local / offline depot (alternative to internet) | Internal |
| Core management plane | ||||
| SDDC Manager | vCenter, NSX Manager | TCP 443 | Management / API | Internal |
| SDDC Manager | ESXi hosts | TCP 443, 902 | Host management | Internal |
| SDDC Manager | ESXi / appliances | TCP 22 (SSH) | Lifecycle / configuration | Internal |
| vCenter <-> ESXi | ESXi / vCenter | TCP 443, 902 | Provisioning / heartbeat | Internal |
| Admin / operators | vCenter, NSX, SDDC, Ops UIs | TCP 443 | Management UI / API | Internal |
| Infrastructure services | ||||
| All management appliances | DNS servers | UDP/TCP 53 | Name resolution (fwd + reverse) | Internal |
| All management appliances | NTP servers | UDP 123 | Time synchronisation | Internal |
| All management appliances | Syslog server | UDP/TCP 514 | Logging | Internal |
| VCF Operations / SDDC Manager | SMTP relay | TCP 25 / 587 | Alert email | Internal |
| Management appliances | AD (LDAP / LDAPS) | TCP 389 / 636 | Directory authentication | Internal |
| Management appliances | AD Global Catalog | TCP 3268 / 3269 | Directory authentication | Internal |
| Management appliances | AD Kerberos | TCP/UDP 88 | Kerberos authentication | Internal |
| Monitoring (if used) | SNMP / NMS | UDP 161 / 162 | SNMP monitoring / traps | Internal |
| Certificates and backup | ||||
| Management appliances | Certificate Authority (if external CA) | TCP 443 / 80 | CSR signing / certificate enrollment | Internal |
| SDDC Manager, vCenter, NSX Manager | SFTP backup server | TCP 22 | File-based backups (SFTP only) | Internal |
| Storage | ||||
| ESXi iSCSI VMkernel | iSCSI array | TCP 3260 | Block storage (MTU 9000) | Internal |
| ESXi vSAN VMkernel | ESXi vSAN VMkernel | TCP/UDP 2233 | vSAN data / clustering (MTU 9000) | Internal |
| NSX / overlay / Federation | ||||
| ESXi TEP | ESXi TEP | UDP 6081 (GENEVE) | NSX overlay (MTU 1600+ / 9000) | Internal |
| NSX Manager nodes | NSX Manager nodes | TCP 443, 1234, 1235 | NSX cluster / controller | Internal |
| NSX Edge | NSX Manager | TCP 443, 1235 | Edge management | Internal |
| NSX Global Manager | GM / LM (cross-site) | TCP 443, 1236 | Federation sync (active-standby) | Site-to-site |
| vMotion and data collection | ||||
| ESXi | ESXi | TCP 8000 | vMotion | Internal |
| Cloud Proxy | VCF Operations | TCP 443 | Operations data collection | Internal |
| Collector | VCF Operations for Networks | TCP 443 / IPFIX | Flow / network data | Internal |
C. MTU per Traffic Type (VLAN Trunk)
The physical trunk has to carry the highest MTU you use, so set the switch ports to 9000 (jumbo) and let each VMkernel use the value below. The host-overlay / TEP network must be at least 1600 bytes because of Geneve encapsulation.
| Traffic | Recommended MTU | Minimum | Notes |
|---|---|---|---|
| Management | 1500 | 1500 | Default; jumbo not required |
| vMotion | 9000 | 1500 | Jumbo improves throughput |
| vSAN | 9000 | 1500 | Jumbo strongly recommended |
| Host Overlay / TEP (Geneve) | 1700 (or 9000) | 1600 | Must be 1600 or higher for Geneve. 1700 leaves room for the header |
| Edge Uplink | 9000 | 1600 | Match the overlay / physical path |
| Physical switch trunk | 9000 | 1600 | Must equal the largest VMkernel MTU on the path |
vmkping -d -s uses a payload size of MTU minus 28, so test 9000 with 8972 and 1600 with 1572.
D. Password Requirements
VCF components have different minimums. NSX needs 12 or more, and VCF Operations is the strictest at 15 characters. The simplest safe approach is to make every account password 15 characters or more with full complexity, which satisfies every component at once.
| Rule | Value |
|---|---|
| Minimum length | 15 characters (use this everywhere to satisfy all components) |
| Uppercase | at least 1 |
| Lowercase | at least 1 |
| Number | at least 1 |
| Special character | at least 1 |
| Not allowed | spaces, dictionary words, simple sequences |
For the exact per-component minimums, check Broadcom’s “Default Password Requirements for VCF Components” documentation.
E. IP Address Requirements by Scenario
Every component with an FQDN needs one static IP with working forward and reverse DNS. Two rules matter. The FQDN addresses must not sit inside the range you give VCF Management Services, and that range must be contiguous, a minimum of 12 addresses with 30 recommended so the Day-N services that run on it have room. The /27 recommendation applies to the Management Services range, not the whole management network, so a full HA build needs more than a single /27.
| Scenario / component | Simple | High availability | Notes |
|---|---|---|---|
| Management domain (first VCF instance) | |||
| vCenter | 1 | 1 | Static IP and DNS |
| NSX Manager nodes | 1 | 3 | |
| NSX Manager cluster VIP | 1 | 1 | |
| SDDC Manager | 1 | 1 | |
| VCF Operations | 2 | 5 | Simple: primary and cloud proxy. HA adds replica, data, optional load balancer |
| License Server | 1 | 1 | |
| VCF Automation | 7 | 7 | 2 FQDNs plus 5 node addresses |
| VCF Management Services FQDNs | 4 | 4 | Fleet, instance, runtime, identity broker |
| VCF Management Services runtime range | 12 min, reserve 30 | 12 min, reserve 30 | Contiguous. The /27 recommendation is for this range |
| Per-host networks (multiply by host count) | |||
| ESXi management | 1 per host | 1 per host | |
| vMotion | 1 per host | 1 per host | |
| vSAN | 1 per host | 1 per host | When vSAN is the storage |
| Host overlay TEP | 1 to 2 per host | 1 to 2 per host | From the NSX TEP pool |
| Optional Day-N components | |||
| VCF Operations for Logs | 6 | 6 | Plus 2 per extra replica. Uses the Management Services range |
| Real-time metrics | 6 | 6 | Uses the Management Services range |
| VCF Operations for Networks | 2 | 2 | Platform and collector, own appliances |
| VCF Automation (added later) | 5 | 5 | Plus 2 FQDNs. Reserve even if not deployed on day one |
| Networking add-ons | |||
| NSX Edge node management | 1 per node | 1 per node | Two or more nodes per cluster |
| NSX Edge TEP | 1 to 2 per node | 1 to 2 per node | Edge TEP pool, can share host TEP VLAN |
| Tier-0 uplinks | 1 per uplink per node | 1 per uplink per node | Plus peer addresses on the physical routers |
| Avi Controller | 1 | 3 | Use 3 for production |
| Avi controller cluster VIP | 0 | 1 | For the 3 node cluster |
| Avi Service Engine management | Pool, 2 or more | Pool, 2 or more | DHCP or static pool |
| Avi virtual service VIPs | Pool per app | Pool per app | Size for published applications |
| Other scenarios | |||
| VI workload domain | vCenter 1, NSX 1 and VIP | vCenter 1, NSX 3 and VIP | Plus per-host networks. Shared NSX saves the NSX addresses |
| Additional VCF instance | vCenter 1, NSX 1 and VIP, SDDC 1, cloud proxy 1, MS range 12/30 | NSX 3 and VIP | No second fleet node set |
| vSphere Foundation (VVF) | vCenter 1, Operations 1, MS range 10/30, logs 6 | same | Lighter platform |
| Data Services Manager | 1 appliance plus 1 per database VM | same | Size a pool for the database count |
| HCX | 1 manager per site plus service mesh pool | same | Addresses per network profile |
| Stretched cluster | Per-AZ host networks plus 1 witness | same | Doubles the host networks across zones |
Source: Broadcom VCF Components FQDNs and IP Addresses (VCF 9.1).
Bottom Line
If you only have time for three checks before you deploy: confirm forward and reverse DNS for every host and management component, confirm NTP time sync across all hosts, and confirm the host certificate CN matches the FQDN. After those, the next most common blocker is the firewall: make sure dl.broadcom.com on TCP 443 (or your offline depot) is reachable. Validate everything in the sections above before deployment day and the bring-up will run clean.
Reference: Broadcom TechDocs, VMware Cloud Foundation 9.x (deployment, vSAN network design, MTU guidance, password requirements) and the VMware Ports and Protocols tool (ports.broadcom.com). Always check against the BOM and the ports tool for your specific 9.x build.
About The Author
DrJha