#Preparing Parameters for a VMware vSphere Cluster

This document helps you collect the values required to create a VMware vSphere workload cluster from the global cluster. Complete this checklist before you apply the manifests in Create a Cluster in the global Cluster.

#Scenarios

Use this checklist in the following scenarios:

• You are preparing a new VMware vSphere cluster deployment.
• You want to validate external dependencies before you start the deployment.
• You plan to enable extension scenarios such as multiple datacenters, multiple NICs, or extra worker nodes.

#Prerequisites

Before you begin, ensure the following conditions are met:

• You can access the global cluster with kubectl.
• You know which namespace will store the workload cluster objects.
• You have access to the target vCenter inventory, networks, datastores, and templates.

#How to Use This Checklist

Use this checklist in the following order:

1. Collect the deployment parameters listed in this document.
2. Replace every placeholder in the manifest templates with the actual values collected here.
3. Reuse the same value everywhere a placeholder appears in multiple manifests.
4. If an optional feature is not enabled, remove the corresponding YAML block exactly as described in the extension document.
5. If an optional field (such as deviceName) is not needed, remove the entire line from the YAML manifest.

#Terminology

The following terms are used consistently throughout the VMware vSphere cluster-creation documents.

#CAPV static allocation pool

A CAPV static allocation pool is the VSphereResourcePool custom resource. It predefines node slots. Each slot can include:

• A node hostname
• A target datacenter
• Static IP configuration for each NIC
• Persistent disk definitions

#Node slot

A node slot is an entry under VSphereResourcePool.spec.resources[]. A single slot usually maps to one node, such as cp-01 or worker-01.

#deviceName

deviceName is an optional field in the VSphereResourcePool network configuration. It is used to control the NIC name seen inside the guest operating system, such as eth0 or eth1.

Use the following distinctions when you fill the values:

• networkName is the vCenter network or port group name.
• deviceName is the NIC name inside the guest operating system.
• If deviceName is omitted, CAPV typically assigns names such as eth0, eth1, and eth2 by NIC order.

#vCenter resource pool

A vCenter resource pool is the native vCenter inventory object, for example:

/Datacenter1/host/cluster1/Resources

This value is different from CAPV's VSphereResourcePool. In the extension scenarios, this path is used by VSphereDeploymentZone.spec.placementConstraint.resourcePool.

#Compute cluster

The compute cluster is the target vCenter compute-cluster name. In these documents, it is primarily used when a VSphereFailureDomain is mapped to a specific deployment target.

#Datastore

The datastore is the vSphere storage location that stores VM disks. Both system disks and data disks must be placed on concrete datastores.

#VM template

The VM template is the source template used to create node virtual machines. When you enable multiple datacenters, the same template must already exist in every target datacenter and must be resolvable by the same template name.

#Thumbprint

The thumbprint is the SHA-1 fingerprint of the vCenter server certificate. CAPV uses it to validate the target vCenter server.

Use the following command to retrieve it:

openssl s_client -connect <vsphere_server>:443 -servername <vsphere_server> </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha1

#Management Cluster Prerequisites

Use the following table to record the required values and validation results.

#vCenter and Template Prerequisites

#vCenter connection information

Note: These documents assume the default vCenter HTTPS port 443.

#VM template requirements

The template should also meet the following requirements:

• It uses an operating system supported by your platform image policy.
• It includes cloud-init.
• It includes VMware Tools or open-vm-tools.
• It includes containerd.
• It includes the baseline components required by kubeadm bootstrap.

#Load Balancer Prerequisites

#Cluster Baseline Parameters

#Minimum Single-Datacenter Parameters

#Datacenter and resource placement

#Primary NIC parameters

#Control plane static allocation pool

#Worker static allocation pool

#Compute sizing

#vSphere CPI parameters

#Optional Extension Parameters

#Multiple datacenters and multiple failure domains

#Second NIC parameters

#Data disk extensions

#Final Readiness Check

Before you start the deployment, confirm all of the following items:

1. The global cluster is reachable.
2. Ensure that the two cluster plugins are installed: Alauda Container Platform Kubeadm Provider and Alauda Container Platform VMware vSphere Infrastructure Provider.
3. ClusterResourceSet=true is enabled.
4. The vCenter server, username, password, and thumbprint are collected.
5. The control plane VIP, load balancer, and port 6443 are ready.
6. The Pod CIDR, Service CIDR, and kube-ovn-join-cidr do not overlap with existing networks.
7. The VM template is available in every required datacenter.
8. The required datastores and vCenter resource pool paths are confirmed.
9. The static allocation pool values for the minimum single-datacenter topology are complete.
10. The baseline system disk and data disk sizing is confirmed.
11. Every required parameter has a real value.

#Next Steps

After you complete this checklist, continue with Create a Cluster in the global Cluster.