VCF 9.0 vs 9.1: IP and DNS Planning for Internal Components

FQDNs and IP addresses

Before getting into the design logic, the useful planning question is simple: for each component, how many FQDNs and IP addresses does the worksheet expect?

The planning trap

"How many IPs does VCF need?" sounds simple, but it breaks down almost immediately. A small management domain without Edges, Automation, Logs, or Kubernetes is a very different planning exercise from a full VCF fleet with HA services, workload domains, NSX Edge clusters, and VKS.

The better question is:

Which VCF layers am I enabling, and which of those layers create management endpoints that need IP addresses, FQDNs, and DNS records?

The other mistake is treating every VCF 9.1 item like an appliance with one IP and one DNS name. The workbook does not model it that way. It has named endpoints that need DNS, and it also has address ranges that are consumed by the services runtime.

How to read the matrix

The workbook gives a clear DNS rule: create PTR and A records for all FQDNs listed in the Management Domain Creation, Workload Domain Creation, and Cluster Creation sections. If the workbook lists only an IP range, treat it as reserved address capacity, not as a per-address DNS requirement.

That distinction matters most in VCF 9.1. Management Services is a services layer above the base SDDC appliances. It has named endpoints, and it also has an IP range for the VCF services runtime. Components such as Software Depot, lifecycle management, Identity Broker, SALT, Real-time Data, and Log Management are enabled or sized within that services/runtime model instead of always appearing as one appliance, one IP, and one DNS name.

VCF 9.0 internal IP and DNS requirements

VCF 9.0 introduced the fleet model and a more integrated operations experience. From an IP/DNS perspective, I would plan it in these layers.

VCF 9.1 internal IP and DNS requirements

VCF 9.1 keeps the same basic infrastructure shape, but the planning worksheet gets more service-oriented. The major difference is not that vCenter or NSX suddenly disappear. The difference is that VCF management services, licensing, depot, and activation workflows become more visible as platform services that also need to be planned.

What changed from 9.0 to 9.1

The clean way to compare 9.0 and 9.1 is not to pretend every component changed. Most of the core infrastructure planning remains familiar: hosts need management IPs, vCenter needs DNS, NSX needs management endpoints, and workload domains repeat the pattern.

The difference is that VCF 9.1 gives more weight to services that sit above the core SDDC layer.

The decision tree

I would build the worksheet in this order before starting a deployment.

Start with the management domain
  Add ESXi management IPs and DNS
  Add VCF Installer IP/FQDN
  Add management vCenter IP/FQDN
  Add SDDC Manager / fleet management endpoint
  Add NSX Manager node IPs and VIP/FQDN

Then ask:
  HA for this service?
    Add node IPs/FQDNs and VIP/FQDN

  NSX Edge required?
    Add Edge management IPs/FQDNs
    Add Edge TEP pool
    Add Edge uplink IPs

  VCF Operations required?
    Add VCFO endpoint, node IPs, collector IPs as needed

  VCF Automation required?
    Add VCFA endpoint and node/service IPs as needed

  Logs required?
    Add log endpoint and node IPs as needed

  VCF 9.1 services required?
    Add the 4 named Management Services endpoints
    Add the separate License Server FQDN
    Reserve VCF Management Services IP Range: 12 minimum, 30 for growth
    Add VCF Automation endpoint/range if VCFA is deployed

  VKS/Supervisor required?
    Add supervisor control plane IPs
    Add Kubernetes API endpoint/FQDN
    Add ingress and egress pools
    Add wildcard/application DNS as needed

  Workload domain required?
    Repeat host, vCenter, NSX, Edge, and Kubernetes decisions

The worksheet columns I would use

The final output should not just be a list of names. It should be a table that an engineer can hand to DNS, network, security, and the deployment team.

The lesson

VCF 9.0 and 9.1 are close enough that it is tempting to reuse the same IP spreadsheet. That is mostly fine for the base SDDC layer, but it is not enough for the full platform.

The 9.1 planning shift is that more of the platform shows up as services: licensing, depot, management services, activation, and fleet-level operations. Those services need the same boring but critical planning as every other infrastructure endpoint: IPs, FQDNs, A records, PTR records, certificates, and clear ownership. The important wrinkle is that the VCF Management Services range is not one DNS record per address. It is a service-runtime pool, and the workbook explicitly tells you to reserve at least 12 IPs, or 30 if you want room for more components and auto-scaling.

References

• VMware Cloud Foundation 9.1 Planning and Preparation Workbook
• Operations in VMware Cloud Foundation 9.0
• Scale, Simplify, and Secure Your Private Cloud Operations with VCF 9.1
• VCF 9.1 Licensing: Programmatic, Centralized, and Built to Scale
• VMware Cloud Foundation 9.1 FAQ