Back in February I shared a post called VMware Cloud Builder – Bringup Validation for VMware Cloud Foundation, where I discussed details around changes relating to the validation modules used within VMware Cloud Builder for VMware Cloud Foundation 4.2. At the time I promised to share more details on what each validation module actually did, due to work commitments its taken a bit longer to put this together but finally here is the detail I was promising.
SECURE_PLATFORM_AUDIT
- Validates the ESXi host thumbprints from the configuration file (if provided and validation is not skipped)
- Extracts SSL certificate from the ESXi hosts and adds them to a temporary trust store which is used during the whole validation (specific per validation run)
- Extracts SSH keys from the ESXi hosts and adds them to a temporary known_hosts which is used during the whole validation (specific per validation run
- Validates the ESXi host SSL certificate contains a common name that matches the FQDN of the host
JSON_SPEC_VALIDATION
- Validates blank input values where a value is mandatory
- Validates missing elements for mandatory values
- Validates input values for correctness
CLOUDBUILDER_READY_VALIDATION
- Validates the NTP Server configuration of Cloud Builder (/etc/ntp.conf) matches the supplied value in the configuration file
- Validates the DNS Server configuration of Cloud Builder /etc/resolve.conf) matches the supplied value in the configuration file
LICENSE_KEY_VALIDATION
- Validates the format of the product license key(s) is valid (Contains the format xxxxx-xxxxx-xxxxx-xxxxx-xxxxx)
- Validates the product license keys against a dormant license file (DLF)
- Validates CPU count against license key provided for ESXi
- Validates that an ESXi license key is provided
PASSWORDS_VALIDATION
- Validates that the passwords provided match the password policy of the product, the checks include:
- Validates the password has the minimum length of characters
- Validates the password has the maximum length of characters
- Validates the password contains lower-case characters
- Validates the password contains upper-case characters
- Validates the password contains numerical characters
- Validates the password contains special characters (e.g. @!#$%?^)
- Validates the password DOES not contain ambiguous characters
- Validates the password is not simplistic (NSX-T Data Center passwords)
NETWORK_IP_POOLS_VALIDATION
- Validates sufficient IP Addresses have been provided for each network
- Performed against the vMotion and vSAN networks
- Validates the IP Addresses are within the specified network
- Validates that individual IP Addresses included are within the specified network
HOST_IP_DNS_VALIDATION
- Validates reverse lookup of the IP address against the DNS Servers defined in the configuration file
- Validates forward lookup of the FQDN against the DNS Servers defined in the configuration file
- If multiple DNS Servers are provided the check is performed against each DNS Server to ensure the DNS records are in-sync across the systems
NETWORK_CONFIG_VALIDATION
- Validates the network configuration by performing the following checks:
- Validates that the required network types are available
- Validates that each IP Address is valid for the relevant subnet
- Validates that each IP Address is not in use
- Validates that each gateway IP is valid for the relevant subnet
- Validates that each gateway IP is contactable (MANAGEMENT and NSXT_EDGE_TEP Networks Only)
- Validates VLAN IDs are in the supported range (0-4095)
- Validates MTUs are in the supported range (1500 – 9000)
- Validates the subnet CIDRs are in correct format
- Validates host gateways match network gateway
- Validates that each ESXi Host can contact the DNS Servers Validates all NTP servers are reachable from all ESXi hosts
ESXI_HOST_READINESS_VALIDATION
- Validates the ESXi host is not in maintenance mode
- Validates the TSM-SSH Service is running on each ESXi host
- Validates the TSM-SSH Service Policy has been configured to ‘Start and Stop with the Host’
- Validates the NTP Service is running on each ESXi host
- Validates the NTP Service Policy has been configured to ‘Start and Stop with the Host’
- Validates the ESXi host has a license associated (eval is OK) with it and that it has not expired
- Validates the ESXi hostname matches the supplied value in the configuration file (relies on DNS being accurate)
- Validates the ESXi host gateway matches the supplied value in the configuration file
- Validates the ESXi host only has one vmnic connected to the vSphere Standard Switch based on the supplied values in the configuration file
- Validates the ESXi host vSphere Standard Switch matches the supplied value in the configuration file
- Validates the ESXi host only contains a single vSphere Standard Switch
- Validates the ESXi host has the portgroup named ‘VM Network’ present (vSAN Ready Node Only)
- Validates the ESXi host ‘VM Network’ portgroup VLAN ID matches the Management network VLAN ID supplied value in the configuration file
- Validates the ESXi host Management interface (vmk0) VLAN ID matches the Management network VLAN ID supplied value in the configuration file
- Validates the ESXi host Management interface (vmk0) subnet mask matches the Management network subnet mask supplied value in the configuration file
ESXI_VERSION_VALIDATION
- Validates that each ESXi host has the correct version and build of ESXi installed
- Based on manifest information for the release (/mnt/iso/sddc-foundation-bundle-x.x.x.x-xxxxxxxx/manifest.json)
TIME_SYNC_VALIDATION
- Validates that VMware Cloud Builder and each ESXi host can connect to the NTP Servers
- Validates that the NTP Server(s) are marked as a source by the NTP Daemon
- Validates that the sync between the NTP Server and ESXi host have an offset below 30 seconds
- Validates that the time drift between the NTP Server and ESXi host does not exceed 30 seconds
VSAN_AVAILABILITY_VALIDATION
- Validates VSAN disks for ESXi host by performing the following checks:
- Validates there is at least one boot disk to meet requirements
- Validates cluster size is big enough
- Validates if cache disk is clean
- Validates if cache disk is available and not already part of a vSAN cluster
- Validates if VSAN DedupScope is set to default value -0.
MANAGEMENT_NETWORKS_VALIDATION
- Validates connectivity for the following networks:
- vMotion
- vSAN
- Creates vmk adapters on all ESXi hosts
- Validates all hosts can vmkping each other from the created vmk adapter
NSXT_NETWORKS_VALIDATION
- Validates connectivity for the following networks (There are two validation scenarios):
- NSX-T Host Overlay
Scenario 1 – If we have enough IP addresses to perform the validation:
- Creates vmk adapters on all ESXi hosts
- Validates all hosts can vmkping each other from the created vmk adapter
Scenario 2 – If we have limited IP addresses to perform the validation:
- Create vmk adapter on first host with the first available IP and a vmk on second host using the next available IP
- Perform a vmkping to the second host from the first one
- Delete the vmk from the second host and push it to the of the list of available Ips
- Create vmk on third host and perform vmkping from the first one. Then delete the vmk, repeating on remaining hosts
- Once vmkping complete to all hosts from the first host, we delete the vmk of the first host and create it on the second host. This is repeated until all hosts have performed a vmkping from their self out to all other hosts and the gateway
AVN_NETWORKS_VALIDATION
- Validates connectivity for the following networks (There are two validation scenarios):
- NSX-T Edge Overlay
- NSX-T Uplink 1
- NSX-T Uplink 2
- NSX-T Host Overlay to Edge Overlay
Scenario 1 – If we have enough IP addresses to perform the validation:
- Creates vmk adapters on all ESXi hosts
- Validates all hosts can vmkping each other from the created vmk adapter
Scenario 2 – If we have limited IP addresses to perform the validation:
- Create vmk adapter on first host with the first available IP and a vmk on second host using the next available IP
- Perform a vmkping to the second host from the first one
- Delete the vmk from the second host and push it to the of the list of available Ips
- Create vmk on third host and perform vmkping from the first one. Then delete the vmk, repeating on remaining hosts
- Once vmkping complete to all hosts from the first host, we delete the vmk of the first host and create it on the second host. This is repeated until all hosts have performed a vmkping from their self out to all other hosts and the gateway
My Cloudy World 