Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Agrega un clúster de vSphere a un dominio

En este documento, se describe cómo agregar un clúster de vSphere a un dominio existente de VMware Cloud Foundation (VCF) 9.1 en VMware Solution en Google Cloud con instancias de Compute Engine Bare Metal. Agrega un clúster cuando necesites escalar la capacidad de procesamiento y almacenamiento de vSAN más allá de un solo clúster, aislar cargas de trabajo o aplicar imágenes de vSphere Lifecycle Manager (vLCM) o políticas de almacenamiento de vSAN independientes dentro de un dominio existente. Puedes agregar el clúster a cualquiera de los siguientes dominios en el mismo proyecto, red de nube privada virtual (VPC) y zona:

Dominio de administración: Agrega un clúster administrado por el servidor de vCenter y NSX Manager de administración.
Dominio de carga de trabajo de VI: Agrega un clúster administrado por el dominio de carga de trabajo vCenter Server y su instancia de NSX Manager.

Resumen de la arquitectura

Cuando agregas un clúster de vSphere a un dominio de VCF existente, la implementación usa la siguiente arquitectura:

Hosts de ESXi de equipos físicos: Cada host de ESXi nuevo es una instancia de z3-highmem-192-highlssd-metal de equipos físicos conectada a las subredes de capa 2 existentes de tu red de VPC (administración de ESXi, vMotion, vSAN y extremo de túnel de NSX (TEP)). Cada host se conecta a través de una interfaz de red principal (nic0) y de interfaces de red dinámicas con etiquetado de VLAN.
No hay dispositivos de administración adicionales: Debido a que agregas el clúster a vCenter Server y NSX Manager que ya administran el dominio de destino, no implementas dispositivos de administración nuevos. Tampoco creas registros de Cloud DNS, servicios de backend, políticas de alta disponibilidad (HA) ni reglas de reenvío nuevos para el dispositivo. En su lugar, agrega los hosts nuevos a los grupos de extremos de red (NEG) zonales existentes.
Asignación y alineación de direcciones IP: VCF asigna direcciones IP de vMotion y vSAN desde un grupo de redes, y NSX asigna direcciones IP de TEP (vmk10) desde un grupo de direcciones IP de NSX. Debido a que ninguno de los grupos admite la asignación estática por host en VCF 9.1, debes alinear las NIC dinámicas de Compute Engine con las direcciones IP asignadas por VCF durante la implementación, mientras mantienes habilitadas todas las validaciones de VCF.

Antes de comenzar

Antes de crear el clúster, verifica los requisitos en las siguientes secciones y configura tus variables de entorno.

Verifica los requisitos del entorno

Verifica que tu entorno cumpla con los siguientes requisitos:

Permisos: Tienes los roles de Identity and Access Management (IAM) necesarios en el proyecto de destino, incluidos Administrador de Compute (roles/compute.admin), Administrador de DNS (roles/dns.admin) y Descriptor de acceso a secretos de Secret Manager (roles/secretmanager.secretAccessor).
Credenciales en Secret Manager: Si cambiaste o rotaste tus contraseñas de ESXi root, SDDC Manager, vCenter Server o NSX Manager en VCF después de la implementación inicial, Secret Manager no se actualiza automáticamente. Antes de ejecutar los comandos de este documento, actualiza los secretos correspondientes en Secret Manager o proporciona las contraseñas actualizadas directamente para que coincidan con tus credenciales de VCF activas.
Estado del dominio: El dominio de destino está en buen estado (vCenter Server, vSAN, NSX Manager, SDDC Manager y VCF Operations) y no tiene tareas con errores.
Imagen de vSphere Lifecycle Manager (vLCM): Hay una imagen de vLCM disponible en la biblioteca de imágenes de VCF o planeas extraer una imagen de un host. Usa la misma imagen que usan tus clústeres existentes para que todos los hosts permanezcan alineados.
Dispositivos de almacenamiento: Cada host nuevo tiene dispositivos SSD locales NVMe sin particiones preexistentes, como se requiere para vSAN.
Recuento mínimo de nodos: Un clúster requiere al menos tres nodos de equipos físicos, que es el mínimo necesario para vSAN con una falla que tolerar (FTT=1).
Tipo de máquina: Todos los nodos del clúster usan el mismo tipo de máquina (z3-highmem-192-highlssd-metal para la arquitectura de almacenamiento de vSAN Express (ESA)).
Zona: El clúster nuevo se encuentra en la misma zona que los NEG zonales de administración y NSX TEP existentes.
VM de jumpbox: Tienes acceso a una VM de jumpbox con la CLI de gcloud, curl y jq instaladas, y con conectividad de red a la red de VPC (por ejemplo, en la subred bm-gcp-demo).
Política de imágenes confiables y Controles del servicio de VPC: Si tu organización aplica la política de la organización constraints/compute.trustedImageProjects o usa un perímetro de servicio de Controles del servicio de VPC, asegúrate de que tu proyecto permita el acceso de imágenes al proyecto smve-prod-public-images (projects/999037279871). Para obtener más información, consulta Administra la capacidad de los nodos.
Herramientas de redes basadas en VLAN: La solución de VMware requiere que las subredes de tu red de VPC tengan la propiedad Resolver máscara de subred configurada como Transmitir solo el rango principal con aprendizaje para admitir herramientas de redes basadas en VLAN. Abre un ticket de asistencia en el Centro de asistencia de la consola deGoogle Cloud con la siguiente información:
- Producto: Google Cloud VMware Engine
- Prioridad: P2
- Categoría: Conectividad de red
- Impacto comercial: Pregunta técnica general
- Proporciona más detalles: Allowlist L2 network connectivity for my project, junto con el ID del proyecto, el número del proyecto, y la región y la zona de destino para la implementación.
Para obtener más información sobre la compatibilidad con las redes basadas en VLAN, consulta Emulación de capa 2: transmisión de ARP y aprendizaje de MAC personalizado.

Revisa los parámetros de entorno de ejemplo

Los comandos de este documento usan los siguientes parámetros de ejemplo:

Parámetro de datos	Valor de ejemplo	Descripción
ID del proyecto	`PROJECT_ID`	Mismo proyecto de Google Cloud que el dominio de destino
Región y zona	`us-east4`/`us-east4-b`	La misma zona que los NEG zonales existentes
ID de cliente	`demo`	Identificador que se usa en los nombres de recursos existentes
Dominio de destino	`mgmt-domain` (o `wld01`)	Dominio de administración o dominio de carga de trabajo de VI existente
Nombre del clúster	`cl02`	Nombre del nuevo clúster de vSphere
Tipo de máquina	`z3-highmem-192-highlssd-metal`	Tipo de máquina homogéneo para todos los nodos del clúster
Recuento de nodos	`3`	Cantidad mínima de nodos para vSAN `FTT=1`
Red de VPC	`bm-demo`	Red de VPC existente
Subredes (ID de VLAN)	`bm-mgmt-demo` (sin etiqueta), `bm-vmotion-demo` (`2`), `bm-vsan-demo` (`3`), `bm-nsx-demo` (`4`)	Subredes de capa 2 existentes
NEG zonales	`bm-mgmt-demo`, `bm-nsx-tep-demo`	NEG de administración y TEP de NSX existentes
Imagen de ESXi	Familia `astra-vcf-9-1-x`, proyecto `smve-prod-offline-depot`	La misma compilación de imagen de ESXi que los clústeres existentes
Dominio y zonas de DNS	`vmware.gve` / `dns-zone-demo`, `rev-dns-zone-demo`	Zonas administradas de reenvío y reversas existentes de Cloud DNS
SDDC Manager	`sddcm.vmware.gve` (`192.168.0.3`)	Dispositivo de SDDC Manager existente
Contraseña de ESXi de `root`	`esxi-root-password`	Secreto de Secret Manager existente que contiene la contraseña de ESXi `root`

Planifica las direcciones IP y los nombres de host

En la siguiente tabla, se muestra el plan de direcciones IP de ejemplo para los tres hosts de ESXi nuevos:

Host de ESXi	IP de administración (`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`

Elige el dominio de destino

El dominio de destino que selecciones determinará qué vCenter Server, NSX Manager y zona de transporte de superposición administrarán el clúster nuevo:

Parámetro o recurso	Clúster en el dominio de administración	Clúster en un dominio de carga de trabajo de VI
Variable `TARGET_DOMAIN`	`mgmt-domain`	`wld01`
Administra vCenter Server	`vc01.vmware.gve`	`vc02.vmware.gve`
Variable `NSX_MANAGER`	`nsx01.vmware.gve` (NSX de administración)	`nsx05.vmware.gve` (NSX dedicado) o `nsx01.vmware.gve` (NSX de administración compartida)
Variable `TRANSPORT_ZONE`	`overlay-tz-mgmt-nsxt`	Zona de transporte de superposición de la instancia de NSX del dominio de carga de trabajo

Verifica la cuota regional

Antes de aprovisionar nodos de equipos físicos o crear un clúster, verifica que tu proyecto tenga suficiente cuota regional y global de Compute Engine. Agrega los recursos de todos los clústeres existentes en la región a los siguientes valores incrementales antes de compararlos con la cuota de tu proyecto:

Métrica de cuota	Recursos necesarios por nodo de Bare Metal	Recursos necesarios para un clúster de 3 nodos
`compute.googleapis.com/cpus_per_vm_family` para `Z3`	192 CPUs virtuales	3 × 192 = 576 CPUs virtuales
`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 cuando se agregan nodos a un clúster existente	1 política de posición distribuida por clúster
`compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha`	0 cuando se agregan nodos o clústeres sin dispositivos nuevos	1 por cada nueva VIP del dispositivo de administración de VCF o extremo de NSX Edge

Para obtener la lista completa de las cuotas requeridas y las instrucciones para ver o solicitar aumentos de cuota, consulta Cuotas y límites.

Configura las variables de entorno

Establece las siguientes variables de entorno en la shell de jumpbox para usarlas en los comandos de esta guía:

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 ejecutar los comandos, reemplaza lo siguiente:

PROJECT_ID: Es el ID de tu proyecto de Google Cloud de destino.
VCF_ADMIN_PASSWORD: Es la contraseña de administrador de SDDC Manager.

Confirma que ninguna de las direcciones IP que planeas usar ya esté en uso por reglas de reenvío o instancias existentes:

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 registros DNS

Cuando implementaste el dominio de administración, creaste las subredes de capa 2, la política de reenvío entrante de Cloud DNS y las zonas administradas de reenvío y reversas. Debido a que agregar un clúster no implementa dispositivos nuevos, solo necesitas crear registros de reenvío (A) y reversos (PTR) para los hosts ESXi nuevos:

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 instancias de equipos físicos

Crea una política de posición dedicada para el clúster nuevo. Luego, creas cada host ESXi de equipos físicos con una interfaz de administración principal (nic0) y NIC dinámicas con etiqueta de VLAN para vMotion (VLAN 2), vSAN (VLAN 3) y NSX TEP (VLAN 4).

Crear una política de posición

Crea la política de posición de grupo:

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

Crea discos de arranque e instancias de ESXi de Bare Metal

Crea el disco de arranque de Google Cloud Hyperdisk Balanced y la instancia de ESXi de equipos físicos para cada host del clúster:

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

Actualiza la membresía del NEG

Todos los nodos de una zona deben pertenecer al mismo NEG zonal de la subred para que los dispositivos de red de VCF puedan enrutar el tráfico entre los nodos del clúster. Agrega los hosts nuevos al NEG de administración existente y al NEG de TEP de 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

Restablece la contraseña raíz de ESXi

Para la seguridad y la puesta en marcha del host, restablece la contraseña de root de cada host nuevo a la contraseña de ESXi root almacenada en Secret Manager. Usarás el mismo secreto para poner en servicio los hosts en un paso posterior. Asegúrate de que la contraseña cumpla con los requisitos de complejidad de VCF (al menos 15 caracteres, incluidas letras mayúsculas, letras minúsculas, dígitos y caracteres especiales). Si cambiaste o rotaste tus contraseñas de ESXi root o VCF después de la implementación inicial, actualiza el secreto correspondiente en Secret Manager antes de ejecutar estos comandos.

Para restablecer la contraseña de root en cada host nuevo, ejecuta los siguientes comandos desde la VM de jumpbox y, cuando se te solicite, ingresa la contraseña inicial de ESXi de root:

# 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 grupo de redes dedicado

VCF asigna direcciones IP de vMotion y vSAN del grupo de redes que seleccionas cuando pones en servicio los hosts. Debido a que los grupos de redes de tus clústeres existentes solo contienen sus propias direcciones IP de host, crea un grupo de redes dedicado cuyos rangos de IP contengan las direcciones IP exactas de vMotion y vSAN que preasignaste a las NIC dinámicas de Compute Engine de los hosts nuevos. El uso de un grupo de red dedicado mantiene la asignación de IP de VCF dentro del conjunto de direcciones IP de Compute Engine asignadas previamente, por lo que solo necesitas alinear el orden de host a IP más adelante si se produce una discrepancia.

Puedes crear el grupo de redes con VCF Operations o la API de SDDC Manager:

VCF Operations

En Operaciones de VCF, ve a Administración de grupos de redes, haz clic en Crear grupo de redes y crea el grupo de redes cl02-np01 con la configuración de red de vMotion (VLAN 2, 192.168.2.21–192.168.2.23) y vSAN (VLAN 3, 192.168.3.21–192.168.3.23) y una MTU de 8896 bytes.

API de SDDC Manager

Ejecuta los siguientes comandos para crear el grupo de redes y recuperar su 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}"

Comisiona a los creadores

Pon en servicio los nuevos hosts de ESXi en el inventario de SDDC Manager con VCF Operations o la API de SDDC Manager:

VCF Operations

En VCF Operations, ve a Inventory > Hosts > Commission Hosts.
Selecciona el grupo de redes cl02-np01 y el tipo de almacenamiento vSAN ESA.
Ingresa los FQDN del host (esxi-h7.vmware.gve, esxi-h8.vmware.gve y esxi-h9.vmware.gve) y las credenciales de root.
Acepta las huellas digitales SSL, valida los hosts y haz clic en Commission.

API de SDDC Manager

Ejecuta los siguientes comandos para validar y encargar los hosts y, luego, sondea el ID de la tarea hasta que devuelva 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'

Si una huella digital SSL de host muestra un nombre de certificado interno (que no es FQDN), el dominio de búsqueda de DNS no está configurado en el host. En el host de ESXi afectado, ejecuta el comando esxcli network ip dns search add -d vmware.gve, vuelve a ejecutar la secuencia de comandos /var/lib/vmware/osdata/init.sh y, luego, ejecuta el comando /sbin/generate-certificates y reinicia los servicios rhttpproxy y hostd (/etc/init.d/rhttpproxy restart && /etc/init.d/hostd restart).

Verifica la alineación de IP antes de la implementación

Mantén habilitadas todas las validaciones de vSAN, vMotion y conectividad de red en SDDC Manager. Estas verificaciones de validación se aprueban solo cuando las direcciones IP de vmk1 (vMotion) y vmk2 (vSAN) que VCF asigna a cada host coinciden con las direcciones IP de NIC dinámica de Compute Engine de ese host. Si se produce una discrepancia porque SDDC Manager asigna direcciones IP de grupo en un orden de host diferente, la tarea de creación del clúster se detiene en la verificación de conectividad. Luego, alineas las NIC dinámicas en un paso posterior antes de volver a intentar la tarea.

Verifica que el rango del grupo de redes coincida con las direcciones IP de las NIC de vMotion y vSAN de Compute Engine: Confirma que el grupo de redes solo contenga las direcciones IP que asignaste previamente a las NIC dinámicas de los hosts nuevos (192.168.2.21–192.168.2.23 y 192.168.3.21–192.168.3.23 en este ejemplo):

# 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

Asigna direcciones IP en orden ascendente de nombre de host: Asigna previamente las direcciones IP de Compute Engine en orden ascendente de nombre de host (esxi-h7 → .21, esxi-h8 → .22, esxi-h9 → .23) para que el conjunto de direcciones IP sea idéntico en ambos lados.
Confirma que SDDC Manager no omita las validaciones: En el dispositivo de SDDC Manager (como root), verifica que el archivo application.properties no contenga ninguna propiedad 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
```
Si agregas el clúster con la API de SDDC Manager, no configures la propiedad "skipValidations": true en el cuerpo de la solicitud.
Ajusta el tamaño del grupo de TEP de NSX para que coincida con las direcciones IP de la NIC de TEP de Compute Engine: Configura un nuevo grupo de direcciones IP de TEP de NSX estático para el clúster con el rango 192.168.4.21–192.168.4.23 (desde la variable TEP_START hasta la variable TEP_END), que coincida con las direcciones IP de las NIC dinámicas de la VLAN 4 de los hosts nuevos, y establece la puerta de enlace en 192.168.4.1.

Agrega el clúster

Puedes agregar el clúster a tu dominio de destino con VCF Operations o la API de SDDC Manager:

VCF Operations

Accede a VCF Operations, ve a Inventario, expande Instancias de VCF, selecciona el dominio de destino (mgmt-domain o wld01) y haz clic en Agregar clúster (o, en la IU de SDDC Manager, ve a Dominios de carga de trabajo > dominio de destino > Acciones > Agregar clúster). Completa el asistente con la siguiente configuración:

Página del asistente	Campo	Valor
Almacenamiento	Tipo	vSAN, Habilitar ESA de vSAN, HCI de vSAN, encriptación de datos en tránsito desactivada
Clúster	Nombre del clúster	`cl02`
Imagen	Imagen de vLCM	Selecciona la imagen que usan tus clústeres existentes o selecciona Extraer una imagen de un host en esta instancia de VCF (con `esxi-h7`).
Hosts	Hosts	`esxi-h7`, `esxi-h8`, `esxi-h9` (comisionados como vSAN ESA con el grupo de redes `cl02-np01`)
vSphere Distributed Switch	Perfil	Predeterminado (VDS único) o personalizado: 1 vínculo de subida (`uplink1` → `vmnic0`), MTU `8896`, tipos de tráfico ESX Management, VM Management, vMotion, vSAN y NSX
Modo de conmutador de NSX	Modo operativo del interruptor virtual	Borra Apply the default virtual switch mode configured in NSX Manager y establece Operational Mode en Standard. Los hosts de la solución de VMware no admiten el modo predeterminado (Ruta de datos mejorada estándar).
Superposición de host de NSX	Asignación de VLAN y de IP de TEP	VLAN `4` (que coincide con la configuración de NSX existente), grupo de IP estáticas (no uses DHCP): grupo nuevo `cl02-tep-pool`, CIDR `192.168.4.0/24`, rango `192.168.4.21`–`192.168.4.23`, puerta de enlace `192.168.4.1`
Revisar	Enviar	Haz clic en Finalizar. Ve a Administración de flotas > Tareas para supervisar la tarea y registrar su ID (`TASK_ID`).

API de SDDC Manager

Recupera el ID del dominio de destino, el ID de la personalidad de la imagen de vLCM y los IDs de los hosts encargados y, luego, valida y envía la especificación para crear el clúster:

# 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 ejecutar los comandos, reemplaza PERSONALITY_ID por el valor personalityId de la imagen de vLCM de tu clúster.

Si VCF asigna a un host una dirección IP de vMotion o vSAN que difiere de su NIC dinámica de Compute Engine, la tarea se detiene en el paso de verificación de la conectividad de vSAN y vMotion. Deja la tarea en el estado de error, completa los pasos que se indican en Alinea las NIC dinámicas de vMotion y vSAN y, luego, vuelve a intentar la tarea. No canceles la tarea ni inhabilites la verificación de validación.

Alinea las NIC dinámicas de vMotion y vSAN

Aplica los pasos de esta sección si la tarea de creación del clúster se detiene en el paso de verificación de la conectividad de vSAN y vMotion. Si la tarea pasa ese paso, ejecuta solo los pasos 1 y 2 para confirmar la alineación de IP y, luego, continúa con Alinea las NIC dinámicas de TEP de NSX.

Lee las direcciones IP asignadas por VCF: Consulta el extremo /v1/hosts del SDDC Manager (o la base de datos platform del SDDC Manager) para revisar qué direcciones IP de vMotion (vmk1) y vSAN (vmk2) asignó VCF a 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;"

Compara con las NIC dinámicas de Compute Engine: Enumera las direcciones IP de las NIC dinámicas actuales en cada host nuevo:

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

Primero, borra todas las NIC dinámicas que no coincidan y, luego, vuelve a agregarlas: Borra todas las NIC dinámicas que no coincidan (la interfaz nic0.2 para vMotion y la interfaz nic0.3 para vSAN) en todos los hosts que no coincidan antes de volver a agregar cualquier interfaz; de lo contrario, las direcciones IP intercambiadas entre dos hosts fallarán con un error 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}"

Vuelve a intentar la tarea del clúster con errores: En VCF Operations, ve a Administración de flotas > Tareas para volver a intentar la tarea o ejecuta el siguiente comando de la API de 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"}'
```
La tarea que se vuelve a intentar ejecuta la verificación de conectividad para vSAN y vMotion de nuevo y se completa correctamente después de que todas las NIC dinámicas de Compute Engine coincidan con las direcciones IP asignadas por VCF.

Alinea las NIC dinámicas de TEP de NSX

Después de que NSX configure los hosts como nodos de transporte, verifica y alinea las NIC dinámicas de NSX TEP (vmk10) de la VLAN 4 en los hosts nuevos.

Recupera las direcciones IP de TEP asignadas por NSX: Consulta el NSX Manager del dominio de destino (NSX_MANAGER) o ejecuta el comando esxcli network ip interface ipv4 get -i vmk10 en cada host de 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 ejecutar los comandos, reemplaza NSX_ADMIN_PASSWORD por la contraseña de NSX Manager admin (disponible en el extremo /v1/credentials de SDDC Manager o en la administración de contraseñas de VCF Operations).

Compara con la NIC de TEP de Compute Engine (VLAN 4): Compara las direcciones IP de vmk10 asignadas por NSX con las direcciones IP de la NIC dinámica de la VLAN 4 en los hosts nuevos (esxi-h7, esxi-h8 y esxi-h9). Solo los hosts nuevos están dentro del alcance; no modifiques las NIC de TEP de los hosts de otros clústeres.

Vuelve a crear las NIC de TEP que no coinciden: Para todos los hosts nuevos que no coinciden, primero desconecta cada host del NEG de TEP y borra la interfaz nic0.4 en todos los hosts que no coinciden. Luego, vuelve a agregar la interfaz nic0.4 y a conectar los hosts al NEG de 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 la implementación del clúster

Después de que se complete la tarea de creación del clúster y alinees todas las NIC dinámicas, verifica lo siguiente:

Servidor de vCenter (vc01 o vc02): El clúster de cl02 y los tres hosts están conectados y en buen estado, sin alarmas de red.
vSAN: Para el clúster cl02, ve a Supervisar > vSAN > Skyline Health y confirma que se aprueben todas las verificaciones de estado y que el almacén de datos de vSAN muestre la capacidad combinada de los tres hosts.
NSX Manager: Ve a Sistema > Fabric > Hosts y confirma que cada host nuevo muestre Correcto y Activo, y que todos los túneles de superposición estén activos.
Operaciones de VCF: El estado del clúster es Activo en el dominio de destino y la lista de tareas no muestra tareas con errores.
Clústeres existentes: Todos los demás clústeres del dominio permanecen en buen estado.
Opcional: Migra una VM de prueba con vMotion entre un clúster existente y el clúster de cl02, y entre hosts dentro del clúster de cl02.

Desde una shell de host de ESXi (por ejemplo, esxi-h7), verifica la conectividad de las tramas gigantes (MTU de 8896 menos el encabezado de IP/ICMP de 28 bytes = 8868 bytes) en las interfaces de vMotion, vSAN y 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: Configura los errores de vSAN que se tolerarán

Para vSAN ESA, VCF crea y asigna una política de almacenamiento de almacén de datos predeterminada según el tipo de clúster y la cantidad de hosts. Para configurar el parámetro de configuración de FTT de forma explícita, elige una política compatible con el recuento de hosts de tu clúster:

Fallas que se toleran	Esquema de ubicación de datos	Cantidad mínima de hosts
`FTT=1`	RAID-1 (duplicación) o RAID-5 (programación de borrado)	3 (se recomiendan 4 o más para volver a compilar después de una falla del host o durante el mantenimiento)
`FTT=2`	RAID-1 (duplicación)	5
`FTT=2`	RAID-6 (codificación de borrado)	6

Para establecer la política de almacenamiento predeterminada en el cliente de vSphere del vCenter Server del dominio de destino (vc01 o vc02), haz lo siguiente:

Desactiva la administración automática de políticas para el clúster de ESA de vSAN de modo que vSAN no reemplace tu política predeterminada personalizada.
Ve a Políticas y perfiles > Políticas de almacenamiento de VM > Crear, habilita las reglas de almacenamiento de vSAN y, en la sección Disponibilidad, selecciona Fallas que se tolerarán (por ejemplo, 1 falla: RAID-1 (duplicación) para 3 a 4 hosts o 2 fallas: RAID-6 (codificación de borrado) para 6 o más hosts).
Establece la política nueva como la predeterminada del almacén de datos: selecciona el almacén de datos de vSAN cl02, ve a Configurar > General > Política de almacenamiento predeterminada > Editar y selecciona la política nueva.
Aplica la política a las VMs existentes (Políticas de VM > Editar políticas de almacenamiento de VM). Ve a Supervisar > vSAN > Objetos virtuales para el clúster de cl02 y verifica el cumplimiento.

Soluciona problemas de creación de clústeres

En la siguiente tabla, se enumeran los problemas, las causas y las soluciones comunes cuando se agrega un clúster de vSphere a un dominio:

Problema	Causa	Solución
Falla la validación de conectividad de vSAN y vMotion; los hosts nuevos informan un estado incorrecto	Cuando creas o expandes un clúster, SDDC Manager asigna direcciones IP de `vmk1` y `vmk2` del grupo de red sin conservar el orden de los hosts.	Mantén habilitadas las validaciones. Crea un grupo de redes dedicado que coincida con las direcciones IP de la NIC de Compute Engine, verifica la alineación previa a la implementación y, si la tarea se detiene en la verificación de conectividad, alinea las NIC dinámicas y vuelve a intentar la tarea.
El estado del host de NSX es `Degraded` o los túneles están inactivos después de agregar el clúster	NSX Manager asigna direcciones IP de TEP (`vmk10`) del grupo de IP de forma aleatoria, por lo que es posible que no coincidan con la NIC de TEP de Compute Engine. Las subredes de NIC dinámicas no admiten DHCP.	Usa un grupo de IPs de TEP dedicado que coincida con las direcciones IP de TEP de Compute Engine y alinea las NIC dinámicas de TEP después de la preparación del host de NSX.
El agente o host de `NSX_VDL2` informa `Degraded` mientras la BFD está activa	Falta la dirección IP de la puerta de enlace en el grupo de IP de NSX TEP.	Configura la puerta de enlace de la subred (`192.168.4.1`) en el grupo de IP de TEP.
Error `IP_IN_USE` cuando se vuelve a agregar una NIC dinámica	Dos hosts intercambiaron direcciones IP o una dirección IP planificada se superpone con otro clúster.	Primero, borra todas las NIC dinámicas que no coincidan en todos los hosts antes de volver a agregar cualquier interfaz y verifica que tu plan de IP no se superponga con los clústeres existentes.
No se admite el modo de conmutador virtual de NSX	En VCF 9.x, el modo de conmutador virtual de NSX predeterminado es Enhanced Datapath Standard, que no es compatible con los hosts de la solución de VMware.	Borra Aplicar el modo de conmutador virtual predeterminado configurado en NSX Manager y establece el Modo operativo en Estándar (o `"hostSwitchOperationalMode": "STANDARD"` en la especificación de la API). Para obtener más información, consulta Modo de conmutador virtual de NSX.
Los hosts no pueden hacer ping a la puerta de enlace de la subred (`.1`)	Google Cloud no responde a las solicitudes de eco de ICMP en las direcciones IP de la puerta de enlace de la subred.	Comportamiento esperado; ignora las advertencias de ping de la puerta de enlace.
Configuración de la sincronización de hora (NTP)	Los hosts de equipos físicos usan el servidor de metadatos de Compute Engine para la sincronización de la hora.	Usa la dirección IP del servidor de metadatos (`169.254.169.254`) directamente como el servidor NTP.
La huella digital o el certificado del host muestran un nombre interno	El dominio de búsqueda de DNS no está configurado en el host o el nombre de host tiene un punto final.	Ejecuta el comando `esxcli network ip dns search add -d vmware.gve`, vuelve a ejecutar la secuencia de comandos `/var/lib/vmware/osdata/init.sh` y, luego, ejecuta el comando `/sbin/generate-certificates` y reinicia los servicios `rhttpproxy` y `hostd`.
Falla la puesta en marcha del host	El adaptador de VMkernel `vmk0` aún usa DHCP porque el servicio de inicio no lo convirtió.	Ejecuta el comando `esxcli network ip interface ipv4 get -i vmk0`. Si el tipo es `DHCP`, configúralo como estático de forma manual (por ejemplo, en `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`).
Errores de replicación de vSAN, tiempos de espera de vMotion o fragmentación de superposición de NSX	VCF establece de forma predeterminada los adaptadores de VDS y VMkernel, y los perfiles de NSX en una MTU de `9000` bytes, y la red de VPC descarta los marcos de más de `8896` bytes.	Configura una MTU de `8896` bytes en el VDS, el grupo de redes (vMotion y vSAN) y el perfil de vínculo de subida de NSX. Para obtener más información, consulta No coincidencia de MTU de VDS.
El asistente solicita un ID de VLAN para el grupo de puertos de superposición	El perfil de VDS predeterminado requiere el ID de VLAN de superposición del host de NSX.	Ingresa el ID de VLAN de TEP de tu configuración de NSX existente (`4` en esta guía).
No existe ningún grupo de puertos para las VMs de carga de trabajo en el clúster nuevo	El perfil de VDS predeterminado solo crea grupos de puertos de infraestructura.	Crea un grupo de puertos distribuidos para las VMs de carga de trabajo después de crear el clúster o usa una configuración de conmutador personalizada.
No se pueden agregar hosts con la imagen de vLCM seleccionada	La imagen de vLCM del clúster difiere de la compilación de ESXi instalada en los hosts.	Usa la misma familia de imágenes de ESXi que usan tus clústeres existentes o extrae la imagen de uno de los hosts nuevos.

¿Qué sigue?

Expande o compacta un clúster existente en Agrega o quita nodos en un clúster de vSphere.
Administra la capacidad de los nodos de equipos físicos en la consola de Google Cloud en Administra la capacidad de los nodos.
Revisa los lineamientos de tamaño y arquitectura del clúster en Acerca de los clústeres de vSphere.
Revisa las soluciones alternativas operativas y de implementación comunes en Problemas conocidos.
Obtén más información sobre las NIC dinámicas y las instancias de Bare Metal.