The VCF Readiness Assessment: What It Is and Why Skipping It Is Expensive

The most predictable VCF deployment delays I've seen have almost nothing to do with VCF. They come from DNS records that weren't created, MTU settings that weren't validated end-to-end, firmware levels that didn't match the compatibility guide for the version being deployed, and NTP drift that causes authentication failures in ways nobody connects to the time source problem until well into the troubleshooting session. None of those are exotic failure modes. They're the same short list of prerequisites that surface as deployment blockers on nearly every engagement where the team went straight from design sign-off to scheduling the bring-up window.

A readiness assessment exists to find them beforehand. What it covers, and what a useful deliverable looks like, is worth being specific about — because "we ran a readiness check" can mean anything from a genuine structured evaluation to someone walking through the VCF Installer prerequisites checklist the afternoon before the deployment window.

Why the VCF Installer's Own Validation Isn't Enough

The VCF Installer — the appliance that replaced Cloud Builder starting with VCF 9 — runs its own pre-validation before bring-up starts. It checks DNS resolution, NTP reachability, host connectivity, NIC speed, vSAN hardware compliance. Unlike older VCF versions where you could sometimes work around prerequisite gaps mid-installation, the VCF 9 Installer enforces its pre-checks as hard gates: if any check fails, bring-up stops. The distinction between that built-in validation and a proper readiness assessment is partly about what gets checked, and mostly about when you find out something is wrong.

When the VCF Installer surfaces a failure, you remediate it and restart from the beginning. There's no resume from a partially completed deployment. In a well-prepared environment with one clean problem, that's a minor delay. In an environment that hasn't been properly assessed, it's a cascade: fix the DNS issue, restart, discover the MTU problem, restart again, hit a firmware compatibility question that requires a vendor escalation, have a conversation with leadership about why the go-live window needs to move. Some failure modes — like IP segments already in use by other components — require reimaging the ESX hosts entirely before you can retry.

Catching problems in a structured assessment two weeks before the deployment window is a different operational reality than catching them in the VCF Installer wizard at 10pm on a Friday.

DNS: The Failure That Looks Like Something Else

The VCF Installer requires both forward and reverse DNS records — A records and PTR records — for every component it's going to deploy before it will proceed. SDDC Manager, vCenter, all three NSX Manager nodes in an HA deployment, the ESXi hosts, the VCF Installer appliance itself. That's a significant number of DNS entries that all need to exist, resolve correctly, and be reachable from the bring-up network before the wizard starts. In VCF 9, the Installer also requires that the SDDC Manager FQDN be entirely lowercase — a known issue causes deployment to fail mid-run with a CS_APPLIANCE_CERT_ALIAS_LOWERCASE certificate error if any uppercase characters appear in the SDDC Manager FQDN. The workaround is to modify the DNS record and retry. The readiness assessment is the right time to validate FQDN case conventions, not after the deployment fails mid-step.

The DNS failure mode when something is wrong isn't always a clean error message. It can surface as a retriable resolution failure in the deployment logs — the Installer retrying the operation multiple times before surfacing anything actionable to the UI. The first time you see it, parsing it takes longer than it should.

The PTR records are the ones that most commonly get missed. The process of creating DNS entries for a VCF deployment tends to be forward-lookup-first — create the A records, confirm they resolve, move on. The reverse lookup zone entries get created as an afterthought, or partially, or with a syntax error that makes the record present but not valid. The Installer doesn't always distinguish clearly between "PTR record doesn't exist" and "PTR record exists but resolves to the wrong FQDN" — both surface as a resolution failure.

A readiness assessment runs a full DNS audit: forward resolution from every IP to its FQDN, reverse resolution from every FQDN to its IP, cross-check that they match, and a case-convention check on all FQDNs. That takes an hour with a script. It finds the trailing period, the missing PTR for the third NSX manager node, and the uppercase character in the SDDC Manager FQDN before any of them halt a deployment mid-run.

MTU: The Failure That Doesn't Fail Cleanly

This is the more dangerous category because the VCF Installer will complete bring-up with an MTU mismatch between the physical switch configuration and the vSAN and NSX overlay VLANs. The environment comes up. Hosts join the cluster. vSAN reports healthy. NSX overlay tunnels establish. Everything looks correct until someone moves workload traffic and frames start fragmenting.

NSX Geneve overlay traffic requires a minimum of 1600 bytes MTU on the Host Overlay VLAN — 1600 is the documented minimum to accommodate the Geneve header overhead without forcing fragmentation. The recommended value for vSAN and NSX overlay traffic is 9000 (jumbo frames) end-to-end. An environment configured at 1500 on the overlay VLAN is below even the minimum and will fragment Geneve traffic. An environment configured at 1600 will avoid the minimum violation but will fragment frames in any path that introduces additional overhead — IPsec, VXLAN wrapped inside Geneve, anything that pushes the effective payload size past 1500.

The symptom is performance degradation or intermittent connectivity in workloads that appears nowhere near the network layer in most monitoring tools. The application team sees slow response times. The storage team sees elevated latency. The network team confirms the switch is "configured for jumbo frames" — and they're not wrong, the switch port was set, but an intermediate firewall in the path is still at 1500, or the upstream router interface was missed, or the vSAN VMkernel port has a different MTU than the underlying switch port it communicates through.

vSAN Hardware Compatibility

vSAN readiness is hardware-specific and version-specific in ways that don't always align neatly with what the hardware vendor tells you. Every component needs to appear on the VMware Compatibility Guide for the specific VCF version being deployed — not just the server model, but the firmware versions for the HBA, the SSD or NVMe devices, the NIC, and the BIOS. A server certified for VCF 5.1 at a given firmware combination may not be certified for 5.2 at that same combination because a component's HCL entry was updated.

There's an active known issue in VCF 5.2.2 where ESA host validation fails with "Host is not HCL compatible" during ESA-related workflows — commissioning a host, creating a domain with ESA datastore type, adding a host to an ESA cluster — even on hardware that's on the HCL. The documented workaround is to manually update the vSAN Hardware Compatibility database inside SDDC Manager, which pulls the current HCL data from the VMware depot. That's not in the default deployment workflow, it's not obvious if you haven't seen the issue before, and finding it during bring-up costs time that a readiness check would have surfaced as a prerequisite step.

The other vSAN prerequisite that catches brownfield environments: disk partition state. Every disk on every host participating in vSAN must have all partitions deleted before bring-up. Servers that were previously used for anything — a prior vSAN deployment, direct-attached storage for a different workload, a test environment that was cleaned up informally — have a non-trivial chance of having partition tables on some disks. vSAN initialization will fail on those disks, the error message will be specific about which disk on which host, and the fix is fast. But it requires a maintenance window to remediate on racked hardware if it's discovered during bring-up, whereas a pre-deployment disk audit takes minutes per host and finds it before anyone has a maintenance window pressure.

NTP and the Failures Nobody Connects to NTP

NTP synchronization is in every VCF prerequisite checklist, and it's the one that gets the least scrutiny because "is NTP working" feels like a question with an obvious answer. It usually is working. The edge cases are what create problems, and they manifest in ways that are hard to connect to the root cause.

VCF components — SDDC Manager, vCenter, NSX Manager, the ESXi hosts, the VCF Installer appliance — all need to be synchronized to the same time source, with time drift within a narrow tolerance. When they aren't, the failures don't announce themselves as time-related. Authentication operations fail because Kerberos tickets are time-sensitive and a clock that's 5 minutes off generates tokens that peers reject. Certificate validation fails because the current time falls outside the certificate's valid window as computed by a component whose clock is wrong. API calls between components fail intermittently in ways that produce HTTP 500 errors rather than clock-skew errors.

In VCF 9.1 specifically, Fleet Lifecycle tasks that fail due to an unreachable or incorrectly specified NTP server surface as "Status polling timed out" — not as "NTP unreachable." The actual error is buried in the build service logs as ntp.chain.validation.failed. This is a known issue with a documented KB. Finding it through log analysis mid-deployment takes considerably longer than verifying NTP reachability from each host in a pre-deployment audit.

A readiness assessment validates NTP synchronization by checking that each host and management component can reach the configured NTP server, that the NTP service is running, and that the current offset is within acceptable range — not just that the NTP configuration is present. Configuration present and synchronization actually occurring are different states that both present as "NTP is configured" in a casual check.

vLCM: The Lifecycle Posture Question That Can't Wait

If vLCM isn't part of the readiness conversation, it will be a painful conversation six months later. The vLCM image established at bring-up — the ESXi base image, hardware vendor add-on, firmware bundle — is the baseline every subsequent patch cycle operates against. Getting the composition right requires knowing the hardware profile in detail before bring-up, not after.

A vLCM image assembled without validating against the actual installed hardware doesn't fail at bring-up. Hosts join the cluster and everything looks correct. The failure surfaces months later when SDDC Manager tries to remediate hosts against the baseline and discovers the firmware components in the image don't match what's physically installed — because the BOM changed between design phase and delivery, or because the vendor shipped a different HBA revision than what was speced, or because the ESXi version in the image was pinned to one that's not compatible with a driver version the hardware requires. By then there are production workloads on those hosts and the remediation is careful, scheduled work rather than a pre-deployment configuration adjustment.

The readiness assessment is the right place to validate the vLCM image composition against the actual racked hardware — check the HBA firmware, validate the driver compatibility matrix, confirm the vendor add-on version matches what's installed. It takes a few hours with access to the hardware. It saves a maintenance window conversation with six months of production traffic on the cluster.

What the Deliverable Should Actually Look Like

A readiness assessment that produces a list of things that need to be done is only marginally more useful than no assessment at all. The people who need to act on the findings are usually different from the people who did the assessment — the network team needs to know which specific VLANs need MTU configuration and what value; the DNS administrator needs a specific list of records to create with exact format requirements; the systems team needs to know which firmware components need updating and to what version before the window.

Vague findings generate follow-up questions that take time to answer. "DNS needs to be fixed" requires a meeting to translate into action. "PTR record missing for 10.10.20.45, expected format: 45.20.10.10.in-addr.arpa pointing to sddc-manager.vcf.example.com" can be executed immediately by the DNS administrator without another call.

The go/no-go determination matters too. A readiness assessment that concludes with "some items to address" without a clear recommendation about whether the environment is ready to proceed puts the decision back on whoever is running the deployment window. The deliverable should say, clearly, whether the environment can proceed to bring-up on the scheduled date given the current state — and if not, what the specific blockers are, what their remediation requires, and what a realistic timeline looks like given who has to do the work.

Advisory findings — things that won't block bring-up but will create operational friction later — belong in the deliverable too, clearly separated from blockers. A fault domain configuration that creates recovery asymmetry under a specific failure scenario. A VLAN naming convention that will cause confusion during Day 2 operations. These don't delay go-live. They become the next six months' worth of operational debt if nobody acts on them before bring-up locks the configuration in.