Aggiungi un cluster vSphere a un dominio

Questo documento descrive come aggiungere un cluster vSphere a un dominio VMware Cloud Foundation (VCF) 9.1 esistente in VMware Solution su Google Cloud utilizzando le istanze bare metal di Compute Engine. Aggiungi un cluster quando devi scalare la capacità di calcolo e di archiviazione vSAN oltre un singolo cluster, isolare i workload o applicare immagini vSphere Lifecycle Manager (vLCM) o policy di archiviazione vSAN separate all'interno di un dominio esistente. Puoi aggiungere il cluster a uno dei seguenti domini nello stesso progetto, nella stessa rete virtual private cloud (VPC) e nella stessa zona:

  • Dominio di gestione: aggiunge un cluster gestito dal vCenter Server di gestione e da NSX Manager.
  • Dominio workload VI: aggiunge un cluster gestito dal vCenter Server del dominio workload e dalla relativa istanza di NSX Manager.

Riepilogo dell'architettura

Quando aggiungi un cluster vSphere a un dominio VCF esistente, il deployment utilizza la seguente architettura:

  • Host ESXi bare metal: ogni nuovo host ESXi è un'istanza bare metal z3-highmem-192-highlssd-metal collegata alle subnet di livello 2 esistenti della tua rete VPC (gestione ESXi, vMotion, vSAN e NSX Tunnel Endpoint (TEP)). Ogni host si connette tramite un'interfaccia di rete principale (nic0) e interfacce di rete dinamiche con tag VLAN.
  • Nessuna appliance di gestione aggiuntiva: poiché aggiungi il cluster al vCenter Server e a NSX Manager che gestiscono già il dominio di destinazione, non esegui il deployment di nuove appliance di gestione. Inoltre, non crei nuovi record Cloud DNS, servizi di backend, policy di alta affidabilità (HA) o regole di forwarding per l'appliance. Devi invece aggiungere i nuovi host ai gruppi di endpoint di rete (NEG) a livello di zona esistenti.
  • Allocazione e allineamento degli indirizzi IP: VCF alloca gli indirizzi IP vMotion e vSAN da un pool di rete, mentre NSX alloca gli indirizzi IP TEP (vmk10) da un pool di indirizzi IP NSX. Poiché nessuno dei due pool supporta l'assegnazione statica per host in VCF 9.1, durante il deployment allinei le NIC dinamiche di Compute Engine agli indirizzi IP allocati da VCF, mantenendo abilitate tutte le convalide VCF.

Prima di iniziare

Prima di creare il cluster, verifica i requisiti nelle sezioni seguenti e configura le variabili di ambiente.

Verifica i requisiti dell'ambiente

Verifica che il tuo ambiente soddisfi i seguenti requisiti:

  • Autorizzazioni: disponi dei ruoli Identity and Access Management (IAM) richiesti nel progetto di destinazione, tra cui Amministratore Compute (roles/compute.admin), Amministratore DNS (roles/dns.admin) e Secret Manager Secret Accessor (roles/secretmanager.secretAccessor).
  • Credenziali in Secret Manager: se hai modificato o ruotato le password di ESXi root, SDDC Manager, vCenter Server o NSX Manager in VCF dopo il deployment iniziale, Secret Manager non viene aggiornato automaticamente. Prima di eseguire i comandi in questo documento, aggiorna i secret corrispondenti in Secret Manager o fornisci direttamente le password aggiornate in modo che corrispondano alle tue credenziali VCF attive.
  • Integrità del dominio: il dominio di destinazione è integro (vCenter Server, vSAN, NSX Manager, SDDC Manager e VCF Operations) e non presenta attività non riuscita.
  • Immagine vSphere Lifecycle Manager (vLCM): un'immagine vLCM è disponibile nella libreria di immagini VCF o prevedi di estrarre un'immagine da un host. Utilizza la stessa immagine utilizzata dai cluster esistenti in modo che tutti gli host rimangano allineati.
  • Dispositivi di archiviazione: ogni nuovo host dispone di dispositivi SSD locali NVMe senza partizioni preesistenti, come richiesto per vSAN.
  • Numero minimo di nodi: un cluster richiede almeno tre nodi bare metal, ovvero il numero minimo richiesto per vSAN con un errore da tollerare (FTT=1).
  • Tipo di macchina: tutti i nodi del cluster utilizzano lo stesso tipo di macchina (z3-highmem-192-highlssd-metal per vSAN Express Storage Architecture (ESA)).
  • Zona: il nuovo cluster si trova nella stessa zona dei NEG di gestione e NSX TEP esistenti.
  • VM jumpbox: hai accesso a una VM jumpbox con l'interfaccia a riga di comando gcloud, curl e jq installate e con connettività di rete alla rete VPC (ad esempio, nella subnet bm-gcp-demo).
  • Policy per immagini attendibili e Controlli di servizio VPC: se la tua organizzazione applica la policy dell'organizzazione constraints/compute.trustedImageProjects o utilizza un perimetro di servizio dei Controlli di servizio VPC, assicurati che il tuo progetto consenta l'accesso alle immagini al progetto smve-prod-public-images (projects/999037279871). Per ulteriori informazioni, consulta Gestisci la capacità dei nodi.

  • Networking basato su VLAN: la soluzione VMware richiede che le subnet della rete VPC abbiano la proprietà Risolvi subnet mask impostata su Trasmetti solo intervallo principale con apprendimento per supportare il networking basato su VLAN. Apri un ticket di assistenza nel Centro assistenza della consoleGoogle Cloud con le seguenti informazioni:

    • Prodotto: Google Cloud VMware Engine
    • Priorità: P2
    • Categoria: connettività di rete
    • Impatto aziendale: domanda tecnica generale
    • Fornisci maggiori dettagli: Allowlist L2 network connectivity for my project, insieme all'ID progetto, al numero di progetto e alla regione e alla zona di destinazione del deployment

    Per ulteriori informazioni sul supporto del networking basato su VLAN, consulta Emulazione di livello 2: trasmissione ARP e apprendimento MAC personalizzato.

Esamina i parametri dell'ambiente di esempio

I comandi in questo documento utilizzano i seguenti parametri di esempio:

Parametro di input Valore di esempio Descrizione
ID progetto PROJECT_ID Stesso progetto Google Cloud del dominio di destinazione
Regione e zona us-east4/us-east4-b La stessa zona dei NEG a livello di zona esistenti
ID cliente demo Identificatore utilizzato nei nomi delle risorse esistenti
Dominio di destinazione mgmt-domain (o wld01) Dominio di gestione o dominio del workload VI esistente
Nome del cluster cl02 Nome del nuovo cluster vSphere
Tipo di macchina z3-highmem-192-highlssd-metal Tipo di macchina omogeneo per tutti i nodi del cluster
Conteggio nodi 3 Numero minimo di nodi per vSAN FTT=1
Rete VPC bm-demo Rete VPC esistente
Subnet (ID VLAN) bm-mgmt-demo (senza tag), bm-vmotion-demo (2), bm-vsan-demo (3), bm-nsx-demo (4) Subnet di livello 2 esistenti
NEG a livello di zona bm-mgmt-demo, bm-nsx-tep-demo NEG di gestione e NSX TEP esistenti
Immagine ESXi Famiglia astra-vcf-9-1-x, progetto smve-prod-offline-depot Stessa build dell'immagine ESXi dei cluster esistenti
Dominio e zone DNS vmware.gve / dns-zone-demo, rev-dns-zone-demo Zone gestite di forwarding e reverse Cloud DNS esistenti
SDDC Manager sddcm.vmware.gve (192.168.0.3) Appliance SDDC Manager esistente
Password root ESXi root esxi-root-password Secret di Secret Manager esistente contenente la password root di ESXi

Pianifica gli indirizzi IP e i nomi host

La tabella seguente mostra il piano di indirizzi IP di esempio per i tre nuovi host ESXi:

Host ESXi IP di gestione (nic0) vMotion (VLAN 2) vSAN (VLAN 3) NSX TEP (VLAN 4)
esxi-h7 192.168.0.161 192.168.2.21 192.168.3.21 192.168.4.21
esxi-h8 192.168.0.162 192.168.2.22 192.168.3.22 192.168.4.22
esxi-h9 192.168.0.163 192.168.2.23 192.168.3.23 192.168.4.23

Scegli il dominio di destinazione

Il dominio di destinazione selezionato determina quale vCenter Server, NSX Manager e zona di trasporto overlay gestiscono il nuovo cluster:

Parametro o risorsa Cluster nel dominio di gestione Cluster in un dominio workload VI
Variabile TARGET_DOMAIN mgmt-domain wld01
Gestione di vCenter Server vc01.vmware.gve vc02.vmware.gve
Variabile NSX_MANAGER nsx01.vmware.gve (NSX di gestione) nsx05.vmware.gve (NSX dedicato) o nsx01.vmware.gve (NSX di gestione condiviso)
Variabile TRANSPORT_ZONE overlay-tz-mgmt-nsxt Zona di trasporto overlay dell'istanza NSX del dominio del workload

Verifica la quota a livello di regione

Prima di eseguire il provisioning dei nodi bare metal o di creare un cluster, verifica che il tuo progetto disponga di una quota Compute Engine regionale e globale sufficiente. Aggiungi le risorse di tutti i cluster esistenti nella regione ai seguenti valori incrementali prima di confrontarli con la quota del progetto:

Metrica di quota Risorse richieste per nodo bare metal Risorse richieste per un cluster a 3 nodi
compute.googleapis.com/cpus_per_vm_family per Z3 192 vCPU 3 x 192 = 576 vCPU
compute.googleapis.com/local_ssd_total_storage_per_vm_family per Z3 72 TB 3 x 72 TB = 216 TB
compute.googleapis.com/hyperdisk_balanced_total_storage 128 GB 3 × 128 GB = 384 GB
compute.googleapis.com/resource_policies 0 quando aggiungi nodi a un cluster esistente 1 policy di posizionamento distribuito per cluster
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha 0 quando aggiungi nodi o cluster senza nuove appliance 1 per ogni nuovo VIP dell'appliance di gestione VCF o endpoint NSX Edge

Per l'elenco completo delle quote richieste e le istruzioni su come visualizzare o richiedere aumenti delle quote, consulta Quote e limiti.

Imposta le variabili di ambiente

Imposta le seguenti variabili di ambiente nella shell del jumpbox da utilizzare nei comandi di questa guida:

export PROJECT_ID="PROJECT_ID"
export REGION="us-east4"
export ZONE="us-east4-b"
export CUSTOMER_ID="demo"
export VPC_NETWORK="bm-${CUSTOMER_ID}"
export DOMAIN="vmware.gve"
export DNS_ZONE="dns-zone-${CUSTOMER_ID}"
export REV_DNS_ZONE="rev-dns-zone-${CUSTOMER_ID}"
export MGMT_SUBNET="bm-mgmt-${CUSTOMER_ID}"
export VMOTION_SUBNET="bm-vmotion-${CUSTOMER_ID}"
export VSAN_SUBNET="bm-vsan-${CUSTOMER_ID}"
export TEP_SUBNET="bm-nsx-${CUSTOMER_ID}"
export MGMT_NEG="bm-mgmt-${CUSTOMER_ID}"
export TEP_NEG="bm-nsx-tep-${CUSTOMER_ID}"
export CLUSTER_NAME="cl02"
export PLACEMENT_POLICY="bm-${CLUSTER_NAME}"
export NETWORK_POOL_NAME="${CLUSTER_NAME}-np01"
export TEP_POOL_NAME="${CLUSTER_NAME}-tep-pool"
export VDS_NAME="${CLUSTER_NAME}-vds-01"
export MACHINE_TYPE="z3-highmem-192-highlssd-metal"
export ESXI_IMAGE_FAMILY="astra-vcf-9-1-x"
export ESXI_IMAGE_PROJECT="smve-prod-offline-depot"
export SDDC_MANAGER="sddcm.vmware.gve"            # 192.168.0.3
export VCF_USER="admin@local"
export VCF_PASSWORD="VCF_ADMIN_PASSWORD"
export ESXI_PASSWORD_SECRET="esxi-root-password"  # Secret Manager secret holding the ESXi root password
export MTU=8896                                   # VPC MTU

# Target domain parameters
export TARGET_DOMAIN="mgmt-domain"                # Or wld01
export NSX_MANAGER="nsx01.vmware.gve"             # Or nsx05.vmware.gve for wld01 with a dedicated NSX instance
export TRANSPORT_ZONE="overlay-tz-mgmt-nsxt"      # Overlay transport zone of the target NSX instance

# Ordered host list: name mgmt_ip vmotion_ip vsan_ip tep_ip
CLUSTER_HOSTS=(
  "esxi-h7 192.168.0.161 192.168.2.21 192.168.3.21 192.168.4.21"
  "esxi-h8 192.168.0.162 192.168.2.22 192.168.3.22 192.168.4.22"
  "esxi-h9 192.168.0.163 192.168.2.23 192.168.3.23 192.168.4.23"
)

# TEP pool range matching the new hosts' Compute Engine TEP NIC IPs
export TEP_CIDR="192.168.4.0/24"
export TEP_GATEWAY="192.168.4.1"
export TEP_START="192.168.4.21"
export TEP_END="192.168.4.23"

Prima di eseguire i comandi, sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto Google Cloud di destinazione.
  • VCF_ADMIN_PASSWORD: la password dell'amministratore di SDDC Manager.

Verifica che nessuno degli indirizzi IP pianificati sia già utilizzato da regole di forwarding o istanze esistenti:

gcloud compute forwarding-rules list --project="${PROJECT_ID}" --regions="${REGION}" \
    --format="table(name,IPAddress,subnetwork.basename())"
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --format="table(name,networkInterfaces[].networkIP.list())"

Crea record DNS

Quando hai eseguito il deployment del dominio di gestione, hai creato le subnet di livello 2, la policy di forwarding in entrata di Cloud DNS e le zone gestite di forwarding e di ricerca inversa. Poiché l'aggiunta di un cluster non comporta il deployment di nuove appliance, devi solo creare record di inoltro (A) e inversi (PTR) per i nuovi host ESXi:

add_dns() {
  local name=$1 ip=$2
  gcloud dns record-sets create "${name}.${DOMAIN}." \
      --rrdatas="${ip}" --type=A --ttl=300 \
      --zone="${DNS_ZONE}" --project="${PROJECT_ID}"
  local rev
  rev=$(echo "${ip}" | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}')
  gcloud dns record-sets create "${rev}" \
      --rrdatas="${name}.${DOMAIN}." --type=PTR --ttl=300 \
      --zone="${REV_DNS_ZONE}" --project="${PROJECT_ID}"
}

for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST MGMT_IP _ <<< "${entry}"
  add_dns "${HOST}" "${MGMT_IP}"
done

# Verify DNS records
gcloud dns record-sets list --zone="${DNS_ZONE}" --project="${PROJECT_ID}" \
    --filter="name~'esxi-h[7-9]'"

Crea istanze bare metal

Crea una policy di posizionamento dedicato per il nuovo cluster. Poi crei ogni host ESXi bare metal con un'interfaccia di gestione principale (nic0) e NIC dinamiche con tag VLAN per vMotion (VLAN 2), vSAN (VLAN 3) e NSX TEP (VLAN 4).

Crea una policy di posizionamento

Crea la policy di posizionamento del gruppo:

gcloud compute resource-policies create group-placement "${PLACEMENT_POLICY}" \
    --region="${REGION}" \
    --availability-domain-count=6 \
    --collocation=COLLOCATED \
    --project="${PROJECT_ID}"

Crea dischi di avvio e istanze ESXi bare metal

Crea il disco di avvio Google Cloud Hyperdisk bilanciato e l'istanza ESXi bare metal per ogni host nel cluster:

i=0
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST MGMT_IP VMOTION_IP VSAN_IP TEP_IP <<< "${entry}"
  AD=$(( (i % 6) + 1 )); i=$((i + 1))

  # Create boot disk
  gcloud compute disks create "${HOST}" \
      --image-project="${ESXI_IMAGE_PROJECT}" \
      --image-family="${ESXI_IMAGE_FAMILY}" \
      --type=hyperdisk-balanced --interface=NVME --size=128GB \
      --guest-os-features=IDPF \
      --zone="${ZONE}" --project="${PROJECT_ID}"

  # Create bare-metal ESXi host
  gcloud compute instances create "${HOST}" \
      --zone="${ZONE}" \
      --machine-type="${MACHINE_TYPE}" \
      --can-ip-forward \
      --resource-policies="${PLACEMENT_POLICY}" \
      --availability-domain="${AD}" \
      --hostname="${HOST}.${DOMAIN}" \
      --disk="name=${HOST},boot=yes,auto-delete=yes" \
      --labels=gcve-node=true \
      --tags=mm-gcve-node \
      --deletion-protection \
      --maintenance-policy=TERMINATE \
      --restart-on-failure \
      --network-performance-configs=total-egress-bandwidth-tier=TIER_1 \
      --project="${PROJECT_ID}" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${MGMT_SUBNET},no-address,private-network-ip=${MGMT_IP}" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${VMOTION_SUBNET},no-address,private-network-ip=${VMOTION_IP},vlan=2" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${VSAN_SUBNET},no-address,private-network-ip=${VSAN_IP},vlan=3" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${TEP_SUBNET},no-address,private-network-ip=${TEP_IP},vlan=4"
done

# Verify instance creation and network interfaces
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --filter="name~'esxi-h[7-9]'" \
    --format="table(name,status,networkInterfaces[].vlan.list(),networkInterfaces[].networkIP.list())"

Aggiorna l'appartenenza al NEG

Tutti i nodi di una zona devono appartenere allo stesso NEG di zona della subnet, in modo che le appliance di rete VCF possano instradare il traffico tra i nodi del cluster. Aggiungi i nuovi host al NEG di gestione esistente e al NEG NSX TEP:

# List the NEGs in the zone (management and NSX TEP)
gcloud compute network-endpoint-groups list --zones="${ZONE}" --project="${PROJECT_ID}" \
    --format="table(name,subnetwork.basename(),networkEndpointType,size)"

ALL_NEGS=("${MGMT_NEG}" "${TEP_NEG}")
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  for NEG in "${ALL_NEGS[@]}"; do
    gcloud compute network-endpoint-groups update "${NEG}" \
        --zone="${ZONE}" \
        --add-endpoint="instance=${HOST}" \
        --project="${PROJECT_ID}"
  done
done

# Verify NEG endpoints
for NEG in "${ALL_NEGS[@]}"; do
  gcloud compute network-endpoint-groups list-network-endpoints "${NEG}" \
      --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkEndpoint.instance,networkEndpoint.ipAddress)"
done

Reimposta la password root di ESXi

Per la sicurezza e il provisioning degli host, reimposta la password root di ogni nuovo host sulla password ESXi root archiviata in Secret Manager. Utilizzerai lo stesso secret per eseguire il provisioning degli host in un passaggio successivo. Assicurati che la password soddisfi i requisiti di complessità di VCF (almeno 15 caratteri, tra cui lettere maiuscole, lettere minuscole, cifre e caratteri speciali). Se hai modificato o ruotato le password di ESXi root o VCF dopo il deployment iniziale, aggiorna il secret corrispondente in Secret Manager prima di eseguire questi comandi.

Per reimpostare la password root su ogni nuovo host, esegui i seguenti comandi dalla VM jumpbox e inserisci la password ESXi root iniziale quando richiesto:

# 1. Read the ESXi root password from Secret Manager
ESXI_ROOT_PASSWORD=$(gcloud secrets versions access latest \
    --secret="${ESXI_PASSWORD_SECRET}" --project="${PROJECT_ID}")

# 2. Reset the root password on each new host
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  ssh -o StrictHostKeyChecking=no "root@${HOST}.${DOMAIN}" \
      "esxcli system account set -i root -p '${ESXI_ROOT_PASSWORD}' -c '${ESXI_ROOT_PASSWORD}'"
done

# 3. Optional: Verify that the FQDN is set and vmk0 is configured as STATIC
ssh "root@esxi-h7.${DOMAIN}" \
    'esxcli system hostname get; esxcli network ip interface ipv4 get -i vmk0'

Crea un pool di rete dedicato

VCF alloca gli indirizzi IP vMotion e vSAN dal pool di rete che selezioni durante il provisioning degli host. Poiché i pool di rete dei cluster esistenti contengono solo i propri indirizzi IP host, crea un pool di rete dedicato i cui intervalli IP contengono gli indirizzi IP vMotion e vSAN esatti che hai preassegnato alle NIC dinamiche di Compute Engine dei nuovi host. L'utilizzo di un pool di rete dedicato mantiene l'allocazione degli IP VCF all'interno dell'insieme di indirizzi IP di Compute Engine preassegnati, quindi devi solo allineare l'ordine host-IP in un secondo momento se si verifica una mancata corrispondenza.

Puoi creare il pool di rete utilizzando VCF Operations o l'API SDDC Manager:

Operazioni VCF

In VCF Operations, vai a Gestione pool di rete, fai clic su Crea pool di rete e crea il pool di rete cl02-np01 con le impostazioni della rete vMotion (VLAN 2, 192.168.2.21–192.168.2.23) e vSAN (VLAN 3, 192.168.3.21–192.168.3.23) e una MTU di 8896 byte.

API SDDC Manager

Esegui questi comandi per creare il pool di rete e recuperarne l'ID:

TOKEN=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/tokens" \
    -H "Content-Type: application/json" \
    -d "{\"username\":\"${VCF_USER}\",\"password\":\"${VCF_PASSWORD}\"}" | jq -r '.accessToken')

curl -s -X POST "https://${SDDC_MANAGER}/v1/network-pools" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "{
      \"name\": \"${NETWORK_POOL_NAME}\",
      \"networks\": [
        { \"type\": \"VMOTION\", \"vlanId\": 2, \"mtu\": ${MTU},
          \"subnet\": \"192.168.2.0\", \"mask\": \"255.255.255.0\", \"gateway\": \"192.168.2.1\",
          \"ipPools\": [ { \"start\": \"192.168.2.21\", \"end\": \"192.168.2.23\" } ] },
        { \"type\": \"VSAN\", \"vlanId\": 3, \"mtu\": ${MTU},
          \"subnet\": \"192.168.3.0\", \"mask\": \"255.255.255.0\", \"gateway\": \"192.168.3.1\",
          \"ipPools\": [ { \"start\": \"192.168.3.21\", \"end\": \"192.168.3.23\" } ] }
      ]
    }"

# Retrieve the network pool ID for host commissioning
POOL_ID=$(curl -s "https://${SDDC_MANAGER}/v1/network-pools" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg n "${NETWORK_POOL_NAME}" '.elements[] | select(.name==$n) | .id')
echo "${POOL_ID}"

Commissiona gli host

Esegui il provisioning dei nuovi host ESXi nell'inventario di SDDC Manager utilizzando VCF Operations o l'API SDDC Manager:

Operazioni VCF

  1. In VCF Operations, vai a Inventario > Host > Commissiona host.
  2. Seleziona il pool di rete cl02-np01 e il tipo di spazio di archiviazione vSAN ESA.
  3. Inserisci gli FQDN dell'host (esxi-h7.vmware.gve, esxi-h8.vmware.gve e esxi-h9.vmware.gve) e le credenziali di root.
  4. Accetta le impronte SSL, convalida gli host e fai clic su Commissiona.

API SDDC Manager

Esegui i seguenti comandi per convalidare e commissionare gli host, quindi esegui il polling dell'ID attività finché non restituisce Successful:

ESXI_PASSWORD=$(gcloud secrets versions access latest \
    --secret="${ESXI_PASSWORD_SECRET}" --project="${PROJECT_ID}")

HOST_FQDNS=$(for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"; echo "${HOST}.${DOMAIN}"
done | jq -R . | jq -s .)

HOSTS_JSON=$(jq -n --argjson f "${HOST_FQDNS}" --arg p "${ESXI_PASSWORD}" \
    --arg np "${POOL_ID}" --arg npn "${NETWORK_POOL_NAME}" \
    '$f | map({fqdn: ., username: "root", password: $p, storageType: "VSAN_ESA",
               networkPoolId: $np, networkPoolName: $npn})')

# 1. Validate hosts
curl -s -X POST "https://${SDDC_MANAGER}/v1/hosts/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" -d "${HOSTS_JSON}"

# 2. Commission hosts
TASK_ID=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/hosts" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${HOSTS_JSON}" | jq -r '.id')

# 3. Poll task status until Successful
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

Se un'impronta SSL dell'host mostra un nome di certificato interno (non FQDN), il dominio di ricerca DNS non è configurato sull'host. Sull'host ESXi interessato, esegui il comando esxcli network ip dns search add -d vmware.gve, esegui di nuovo lo script /var/lib/vmware/osdata/init.sh, quindi esegui il comando /sbin/generate-certificates e riavvia i servizi rhttpproxy e hostd (/etc/init.d/rhttpproxy restart && /etc/init.d/hostd restart).

Controlla l'allineamento degli IP prima del deployment

Mantieni attive tutte le convalide di connettività di rete, vSAN e vMotion in SDDC Manager. Questi controlli di convalida vengono superati solo quando gli indirizzi IP vmk1 (vMotion) e vmk2 (vSAN) assegnati da VCF a ciascun host corrispondono agli indirizzi IP delle NIC dinamiche di Compute Engine di quell'host. Se si verifica una mancata corrispondenza perché SDDC Manager assegna gli indirizzi IP del pool in un ordine host diverso, l'attività di creazione del cluster viene messa in pausa durante il controllo della connettività. Poi, allinea le NIC dinamiche in un passaggio successivo prima di riprovare l'attività.

  1. Verifica che l'intervallo del pool di rete corrisponda agli indirizzi IP delle NIC vMotion e vSAN di Compute Engine: verifica che il pool di rete contenga solo gli indirizzi IP preassegnati alle NIC dinamiche dei nuovi host (192.168.2.21-192.168.2.23 e 192.168.3.21-192.168.3.23 in questo esempio):

    # Inspect network pool definition
curl -s "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}" \
    -H "Authorization: Bearer ${TOKEN}" | jq '.networks[] | {type, vlanId, mtu, ipPools}'

# Inspect Compute Engine dynamic NIC IPs per new host (VLAN 2 = vMotion, 3 = vSAN, 4 = TEP)
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  echo "== ${HOST}"
  gcloud compute instances describe "${HOST}" --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkInterfaces[].name,networkInterfaces[].vlan,networkInterfaces[].networkIP)"
done

  2. Assegna gli indirizzi IP in ordine crescente di nome host: preassegna gli indirizzi IP di Compute Engine in ordine crescente di nome host (esxi-h7 → .21, esxi-h8 → .22, esxi-h9 → .23) in modo che l'insieme di indirizzi IP sia identico su entrambi i lati.

  3. Verifica che SDDC Manager non ignori le convalide: sull'appliance SDDC Manager (come root), verifica che il file application.properties non contenga proprietà validation.disable.*:

    # Must return no output. If any validation.disable.* line is present, remove it
# and run: systemctl restart domainmanager
grep -n 'validation.disable' /etc/vmware/vcf/domainmanager/application.properties

    Se aggiungi il cluster utilizzando l'API SDDC Manager, non impostare la proprietà "skipValidations": true nel corpo della richiesta.

  4. Dimensiona il pool TEP NSX in modo che corrisponda agli indirizzi IP delle NIC TEP di Compute Engine: configura un nuovo pool di indirizzi IP TEP NSX statici per il cluster con l'intervallo 192.168.4.21-192.168.4.23 (dalla variabile TEP_START alla variabile TEP_END), in modo che corrisponda agli indirizzi IP delle NIC dinamiche della VLAN 4 dei nuovi host, e imposta il gateway su 192.168.4.1.

Aggiungi il cluster

Puoi aggiungere il cluster al dominio di destinazione utilizzando VCF Operations o l'API SDDC Manager:

Operazioni VCF

Accedi a VCF Operations, vai a Inventario, espandi Istanze VCF, seleziona il dominio di destinazione (mgmt-domain o wld01) e fai clic su Aggiungi cluster (oppure nell'interfaccia utente di SDDC Manager, vai a Workload Domains > dominio di destinazione > Azioni > Aggiungi cluster). Completa la procedura guidata utilizzando le seguenti impostazioni:

Pagina della procedura guidata Campo Valore
Archiviazione Tipo vSAN, Abilita vSAN ESA, vSAN HCI, crittografia dei dati in transito disattivata
Cluster Nome del cluster cl02
Immagine Immagine vLCM Seleziona l'immagine utilizzata dai cluster esistenti o seleziona Estrai un'immagine da un host in questa istanza VCF (utilizzando esxi-h7)
Hosting Hosting esxi-h7, esxi-h8, esxi-h9 (commissionati come vSAN ESA con il pool di rete cl02-np01)
vSphere Distributed Switch Profilo Predefinito (VDS singolo) o personalizzato: 1 uplink (uplink1 → vmnic0), MTU 8896, tipi di traffico ESX Management, VM Management, vMotion, vSAN e NSX
Modalità switch NSX Modalità operativa dello switch virtuale Deseleziona Applica la modalità di switch virtuale predefinita configurata in NSX Manager e imposta Modalità operativa su Standard. Gli host della soluzione VMware non supportano la modalità predefinita (Enhanced Datapath Standard).
Overlay host NSX VLAN TEP e assegnazione IP VLAN 4 (corrispondente alla configurazione NSX esistente), Pool di IP statici (non utilizzare DHCP): nuovo pool cl02-tep-pool, CIDR 192.168.4.0/24, intervallo 192.168.4.21–192.168.4.23, gateway 192.168.4.1
Rivedi Invia Fai clic su Fine. Vai a Gestione del parco risorse > Attività per monitorare l'attività e registrare l'ID attività (TASK_ID).

API SDDC Manager

Recupera l'ID dominio di destinazione, l'ID personalità dell'immagine vLCM e gli ID host commissionati, quindi convalida e invia la specifica per la creazione del cluster:

# 1. Retrieve target domain ID, vLCM image personality ID, and host specs
DOMAIN_ID=$(curl -s "https://${SDDC_MANAGER}/v1/domains" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg d "${TARGET_DOMAIN}" '.elements[] | select(.name==$d) | .id')

curl -s "https://${SDDC_MANAGER}/v1/personalities" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r '.elements[] | [.personalityId, .personalityName] | @tsv'
IMAGE_ID="PERSONALITY_ID"   # Select the personalityId of the existing clusters' image

HOST_SPECS=$(curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" \
    | jq --argjson f "${HOST_FQDNS}" --arg vds "${VDS_NAME}" '
        [.elements[] | select(.fqdn as $x | $f | index($x))
         | {id, hostNetworkSpec: {vmNics: [{id: "vmnic0", uplink: "uplink1", vdsName: $vds}]}}]')
echo "${HOST_SPECS}" | jq 'length'   # Must equal 3

# 2. Construct the cluster specification (without skipValidations)
CLUSTER_SPEC=$(jq -n \
    --arg domain "${DOMAIN_ID}" --arg name "${CLUSTER_NAME}" --arg img "${IMAGE_ID}" \
    --argjson hosts "${HOST_SPECS}" --arg vds "${VDS_NAME}" --argjson mtu "${MTU}" \
    --arg tz "${TRANSPORT_ZONE}" --arg pool "${TEP_POOL_NAME}" \
    --arg cidr "${TEP_CIDR}" --arg gw "${TEP_GATEWAY}" --arg s "${TEP_START}" --arg e "${TEP_END}" '
{
  domainId: $domain,
  computeSpec: { clusterSpecs: [{
    name: $name,
    clusterImageId: $img,
    hostSpecs: $hosts,
    datastoreSpec: { vsanDatastoreSpec: { datastoreName: ($name + "-vsan"), esaConfig: { enabled: true } } },
    networkSpec: {
      vdsSpecs: [{
        name: $vds, mtu: $mtu,
        portGroupSpecs: [
          { name: ($vds + "-pg-mgmt"),    transportType: "MANAGEMENT", activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" },
          { name: ($vds + "-pg-vmotion"), transportType: "VMOTION",    activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" },
          { name: ($vds + "-pg-vsan"),    transportType: "VSAN",       activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" }
        ],
        nsxtSwitchConfig: {
          transportZones: [ { name: $tz, transportType: "OVERLAY" } ],
          hostSwitchOperationalMode: "STANDARD"
        }
      }],
      nsxClusterSpec: { nsxTClusterSpec: {
        uplinkProfiles: [{ name: ($name + "-uplink-profile"),
          teamings: [ { policy: "LOADBALANCE_SRCID", activeUplinks: ["uplink-1"] } ],
          transportVlan: 4 }],
        ipAddressPoolsSpec: [{ name: $pool,
          subnets: [{ cidr: $cidr, gateway: $gw, ipAddressPoolRanges: [ { start: $s, end: $e } ] }] }]
      }},
      networkProfiles: [{
        name: ($name + "-network-profile"), isDefault: true,
        nsxtHostSwitchConfigs: [{
          vdsName: $vds, uplinkProfileName: ($name + "-uplink-profile"), ipAddressPoolName: $pool,
          vdsUplinkToNsxUplink: [ { vdsUplinkName: "uplink1", nsxUplinkName: "uplink-1" } ]
        }]
      }]
    }
  }]}
}')

# 3. Validate the cluster specification
curl -s -X POST "https://${SDDC_MANAGER}/v1/clusters/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${CLUSTER_SPEC}" | jq '{executionStatus, resultStatus}'

# 4. Create the cluster and poll the task
TASK_ID=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/clusters" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${CLUSTER_SPEC}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

Prima di eseguire i comandi, sostituisci PERSONALITY_ID con il valore personalityId dell'immagine vLCM del cluster.

Se VCF assegna a un host un indirizzo IP vMotion o vSAN diverso dalla sua NIC dinamica di Compute Engine, l'attività si interrompe al passaggio di verifica della connettività vSAN e vMotion. Lascia l'attività nello stato di errore, completa i passaggi descritti in Allinea le NIC dinamiche vMotion e vSAN, quindi riprova l'attività. Non annullare l'attività e non disattivare il controllo di convalida.

Allinea le NIC dinamiche vMotion e vSAN

Applica i passaggi descritti in questa sezione se l'attività di creazione del cluster si interrompe al passaggio di verifica della connettività vSAN e vMotion. Se l'attività supera questo passaggio, esegui solo i passaggi 1 e 2 per confermare l'allineamento degli IP, quindi procedi con Allinea le NIC dinamiche NSX TEP.

  1. Leggi gli indirizzi IP allocati da VCF: esegui una query sull'endpoint SDDC Manager /v1/hosts (o sul database SDDC Manager platform) per esaminare gli indirizzi IP vMotion (vmk1) e vSAN (vmk2) allocati da VCF a ciascun host:

    curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" | jq -r '
  ["FQDN","STATUS","CLUSTER","MGMT_IP","VMOTION_IP","VSAN_IP"],
  (.elements | sort_by(.fqdn)[] | [
     .fqdn, (.status // "-"), (.cluster.name // .cluster.id // "-"),
     (([.ipAddresses[]? | select(.type=="MANAGEMENT") | .ipAddress] | first) // "-"),
     (([.ipAddresses[]? | select(.type=="VMOTION")    | .ipAddress] | first) // "-"),
     (([.ipAddresses[]? | select(.type=="VSAN")       | .ipAddress] | first) // "-")
  ]) | @tsv' | column -t

# Alternative (run on the SDDC Manager appliance shell):
# psql -h localhost -U postgres -d platform \
#   -c "select hostname, vmotion_ip_address, vsan_ip_address from host;"

  2. Confronta con le NIC dinamiche di Compute Engine: elenca gli indirizzi IP delle NIC dinamiche attuali su ogni nuovo host:

    for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  echo "== ${HOST}"
  gcloud compute instances describe "${HOST}" --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkInterfaces[].name,networkInterfaces[].vlan,networkInterfaces[].networkIP)"
done

  3. Elimina prima tutte le NIC dinamiche non corrispondenti, quindi aggiungile di nuovo: elimina ogni NIC dinamica non corrispondente (l'interfaccia nic0.2 per vMotion e l'interfaccia nic0.3 per vSAN) in tutti gli host non corrispondenti prima di aggiungere nuovamente qualsiasi interfaccia; in caso contrario, gli indirizzi IP scambiati tra due host non vanno a buon fine con un errore IP_IN_USE:

    # Example: VCF assigned esxi-h7 vMotion 192.168.2.22 and vSAN 192.168.3.22
HOST="esxi-h7"
VCF_VMOTION_IP="192.168.2.22"
VCF_VSAN_IP="192.168.3.22"

# 3a. Delete mismatched NICs (run on all mismatched hosts before running 3b)
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.2 \
    --zone="${ZONE}" --project="${PROJECT_ID}" --quiet
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.3 \
    --zone="${ZONE}" --project="${PROJECT_ID}" --quiet

# 3b. Re-add the dynamic NICs with the VCF-allocated IP addresses
# vMotion (VLAN 2)
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=2 \
    --network="${VPC_NETWORK}" --subnetwork="${VMOTION_SUBNET}" \
    --private-network-ip="${VCF_VMOTION_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

# vSAN (VLAN 3)
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=3 \
    --network="${VPC_NETWORK}" --subnetwork="${VSAN_SUBNET}" \
    --private-network-ip="${VCF_VSAN_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

  4. Riprova l'attività del cluster non riuscita: in VCF Operations, vai a Gestione del parco risorse > Attività per riprovare l'attività o esegui il seguente comando dell'API SDDC Manager:

    curl -s -X PATCH "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d '{"status": "RETRY"}'

    L'attività ritentata esegue nuovamente il controllo della connettività per vSAN e vMotion e ha esito positivo dopo che tutte le NIC dinamiche di Compute Engine corrispondono agli indirizzi IP assegnati da VCF.

Allinea le NIC dinamiche NSX TEP

Dopo che NSX ha configurato gli host come nodi di trasporto, verifica e allinea le NIC dinamiche TEP NSX (vmk10) della VLAN 4 sui nuovi host.

  1. Recupera gli indirizzi IP TEP allocati da NSX: esegui una query su NSX Manager del dominio di destinazione (NSX_MANAGER) o esegui il comando esxcli network ip interface ipv4 get -i vmk10 su ogni host ESXi:

    NSX_PW="NSX_ADMIN_PASSWORD"

# Map transport node ID to hostname
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/api/v1/transport-nodes" \
    | jq -r '.results[] | [.id, .display_name] | @tsv'

# Map transport node ID to TEP device and IP address
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/api/v1/transport-nodes/state" \
    | jq -r '.results[] | [.transport_node_id, .state,
        ([.host_switch_states[]?.endpoints[]? | .device_name + "=" + .ip] | join(","))] | @tsv'

    Prima di eseguire i comandi, sostituisci NSX_ADMIN_PASSWORD con la password di NSX Manager admin (disponibile dall'endpoint SDDC Manager /v1/credentials o dalla gestione delle password di VCF Operations).

  2. Confronta con la NIC TEP di Compute Engine (VLAN 4): confronta gli indirizzi IP vmk10 assegnati da NSX con gli indirizzi IP della NIC dinamica della VLAN 4 sui nuovi host (esxi-h7, esxi-h8 e esxi-h9). Solo i nuovi host sono inclusi nell'ambito; non modificare le NIC TEP degli host in altri cluster.

  3. Ricrea le NIC TEP non corrispondenti: per tutti i nuovi host non corrispondenti, scollega prima ogni host dal NEG TEP ed elimina l'interfaccia nic0.4 in tutti gli host non corrispondenti. Poi aggiungi di nuovo l'interfaccia nic0.4 e ricollega gli host al NEG TEP:

    # Example: Compute Engine has 192.168.4.21 on esxi-h7, but NSX assigned 192.168.4.23
HOST="esxi-h7"
CURRENT_TEP_IP="192.168.4.21"
NSX_TEP_IP="192.168.4.23"

# 3a. Detach the host from the TEP NEG
gcloud compute network-endpoint-groups update "${TEP_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" \
    --remove-endpoint="instance=${HOST},ip=${CURRENT_TEP_IP}"

# 3b. Delete the mismatched TEP NIC (nic0.4) on all mismatched hosts first
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.4 \
    --zone="${ZONE}" --project="${PROJECT_ID}" --quiet

# 3c. Re-add nic0.4 with the NSX-allocated IP address
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=4 \
    --network="${VPC_NETWORK}" --subnetwork="${TEP_SUBNET}" \
    --private-network-ip="${NSX_TEP_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

# 3d. Re-attach the host to the TEP NEG
gcloud compute network-endpoint-groups update "${TEP_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" \
    --add-endpoint="instance=${HOST}"

Verifica il deployment del cluster

Al termine dell'attività di creazione del cluster e dopo aver allineato tutte le NIC dinamiche, verifica quanto segue:

  • vCenter Server (vc01 o vc02): il cluster cl02 e tutti e tre gli host sono connessi e integri, senza allarmi di rete.
  • vSAN: per il cluster cl02, vai a Monitor > vSAN > Skyline Health e verifica che tutti i controlli di integrità siano stati superati e che il datastore vSAN mostri la capacità combinata di tutti e tre gli host.
  • NSX Manager: vai a System > Fabric > Hosts e verifica che ogni nuovo host mostri Success e Up e che tutti i tunnel di overlay siano attivi.
  • VCF Operations: lo stato del cluster è Attivo nel dominio di destinazione e l'elenco delle attività non mostra attività non riuscite.
  • Cluster esistenti: tutti gli altri cluster del dominio rimangono integri.
  • (Facoltativo) Esegui la migrazione di una VM di test utilizzando vMotion tra un cluster esistente e il cluster cl02 e tra gli host all'interno del cluster cl02.

Da una shell host ESXi (ad esempio, esxi-h7), verifica la connettività dei frame jumbo (MTU 8896 meno l'intestazione IP/ICMP di 28 byte = 8868 byte) tra le interfacce vMotion, vSAN e NSX TEP:

esxcli network ip interface ipv4 get                        # Verify vmk0, vmk1, vmk2, and vmk10 IPs
vmkping -S vmotion -I vmk1 -d -s 8868 192.168.2.22          # vMotion
vmkping -I vmk2 -d -s 8868 192.168.3.22                     # vSAN
vmkping ++netstack=vxlan -I vmk10 -d -s 8868 192.168.4.22   # NSX TEP

(Facoltativo) Configura gli errori vSAN da tollerare

Per vSAN ESA, VCF crea e assegna una policy di archiviazione del datastore predefinita in base al tipo di cluster e al numero di host. Per configurare l'impostazione FTT in modo esplicito, scegli una policy supportata dal numero di host del cluster:

Errori da tollerare Schema di posizionamento dei dati Numero minimo di host
FTT=1 RAID-1 (mirroring) o RAID-5 (codifica di cancellazione) 3 (consigliamo 4 o più per la ricostruzione dopo un errore dell'host o durante la manutenzione)
FTT=2 RAID-1 (mirroring) 5
FTT=2 RAID-6 (erasure coding) 6

Per impostare la policy di archiviazione predefinita nel client vSphere del server vCenter del dominio di destinazione (vc01 o vc02), segui questi passaggi:

  1. Disattiva la gestione automatica delle policy per il cluster vSAN ESA in modo che vSAN non sovrascriva la policy predefinita personalizzata.
  2. Vai a Policies and Profiles > VM Storage Policies > Create, attiva le regole di archiviazione vSAN e, nella sezione Availability, seleziona Failures to tolerate (ad esempio, 1 failure - RAID-1 (Mirroring) per 3 o 4 host o 2 failures - RAID-6 (Erasure Coding) per 6 o più host).
  3. Imposta la nuova policy come predefinita per il datastore: seleziona il datastore vSAN cl02, vai a Configura > Generale > Policy di archiviazione predefinita > Modifica e seleziona la nuova policy.
  4. Applica la policy alle VM esistenti (Policy VM > Modifica policy di archiviazione VM). Vai a Monitora > vSAN > Oggetti virtuali per il cluster cl02 per verificare la conformità.

Risolvi i problemi relativi alla creazione dei cluster

La tabella seguente elenca i problemi, le cause e le soluzioni comuni per l'aggiunta di un cluster vSphere a un dominio:

Problema Causa Risoluzione
La convalida della connettività vSAN e vMotion non va a buon fine; i nuovi host segnalano uno stato non integro Quando crei o espandi un cluster, SDDC Manager assegna gli indirizzi IP vmk1 e vmk2 dal pool di rete senza preservare l'ordine degli host. Mantieni attive le convalide. Crea un pool di rete dedicato corrispondente agli indirizzi IP delle NIC di Compute Engine, verifica l'allineamento pre-deployment e, se l'attività si interrompe durante il controllo della connettività, allinea le NIC dinamiche e riprova.
Lo stato dell'host NSX è Degraded o i tunnel non sono attivi dopo l'aggiunta del cluster NSX Manager assegna gli indirizzi IP TEP (vmk10) dal pool di IP in modo casuale, pertanto potrebbero non corrispondere alla NIC TEP di Compute Engine; le subnet NIC dinamiche non supportano DHCP. Utilizza un pool di IP TEP dedicato corrispondente agli indirizzi IP TEP di Compute Engine e allinea le NIC dinamiche TEP dopo la preparazione dell'host NSX.
NSX_VDL2 l'agente o l'host segnala Degraded mentre BFD è attivo L'indirizzo IP del gateway non è presente nel pool di IP NSX TEP. Configura il gateway della subnet (192.168.4.1) nel pool di IP TEP.
Errore IP_IN_USE durante l'aggiunta di una NIC dinamica Due host hanno scambiato gli indirizzi IP o un indirizzo IP pianificato si sovrappone a un altro cluster. Elimina tutte le NIC dinamiche non corrispondenti su tutti gli host prima di aggiungere nuovamente un'interfaccia e verifica che il tuo piano IP non si sovrapponga ai cluster esistenti.
La modalità switch virtuale NSX non è supportata In VCF 9.x, la modalità predefinita del virtual switch NSX è Enhanced Datapath Standard, che non è supportata dagli host della soluzione VMware. Deseleziona Applica la modalità di switch virtuale predefinita configurata in NSX Manager e imposta Modalità operativa su Standard (o "hostSwitchOperationalMode": "STANDARD" nella specifica dell'API). Per saperne di più, consulta Modalità di switch virtuale NSX.
Gli host non possono inviare un ping al gateway della subnet (.1) Google Cloud non risponde alle richieste echo ICMP sugli indirizzi IP del gateway della subnet. Comportamento previsto; ignora gli avvisi di ping del gateway.
Configurazione della sincronizzazione dell'orario (NTP) Gli host bare metal utilizzano il server di metadati di Compute Engine per la sincronizzazione dell'ora. Utilizza l'indirizzo IP del server dei metadati (169.254.169.254) direttamente come server NTP.
L'identificazione o il certificato dell'host mostra un nome interno Il dominio di ricerca DNS non è impostato sull'host o il nome host ha un punto finale. Esegui il comando esxcli network ip dns search add -d vmware.gve, esegui nuovamente lo script /var/lib/vmware/osdata/init.sh, quindi esegui il comando /sbin/generate-certificates e riavvia i servizi rhttpproxy e hostd.
Commissioning dell'host non riuscito L'adattatore VMkernel vmk0 utilizza ancora DHCP perché il servizio di avvio non lo ha convertito. Esegui il comando esxcli network ip interface ipv4 get -i vmk0. Se il tipo è DHCP, impostalo manualmente su statico (ad esempio, su esxi-h7: esxcli network ip interface ipv4 set -i vmk0 -t static -I 192.168.0.161 -N 255.255.255.0 -g 192.168.0.1).
Errori di replica vSAN, timeout di vMotion o frammentazione dell'overlay NSX VCF imposta per impostazione predefinita l'MTU di VDS, adattatori VMkernel e profili NSX su 9000 byte e la rete VPC ignora i frame di dimensioni superiori a 8896 byte. Configura un'MTU di 8896 byte sul VDS, sul pool di rete (vMotion e vSAN) e sul profilo di uplink NSX. Per saperne di più, consulta Mancata corrispondenza della MTU VDS.
La procedura guidata richiede un ID VLAN per il gruppo di porte overlay Il profilo VDS predefinito richiede l'ID VLAN dell'overlay host NSX. Inserisci l'ID VLAN TEP della configurazione NSX esistente (4 in questa guida).
Non esiste un gruppo di porte per le VM del workload nel nuovo cluster Il profilo VDS predefinito crea solo gruppi di porte dell'infrastruttura. Crea un gruppo di porte distribuite per le VM dei workload dopo aver creato il cluster o utilizza una configurazione di switch personalizzata.
Impossibile aggiungere host con l'immagine vLCM selezionata L'immagine vLCM del cluster è diversa dalla build ESXi installata sugli host. Utilizza la stessa famiglia di immagini ESXi utilizzata dai cluster esistenti o estrai l'immagine da uno dei nuovi host.

Passaggi successivi