O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Adicionar um cluster do vSphere a um domínio

Neste documento, descrevemos como adicionar um cluster do vSphere a um domínio atual do VMware Cloud Foundation (VCF) 9.1 na solução VMware no Google Cloud usando instâncias bare metal do Compute Engine. Adicione um cluster quando precisar escalonar a capacidade de computação e armazenamento do vSAN além de um único cluster, isolar cargas de trabalho ou aplicar imagens separadas do vSphere Lifecycle Manager (vLCM) ou políticas de armazenamento do vSAN em um domínio atual. É possível adicionar o cluster a um dos seguintes domínios no mesmo projeto, rede de nuvem privada virtual (VPC) e zona:

Domínio de gerenciamento: adiciona um cluster gerenciado pelo vCenter Server e pelo NSX Manager de gerenciamento.
Domínio de carga de trabalho do VI: adiciona um cluster gerenciado pelo vCenter Server do domínio de carga de trabalho e pela instância do NSX Manager.

Resumo da arquitetura

Quando você adiciona um cluster do vSphere a um domínio do VCF, a implantação usa a seguinte arquitetura:

Hosts ESXi bare metal: cada novo host ESXi é uma instância bare metal z3-highmem-192-highlssd-metal anexada às sub-redes de camada 2 da sua rede VPC (gerenciamento de ESXi, vMotion, vSAN e endpoint de túnel NSX (TEP, na sigla em inglês)). Cada host se conecta por uma interface de rede principal (nic0) e interfaces de rede dinâmicas com inclusão de tag VLAN.
Sem outros dispositivos de gerenciamento: como você adiciona o cluster ao vCenter Server e ao NSX Manager que já gerenciam o domínio de destino, não implanta novos dispositivos de gerenciamento. Também não é necessário criar novos registros Cloud DNS, serviços de back-end, políticas de alta disponibilidade (HA) ou regras de encaminhamento do dispositivo. Em vez disso, adicione os novos hosts aos grupos de endpoints de rede (NEGs) zonais atuais.
Alocação e alinhamento de endereços IP: o VCF aloca endereços IP do vMotion e do vSAN de um pool de rede, e o NSX aloca endereços IP do TEP (vmk10) de um pool de endereços IP do NSX. Como nenhum pool é compatível com a atribuição estática por host no VCF 9.1, você alinha as NICs dinâmicas do Compute Engine aos endereços IP alocados pelo VCF durante a implantação, mantendo todas as validações do VCF ativadas.

Antes de começar

Antes de criar o cluster, verifique os requisitos nas seções a seguir e configure as variáveis de ambiente.

Verificar os requisitos do ambiente

Verifique se o ambiente atende aos seguintes requisitos:

Permissões: você tem os papéis necessários do Identity and Access Management (IAM) no projeto de destino, incluindo Administrador do Compute (roles/compute.admin), Administrador de DNS (roles/dns.admin) e Acessador de secrets do Secret Manager (roles/secretmanager.secretAccessor).
Credenciais no Secret Manager: se você alterou ou alternou as senhas do ESXi root, do SDDC Manager, do vCenter Server ou do NSX Manager no VCF após a implantação inicial, o Secret Manager não será atualizado automaticamente. Antes de executar os comandos neste documento, atualize os secrets correspondentes no Secret Manager ou forneça as senhas atualizadas diretamente para que correspondam às suas credenciais ativas do VCF.
Integridade do domínio: o domínio de destino está íntegro (vCenter Server, vSAN, NSX Manager, SDDC Manager e VCF Operations) e não tem tarefas com falha.
Imagem do vSphere Lifecycle Manager (vLCM): uma imagem do vLCM está disponível na biblioteca de imagens do VCF ou você planeja extrair uma imagem de um host. Use a mesma imagem que os clusters atuais usam para que todos os hosts permaneçam alinhados.
Dispositivos de armazenamento: cada novo host tem dispositivos SSD locais NVMe sem partições preexistentes, conforme exigido pela vSAN.
Contagem mínima de nós: um cluster requer pelo menos três nós bare metal, que é o mínimo necessário para o vSAN com uma falha a ser tolerada (FTT=1).
Tipo de máquina: todos os nós no cluster usam o mesmo tipo de máquina (z3-highmem-192-highlssd-metal para a arquitetura de armazenamento expresso (ESA) da vSAN).
Zona: o novo cluster está na mesma zona que os NEGs zonais de gerenciamento e NSX TEP atuais.
VM jumpbox: você tem acesso a uma VM jumpbox com a CLI gcloud, curl e jq instaladas e com conectividade de rede com a rede VPC (por exemplo, na sub-rede bm-gcp-demo).
Política de imagem confiável e VPC Service Controls: se a organização aplicar a política da organização constraints/compute.trustedImageProjects ou usar um perímetro de serviço do VPC Service Controls, verifique se o projeto permite o acesso de imagens ao projeto smve-prod-public-images (projects/999037279871). Para mais informações, consulte Gerenciar a capacidade do nó.
Rede baseada em VLAN: a solução VMware exige que as sub-redes da sua rede VPC tenham a propriedade Resolver máscara de sub-rede definida como Transmitir intervalo principal apenas com aprendizado para oferecer suporte à rede baseada em VLAN. Abra um tíquete de suporte na Central de suporte do console doGoogle Cloud com as seguintes informações:
- Produto: Google Cloud VMware Engine
- Prioridade: P2
- Categoria: conectividade de rede
- Impacto nos negócios: pergunta técnica geral
- Forneça mais detalhes: Allowlist L2 network connectivity for my project, além do ID do projeto, do número do projeto e da região e zona de destino da implantação.
Para mais informações sobre o suporte a redes baseadas em VLAN, consulte Emulação de camada 2: transmissão ARP e aprendizado de MAC personalizado.

Analisar exemplos de parâmetros de ambiente

Os comandos neste documento usam os seguintes parâmetros de exemplo:

Parâmetro de entrada	Valor de exemplo	Descrição
ID do projeto	`PROJECT_ID`	Mesmo projeto do Google Cloud do domínio de destino
Região e zona	`us-east4` / `us-east4-b`	A mesma zona dos NEGs zonais atuais
ID de cliente	`demo`	Identificador usado em nomes de recursos atuais
Domínio de destino	`mgmt-domain` (ou `wld01`)	Domínio de gerenciamento ou de carga de trabalho de VI atual
Nome do cluster	`cl02`	Nome do novo cluster do vSphere
Tipo de máquina	`z3-highmem-192-highlssd-metal`	Tipo de máquina homogêneo para todos os nós no cluster
Contagem de nós	`3`	Contagem mínima de nós para vSAN `FTT=1`
Rede VPC	`bm-demo`	Rede VPC atual
Sub-redes (ID da VLAN)	`bm-mgmt-demo` (sem tag), `bm-vmotion-demo` (`2`), `bm-vsan-demo` (`3`), `bm-nsx-demo` (`4`)	Sub-redes da camada 2 atuais
NEGs por zona	`bm-mgmt-demo`, `bm-nsx-tep-demo`	NEGs de gerenciamento e TEP do NSX atuais
Imagem do ESXi	Família `astra-vcf-9-1-x`, projeto `smve-prod-offline-depot`	Mesma versão da imagem do ESXi dos clusters atuais
Domínio e zonas de DNS	`vmware.gve` / `dns-zone-demo`, `rev-dns-zone-demo`	Zonas gerenciadas de encaminhamento e reversas do Cloud DNS
Gerenciador do SDDC	`sddcm.vmware.gve` (`192.168.0.3`)	Dispositivo do SDDC Manager atual
Senha de acesso root do ESXi `root`	`esxi-root-password`	Secret do Secret Manager que contém a senha do ESXi `root`

Planejar endereços IP e nomes de host

A tabela a seguir mostra o exemplo de plano de endereço IP para os três novos hosts ESXi:

Host ESXi	IP de gerenciamento (`nic0`)	vMotion (VLAN 2)	vSAN (VLAN 3)	TEP do NSX (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`

Escolher o domínio de destino

O domínio de destino selecionado determina qual vCenter Server, NSX Manager e zona de transporte de sobreposição gerenciam o novo cluster:

Parâmetro ou recurso	Cluster no domínio de gerenciamento	Cluster em um domínio de carga de trabalho de VI
Variável `TARGET_DOMAIN`	`mgmt-domain`	`wld01`
Como gerenciar o vCenter Server	`vc01.vmware.gve`	`vc02.vmware.gve`
Variável `NSX_MANAGER`	`nsx01.vmware.gve` (NSX de gerenciamento)	`nsx05.vmware.gve` (NSX dedicado) ou `nsx01.vmware.gve` (NSX de gerenciamento compartilhado)
Variável `TRANSPORT_ZONE`	`overlay-tz-mgmt-nsxt`	Zona de transporte de sobreposição da instância NSX do domínio de carga de trabalho

Verificar cota regional

Antes de provisionar nós bare metal ou criar um cluster, verifique se o projeto tem cota regional e global suficiente do Compute Engine. Adicione os recursos de todos os clusters atuais na região aos seguintes valores incrementais antes de compará-los com a cota do projeto:

Métrica de cota	Recursos necessários por nó bare metal	Recursos necessários para um cluster de três nós
`compute.googleapis.com/cpus_per_vm_family` para `Z3`	192 vCPUs	3 × 192 = 576 vCPUs
`compute.googleapis.com/local_ssd_total_storage_per_vm_family` para `Z3`	72 TB	3 × 72 TB = 216 TB
`compute.googleapis.com/hyperdisk_balanced_total_storage`	128 GB	3 × 128 GB = 384 GB
`compute.googleapis.com/resource_policies`	0 ao adicionar nós a um cluster atual	1 política de posicionamento distribuído por cluster
`compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha`	0 ao adicionar nós ou clusters sem novos appliances	1 por novo VIP do dispositivo de gerenciamento do VCF ou endpoint do NSX Edge

Para ver a lista completa de cotas necessárias e instruções sobre como visualizar ou solicitar aumentos de cota, consulte Cotas e limites.

Defina as variáveis de ambiente

Defina as seguintes variáveis de ambiente no shell do jumpbox para usar nos comandos deste guia:

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"

Antes de executar os comandos, substitua o seguinte:

PROJECT_ID: o ID do projeto de destino do Google Cloud.
VCF_ADMIN_PASSWORD: a senha de administrador do SDDC Manager.

Confirme se nenhum dos endereços IP planejados já está em uso por regras de encaminhamento ou instâncias:

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())"

Criar registros DNS

Ao implantar o domínio de gerenciamento, você criou as sub-redes de camada 2, a política de encaminhamento de entrada do Cloud DNS e as zonas gerenciadas de encaminhamento e reversas. Como a adição de um cluster não implanta novos dispositivos, você só precisa criar registros de encaminhamento (A) e reversos (PTR) para os novos hosts 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]'"

Criar instâncias bare metal

Crie uma política de posicionamento dedicada para o novo cluster. Em seguida, crie cada host ESXi bare metal com uma interface de gerenciamento principal (nic0) e NICs dinâmicas com tag de VLAN para vMotion (VLAN 2), vSAN (VLAN 3) e NSX TEP (VLAN 4).

Criar uma política de posicionamento

Crie a política de posicionamento em grupo:

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

Criar discos de inicialização e instâncias bare metal do ESXi

Crie o disco de inicialização do Google Cloud Hyperdisk Balanced e a instância do ESXi bare metal para cada host no 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())"

Atualizar associação do NEG

Todos os nós em uma zona precisam pertencer ao mesmo NEG zonal da sub-rede para que os dispositivos de rede do VCF possam rotear o tráfego entre os nós do cluster. Adicione os novos hosts ao NEG de gerenciamento e ao NEG de TEP do NSX:

# 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

Redefinir a senha raiz do ESXi

Para segurança e comissionamento de host, redefina a senha root de cada novo host para a senha root do ESXi armazenada no Secret Manager. Use o mesmo secret para comissionar os hosts em uma etapa posterior. Verifique se a senha atende aos requisitos de complexidade do VCF (pelo menos 15 caracteres, incluindo letras maiúsculas, letras minúsculas, dígitos e caracteres especiais). Se você mudou ou trocou as senhas do ESXi root ou do VCF após a implantação inicial, atualize o secret correspondente no Secret Manager antes de executar esses comandos.

Para redefinir a senha de root em cada novo host, execute os seguintes comandos na VM jumpbox e insira a senha inicial de root do ESXi quando solicitado:

# 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'

Criar um pool de rede dedicado

O VCF aloca endereços IP do vMotion e do vSAN do pool de rede que você seleciona ao comissionar hosts. Como os pools de rede dos clusters atuais contêm apenas os próprios endereços IP de host, crie um pool de rede dedicado com intervalos de IP que contenham os endereços IP exatos do vMotion e do vSAN que você atribuiu previamente às NICs dinâmicas do Compute Engine dos novos hosts. O uso de um pool de rede dedicado mantém a alocação de IP do VCF no conjunto de endereços IP pré-atribuídos do Compute Engine. Assim, você só precisa alinhar a ordem de host para IP mais tarde se houver uma incompatibilidade.

É possível criar o pool de rede usando as operações do VCF ou a API SDDC Manager:

Operações do VCF

Em Operações do VCF, acesse Gerenciamento de pool de rede, clique em Criar pool de rede e crie o pool de rede cl02-np01 com as configurações de rede do vMotion (VLAN 2, 192.168.2.21–192.168.2.23) e do vSAN (VLAN 3, 192.168.3.21–192.168.3.23) e uma MTU de 8896 bytes.

API SDDC Manager

Execute os comandos a seguir para criar o pool de rede e recuperar o ID dele:

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}"

Comissionar os hosts

Comissione os novos hosts ESXi no inventário do SDDC Manager usando as operações do VCF ou a API SDDC Manager:

Operações do VCF

Em Operações do VCF, acesse Inventário > Hosts > Hosts de comissão.
Selecione o pool de rede cl02-np01 e o tipo de armazenamento vSAN ESA.
Insira os FQDNs do host (esxi-h7.vmware.gve, esxi-h8.vmware.gve e esxi-h9.vmware.gve) e as credenciais do root.
Aceite as impressões digitais SSL, valide os hosts e clique em Commission.

API SDDC Manager

Execute os comandos a seguir para validar e comissionar os hosts e, em seguida, pesquise o ID da tarefa até que ele retorne 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 uma impressão digital SSL do host exibir um nome de certificado interno (não FQDN), o domínio de pesquisa de DNS não estará configurado no host. No host ESXi afetado, execute o comando esxcli network ip dns search add -d vmware.gve, execute novamente o script /var/lib/vmware/osdata/init.sh e, em seguida, execute o comando /sbin/generate-certificates e reinicie os serviços rhttpproxy e hostd (/etc/init.d/rhttpproxy restart && /etc/init.d/hostd restart).

Verificar o alinhamento de IP antes da implantação

Mantenha todas as validações de vSAN, vMotion e conectividade de rede ativadas no SDDC Manager. Essas verificações de validação só são aprovadas quando os endereços IP vmk1 (vMotion) e vmk2 (vSAN) que o VCF atribui a cada host correspondem aos endereços IP da NIC dinâmica do Compute Engine desse host. Se ocorrer uma incompatibilidade porque o SDDC Manager atribui endereços IP de pool em uma ordem de host diferente, a tarefa de criação do cluster será pausada na verificação de conectividade. Em seguida, alinhe as NICs dinâmicas em uma etapa subsequente antes de tentar novamente a tarefa.

Verifique se o intervalo do pool de rede corresponde aos endereços IP da placa de rede do vMotion e do vSAN do Compute Engine: confirme se o pool de rede contém apenas os endereços IP que você pré-atribuiu às NICs dinâmicas dos novos hosts (192.168.2.21–192.168.2.23 e 192.168.3.21–192.168.3.23 neste exemplo):

# 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

Atribuir endereços IP em ordem crescente de nome do host: pré-atribua os endereços IP do Compute Engine em ordem crescente de nome do host (esxi-h7 → .21, esxi-h8 → .22, esxi-h9 → .23) para que o conjunto de endereços IP seja idêntico em ambos os lados.
Confirme se o SDDC Manager não ignora as validações: no dispositivo do SDDC Manager (como root), verifique se o arquivo application.properties não contém propriedades 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 você adicionar o cluster usando a API SDDC Manager, não defina a propriedade "skipValidations": true no corpo da solicitação.
Dimensione o pool de TEP do NSX para corresponder aos endereços IP da NIC de TEP do Compute Engine: configure um novo pool de endereços IP de TEP do NSX estático para o cluster com o intervalo 192.168.4.21–192.168.4.23 (da variável TEP_START para a variável TEP_END), correspondendo aos endereços IP nas NICs dinâmicas da VLAN 4 dos novos hosts, e defina o gateway como 192.168.4.1.

Adicionar o cluster

É possível adicionar o cluster ao domínio de destino usando as operações do VCF ou a API SDDC Manager:

Operações do VCF

Faça login no VCF Operations, acesse Inventário, expanda Instâncias do VCF, selecione o domínio de destino (mgmt-domain ou wld01) e clique em Adicionar cluster (ou, na interface do SDDC Manager, acesse Domínios de carga de trabalho > domínio de destino > Ações > Adicionar cluster). Conclua o assistente usando as seguintes configurações:

Página do assistente	Campo	Valor
Armazenamento	Tipo	vSAN, Ativar vSAN ESA, vSAN HCI, criptografia de dados em trânsito desativada
Cluster	Nome do cluster	`cl02`
Imagem	Imagem do vLCM	Selecione a imagem que os clusters atuais usam ou selecione Extrair uma imagem de um host nesta instância do VCF (usando `esxi-h7`).
Hosts	Hosts	`esxi-h7`, `esxi-h8`, `esxi-h9` (comissionado como vSAN ESA com o pool de rede `cl02-np01`)
vSphere Distributed Switch	Perfil	Padrão (VDS único) ou personalizado: 1 uplink (`uplink1` → `vmnic0`), MTU `8896`, tipos de tráfego gerenciamento de ESX, gerenciamento de VM, vMotion, vSAN e NSX
Modo de troca do NSX	Modo operacional do switch virtual	Desmarque Aplicar o modo de switch virtual padrão configurado no NSX Manager e defina o Modo operacional como Padrão. Os hosts de soluções da VMware não são compatíveis com o modo padrão (Enhanced Datapath Standard).
Sobreposição de host NSX	Atribuição de VLAN e IP do TEP	VLAN `4` (correspondente à configuração atual do NSX), pool de IPs estáticos (não use DHCP): novo pool `cl02-tep-pool`, CIDR `192.168.4.0/24`, intervalo `192.168.4.21`–`192.168.4.23`, gateway `192.168.4.1`
Revisar	Enviar	Clique em Concluir. Acesse Gerenciamento de frotas > Tarefas para monitorar a tarefa e registrar o ID dela (`TASK_ID`).

API SDDC Manager

Recupere o ID do domínio de destino, o ID de personalidade da imagem do vLCM e os IDs de host comissionados. Em seguida, valide e envie a especificação para criar o 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'

Antes de executar os comandos, substitua PERSONALITY_ID pelo valor personalityId da imagem vLCM do cluster.

Se o VCF atribuir a um host um endereço IP do vMotion ou do vSAN diferente da NIC dinâmica do Compute Engine, a tarefa será interrompida na etapa de verificação da conectividade do vSAN e do vMotion. Deixe a tarefa no estado de falha, conclua as etapas em Alinhar as NICs dinâmicas do vMotion e do vSAN e tente novamente. Não cancele a tarefa nem desative a verificação de validação.

Alinhar NICs dinâmicas do vMotion e do vSAN

Siga as etapas desta seção se a tarefa de criação do cluster parar na etapa de verificação da conectividade do vSAN e do vMotion. Se a tarefa passar por essa etapa, execute apenas as etapas 1 e 2 para confirmar o alinhamento de IP e prossiga para Alinhar NICs dinâmicas do NSX TEP.

Leia os endereços IP alocados pelo VCF: consulte o endpoint /v1/hosts do SDDC Manager (ou o banco de dados platform do SDDC Manager) para analisar quais endereços IP do vMotion (vmk1) e do vSAN (vmk2) o VCF alocou para cada 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;"

Compare com as NICs dinâmicas do Compute Engine: liste os endereços IP atuais das NICs dinâmicas em cada novo 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

Exclua todas as NICs dinâmicas incompatíveis primeiro e, em seguida, adicione-as novamente: exclua todas as NICs dinâmicas incompatíveis (a interface nic0.2 para vMotion e a interface nic0.3 para vSAN) em todos os hosts incompatíveis antes de adicionar novamente qualquer interface. Caso contrário, os endereços IP trocados entre dois hosts falharão com um erro 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}"

Tente novamente a tarefa do cluster com falha: em Operações do VCF, acesse Gerenciamento de frota > Tarefas para tentar novamente a tarefa ou execute o seguinte comando da 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"}'
```
A tarefa repetida executa a verificação de conectividade para vSAN e vMotion novamente e é bem-sucedida depois que todas as NICs dinâmicas do Compute Engine correspondem aos endereços IP atribuídos pelo VCF.

Alinhar as NICs dinâmicas do NSX TEP

Depois que o NSX configurar os hosts como nós de transporte, verifique e alinhe as NICs dinâmicas do TEP do NSX (vmk10) da VLAN 4 nos novos hosts.

Recupere os endereços IP do TEP alocados pelo NSX: consulte o NSX Manager do domínio de destino (NSX_MANAGER) ou execute o comando esxcli network ip interface ipv4 get -i vmk10 em cada 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'

Antes de executar os comandos, substitua NSX_ADMIN_PASSWORD pela senha do NSX Manager admin (disponível no endpoint /v1/credentials do SDDC Manager ou no gerenciamento de senhas do VCF Operations).

Compare com a NIC TEP do Compute Engine (VLAN 4): compare os endereços IP vmk10 atribuídos pelo NSX com os endereços IP da NIC dinâmica da VLAN 4 nos novos hosts (esxi-h7, esxi-h8 e esxi-h9). Somente os novos hosts estão no escopo. Não modifique as NICs TEP de hosts em outros clusters.

Recrie as NICs de TEP incompatíveis: para todos os novos hosts incompatíveis, primeiro remova cada host do NEG de TEP e exclua a interface nic0.4 em todos os hosts incompatíveis. Em seguida, adicione novamente a interface nic0.4 e reconecte os hosts ao NEG do 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}"

Verificar a implantação do cluster

Depois que a tarefa de criação do cluster for concluída e você alinhar todas as NICs dinâmicas, verifique o seguinte:

vCenter Server (vc01 ou vc02): o cluster cl02 e os três hosts estão conectados e íntegros, sem alarmes de rede.
vSAN: para o cluster cl02, acesse Monitor > vSAN > Skyline Health e confirme se todas as verificações de integridade foram aprovadas e se o repositório de dados vSAN mostra a capacidade combinada dos três hosts.
NSX Manager: acesse Sistema > Fabric > Hosts e confirme se cada novo host mostra Sucesso e Ativo e se todos os túneis de sobreposição estão ativos.
Operações do VCF: o status do cluster é Ativo no domínio de destino, e a lista de tarefas não mostra tarefas com falha.
Clusters atuais: todos os outros clusters no domínio permanecem íntegros.
Opcional: migre uma VM de teste usando o vMotion entre um cluster atual e o cluster do cl02 e entre hosts no cluster do cl02.

Em um shell de host ESXi (por exemplo, esxi-h7), verifique a conectividade de frame jumbo (MTU 8896 menos cabeçalho IP/ICMP de 28 bytes = 8868 bytes) nas interfaces 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

Opcional: configurar falhas de vSAN a serem toleradas

Para o vSAN ESA, o VCF cria e atribui uma política de armazenamento de dados padrão com base no tipo de cluster e no número de hosts. Para configurar a definição de FTT explicitamente, escolha uma política compatível com a contagem de hosts do cluster:

Falhas a tolerar	Esquema de posicionamento de dados	Mínimo de hosts
`FTT=1`	RAID-1 (espelhamento) ou RAID-5 (programação de eliminação)	3 (recomendamos 4 ou mais para recriar após uma falha do host ou durante a manutenção)
`FTT=2`	RAID-1 (espelhamento)	5
`FTT=2`	RAID-6 (programação de eliminação)	6

Para definir a política de armazenamento padrão no cliente vSphere do vCenter Server do domínio de destino (vc01 ou vc02), faça o seguinte:

Desative o gerenciamento automático de políticas para o cluster do vSAN ESA para que o vSAN não substitua sua política padrão personalizada.
Acesse Políticas e perfis > Políticas de armazenamento de VM > Criar, ative as regras de armazenamento do vSAN e, na seção Disponibilidade, selecione Falhas a tolerar (por exemplo, 1 falha - RAID-1 (espelhamento) para 3 a 4 hosts ou 2 falhas - RAID-6 (codificação de eliminação) para 6 ou mais hosts).
Defina a nova política como padrão do repositório de dados: selecione o repositório de dados do vSAN cl02, acesse Configurar > Geral > Política de armazenamento padrão > Editar e selecione a nova política.
Aplique a política às VMs atuais (Políticas de VM > Editar políticas de armazenamento de VM). Acesse Monitor > vSAN > Virtual Objects para o cluster cl02 para verificar a conformidade.

Resolver problemas de criação de cluster

A tabela a seguir lista problemas, causas e soluções comuns ao adicionar um cluster do vSphere a um domínio:

Problema	Causa	Resolução
A validação de conectividade do vSAN e do vMotion falha; novos hosts relatam problemas de integridade	Quando você cria ou expande um cluster, o SDDC Manager aloca endereços IP `vmk1` e `vmk2` do pool de rede sem preservar a ordem do host.	Mantenha as validações ativadas. Criar um pool de rede dedicado que corresponda aos endereços IP da placa de rede do Compute Engine, verificar o alinhamento pré-implantação e, se a tarefa for pausada na verificação de conectividade, alinhar as NICs dinâmicas e tentar novamente.
O status do host NSX é `Degraded` ou os túneis estão inativos depois que você adiciona o cluster	O NSX Manager atribui endereços IP de TEP (`vmk10`) do pool de IPs aleatoriamente, então eles podem não corresponder à NIC de TEP do Compute Engine. As sub-redes de NIC dinâmica não são compatíveis com DHCP.	Use um pool de IPs de TEP dedicado que corresponda aos endereços IP de TEP do Compute Engine e alinhe as NICs dinâmicas de TEP após a preparação do host do NSX.
O agente ou host `NSX_VDL2` informa `Degraded` enquanto o BFD está ativo	O endereço IP do gateway está ausente no pool de IPs do NSX TEP.	Configure o gateway de sub-rede (`192.168.4.1`) no pool de IPs do TEP.
Erro `IP_IN_USE` ao adicionar novamente uma NIC dinâmica	Dois hosts trocaram de endereço IP ou um endereço IP planejado se sobrepõe a outro cluster.	Exclua todas as NICs dinâmicas incompatíveis em todos os hosts antes de adicionar qualquer interface novamente e verifique se o plano de IP não se sobrepõe aos clusters atuais.
O modo de switch virtual do NSX não é compatível	No VCF 9.x, o modo de switch virtual NSX padrão é o Enhanced Datapath Standard, que não é compatível com os hosts da Solução VMware.	Desmarque Aplicar o modo de switch virtual padrão configurado no NSX Manager e defina Modo operacional como Padrão (ou `"hostSwitchOperationalMode": "STANDARD"` na especificação da API). Para mais informações, consulte Modo de switch virtual do NSX.
Os hosts não podem dar um ping no gateway da sub-rede (`.1`)	OGoogle Cloud não responde a solicitações de eco ICMP em endereços IP de gateway de sub-rede.	Comportamento esperado. Ignore os avisos de ping do gateway.
Configuração da sincronização de horário (NTP)	Os hosts bare metal usam o servidor de metadados do Compute Engine para sincronização de horário.	Use o endereço IP do servidor de metadados (`169.254.169.254`) diretamente como o servidor NTP.
A impressão digital ou o certificado do host mostra um nome interno	O domínio de pesquisa de DNS não está definido no host ou o nome do host tem um ponto final.	Execute o comando `esxcli network ip dns search add -d vmware.gve`, execute novamente o script `/var/lib/vmware/osdata/init.sh`, execute o comando `/sbin/generate-certificates` e reinicie os serviços `rhttpproxy` e `hostd`.
Falha no comissionamento do host	O adaptador VMkernel `vmk0` ainda usa DHCP porque o serviço de inicialização não o converteu.	Execute o comando `esxcli network ip interface ipv4 get -i vmk0`. Se o tipo for `DHCP`, defina-o como estático manualmente (por exemplo, em `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`).
Erros de replicação do vSAN, tempos limite do vMotion ou fragmentação de sobreposição do NSX	O VCF define o VDS, os adaptadores VMkernel e os perfis NSX como uma MTU de `9000` bytes, e a rede VPC descarta frames maiores que `8896` bytes.	Configure uma MTU de `8896` bytes no VDS, no pool de rede (vMotion e vSAN) e no perfil de uplink do NSX. Para mais informações, consulte Incompatibilidade de MTU do VDS.
O assistente solicita um ID da VLAN para o grupo de portas de sobreposição	O perfil padrão do VDS requer o ID da VLAN de sobreposição do host do NSX.	Insira o ID da VLAN do TEP da configuração atual do NSX (`4` neste guia).
Não há grupo de portas para VMs de carga de trabalho no novo cluster	O perfil padrão do VDS cria apenas grupos de portas de infraestrutura.	Crie um grupo de portas distribuídas para VMs de carga de trabalho depois de criar o cluster ou use uma configuração de switch personalizada.
Não é possível adicionar hosts com a imagem do vLCM selecionada	A imagem do vLCM do cluster é diferente do build do ESXi instalado nos hosts.	Use a mesma família de imagens ESXi que seus clusters atuais usam ou extraia a imagem de um dos novos hosts.

A seguir

Expanda ou compacte um cluster atual em Adicionar ou remover nós em um cluster do vSphere.
Gerencie a capacidade de nós bare metal no console do Google Cloud em Gerenciar capacidade de nós.
Consulte as diretrizes de dimensionamento e arquitetura de cluster em Sobre clusters do vSphere.
Confira as soluções alternativas comuns de implantação e operacionais em Problemas conhecidos.
Saiba mais sobre NICs dinâmicas e instâncias bare metal.