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

Problemas conocidos

En esta página, se enumeran los problemas conocidos y las soluciones alternativas para implementar y operar VMware Cloud Foundation (VCF) en VMware Solution en Google Cloud.

No coinciden las direcciones IP de vMotion y vSAN del host durante la implementación de VCF

Cuando implementas un dominio de administración de VCF, el instalador de VCF ordena el grupo de direcciones IP de vMotion y vSAN en orden numérico ascendente y asigna direcciones IP de forma secuencial a los hosts ESXi en el orden exacto en que aparecen en el array hostSpecs. Cuando creas un dominio de carga de trabajo de VI o expandes un clúster, SDDC Manager asigna direcciones IP de VMkernel de vMotion y vSAN desde el grupo de direcciones IP configurado sin conservar el orden de los hosts de hostSpecs.

Debido a que las redes de VPC de Google Cloud aplican verificaciones estrictas de IP de origen y destino en las NIC dinámicas de cada nodo de equipos físicos, la dirección IP que VCF asigna al adaptador vmk1 (vMotion) o vmk2 (vSAN) de un host debe coincidir con la dirección IP configurada en la NIC dinámica de Compute Engine correspondiente (nic0.VLAN_ID). Si la dirección IP de la NIC dinámica de un host no coincide con la dirección IP del entorno de ejecución asignada por VCF, el hipervisor recibe o transmite tráfico con una dirección IP que no coincide, y la validación de red o la implementación del clúster fallan.

Por ejemplo, considera una implementación de dominio de administración de cuatro hosts con las siguientes asignaciones de NIC dinámicas de Compute Engine:

FQDN del host	IP de vMotion (`vmk1`)	IP de vSAN (`vmk2`)	IP de NSX-TEP (`vmk10`)
`esxi-h0.40-vmware.gve`	`10.40.2.2`	`10.40.3.2`	`10.40.4.2`
`esxi-h1.40-vmware.gve`	`10.40.2.5`	`10.40.3.5`	`10.40.4.5`
`esxi-h2.40-vmware.gve`	`10.40.2.3`	`10.40.3.3`	`10.40.4.3`
`esxi-h3.40-vmware.gve`	`10.40.2.4`	`10.40.3.4`	`10.40.4.4`

Si los hosts se ordenan en la configuración de entrada como esxi-h0, esxi-h2, esxi-h1, esxi-h3, el instalador de VCF ordena el grupo (10.40.2.2, 10.40.2.3, 10.40.2.4, 10.40.2.5) y asigna las direcciones de forma secuencial a esxi-h0, esxi-h2, esxi-h1 y esxi-h3. El host esxi-h1 recibe 10.40.2.4 del instalador, aunque su NIC dinámica de Compute Engine subyacente espera 10.40.2.5.

Solución alternativa: Usa cualquiera de las siguientes opciones según si implementas un dominio de administración nuevo o expandes un dominio o clúster de carga de trabajo existente.

Opción 1: Especificaciones de host preordenadas para la implementación del dominio de administración

Cuando usas el kit de herramientas de VMware (self-managed-vmware-solution-toolkit), este consulta automáticamente las direcciones IP de NIC dinámicas de tus nodos de equipos físicos y ordena los arrays hostSpecs y includeIpAddressRanges en tu archivo JSON de implementación de VCF.

Si creas o modificas el archivo JSON de implementación de VCF de forma manual, alinea el orden de las entradas en el array hostSpecs para que coincida con el orden numérico ascendente de las direcciones IP de NIC dinámicas asignadas (para el ejemplo anterior: 10.40.2.2 para esxi-h0.40-vmware.gve, 10.40.2.3 para esxi-h2.40-vmware.gve, 10.40.2.4 para esxi-h3.40-vmware.gve y 10.40.2.5 para esxi-h1.40-vmware.gve):

Configura el grupo de direcciones IP: Según si tus asignaciones de IP son contiguas, especifica el grupo con rangos continuos o direcciones IP explícitas:

Rangos de IP continuos:

"includeIpAddressRanges": [
  {
    "startIpAddress": "10.40.2.2",
    "endIpAddress": "10.40.2.5"
  }
]

Direcciones IP no continuas:

"includeIpAddress": [
  "10.40.2.2",
  "10.40.2.3",
  "10.40.2.4",
  "10.40.2.5"
]

Ordena previamente el array hostSpecs para que los hosts aparezcan en orden ascendente según sus direcciones IP asignadas:

"hostSpecs": [
  {
    "hostname": "esxi-h0.40-vmware.gve"
  },
  {
    "hostname": "esxi-h2.40-vmware.gve"
  },
  {
    "hostname": "esxi-h3.40-vmware.gve"
  },
  {
    "hostname": "esxi-h1.40-vmware.gve"
  }
]

Opción 2: Vuelve a configurar las NIC dinámicas durante la expansión del dominio o clúster de carga de trabajo

Cuando implementas un dominio de carga de trabajo de VI o expandes un clúster con SDDC Manager, concilia las NIC dinámicas de vMotion y vSAN con las direcciones IP de entorno de ejecución que asigna VCF:

Poner en marcha los hosts de ESXi de equipos físicos en SDDC Manager y vCenter Server, y comenzar el flujo de trabajo de creación de clústeres o dominios de carga de trabajo Permite que el flujo de trabajo se detenga o falle en la etapa de verificación de conectividad de vSAN y vMotion.
Recupera las direcciones IP del entorno de ejecución asignadas por VCF con la base de datos de SDDC Manager o la API de REST de SDDC Manager (o inspecciona los adaptadores de VMkernel en el cliente de vSphere):
- Consulta de la base de datos de VCF (se ejecuta en el dispositivo de SDDC Manager):
```
psql -h localhost -U postgres -d platform -c "select * from host;"
```
- API de REST de SDDC Manager:
```
curl -u ADMIN_USER:ADMIN_PASSWORD \
   -X GET https://SDDC_MANAGER_FQDN/v1/hosts
```
  Antes de ejecutar el comando curl, reemplaza lo siguiente:
  - ADMIN_USER: Es el nombre de usuario del administrador de SDDC Manager.
  - ADMIN_PASSWORD: Es la contraseña de administrador de SDDC Manager.
  - SDDC_MANAGER_FQDN: Es el nombre de dominio completamente calificado o la dirección IP de tu dispositivo de SDDC Manager.
Primero, borra la NIC dinámica que no coincide (nic0.VLAN_ID) en todos los hosts ESXi afectados. Debes completar todas las eliminaciones de NIC dinámicas en todos los hosts antes de volver a agregar cualquier interfaz; de lo contrario, Compute Engine rechazará la adición de la interfaz con un conflicto de dirección IP si otro host aún tiene la dirección IP de destino:
```
gcloud compute instances network-interfaces delete HOST_INSTANCE_NAME \
   --zone=ZONE \
   --network-interface=nic0.VLAN_ID \
   --project=PROJECT_ID
```
Después de borrar todas las NIC dinámicas que no coinciden en todos los hosts, vuelve a agregar la NIC dinámica (nic0.VLAN_ID) en cada host con la dirección IPv4 exacta asignada por VCF.

Nota: La marca --private-network-ip acepta una dirección IPv4 o el nombre de un recurso de dirección IP interna reservada. Si usas direcciones IP reservadas, especifica la dirección IP reservada existente que coincida con la dirección IP asignada por VCF, que se reservó originalmente para otro host. No borres ni vuelvas a crear tus recursos de direcciones IP internas reservadas.
```
gcloud compute instances network-interfaces add HOST_INSTANCE_NAME \
   --zone=ZONE \
   --parent-nic-name=nic0 \
   --vlan=VLAN_ID \
   --subnetwork=SUBNET_NAME \
   --no-address \
   --private-network-ip=VMWARE_ASSIGNED_IP \
   --project=PROJECT_ID
```
Antes de ejecutar los comandos anteriores, reemplaza lo siguiente:
- HOST_INSTANCE_NAME: Es el nombre de la instancia de ESXi de equipos físicos en Compute Engine.
- ZONE: Es la zona en la que reside la instancia de Bare Metal.
- VLAN_ID: Es el ID de VLAN asignado a la NIC dinámica (por ejemplo, 2 para vSAN o 3 para vMotion), que forma el nombre de la interfaz nic0.VLAN_ID.
- SUBNET_NAME: el nombre de la subred vSAN o vMotion.
- VMWARE_ASSIGNED_IP: Es la dirección IPv4 o el nombre del recurso de dirección IP interna reservada existente que coincide con la dirección IP asignada al adaptador de VMkernel del host por VCF.
- PROJECT_ID: Es el ID de tu proyecto de Google Cloud .
Reanuda y completa la tarea de implementación del clúster en SDDC Manager.

No coincide la dirección IP de NSX-TEP en los hosts

Durante la preparación del nodo de transporte de NSX, NSX Manager asigna direcciones IP de extremo de transporte (TEP) (vmk10 o vmk3) del grupo de IP de NSX configurado (DHCP no se admite en las subredes de VPC de Google Cloud para las NIC dinámicas). Debido a que NSX Manager asigna direcciones IP del grupo de forma aleatoria, es posible que la dirección IP de TEP configurada en el adaptador vmk10 de un host ESXi no coincida con la dirección IP preasignada inicialmente en la NIC dinámica (nic0.TEP_VLAN_ID) del host NSX-TEP.

Solución alternativa: Después de que se complete la configuración del nodo de transporte de NSX, actualiza las NIC dinámicas de NSX-TEP en tus hosts para que coincidan con las direcciones IP de TEP asignadas por NSX:

Inspecciona la dirección IP de TEP asignada a cada host de ESXi en la IU de NSX Manager (ve a Sistema > Tejido > Hosts en VCF 9.1) o en el cliente de vSphere.

Quita todas las instancias de host de equipos físicos del grupo de extremos de red (NEG) de NSX antes de modificar las interfaces de red de NSX-TEP:

gcloud compute network-endpoint-groups update NSX_NEG_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --remove-endpoint="instance=HOST_INSTANCE_NAME"

Primero, borra la NIC dinámica NSX-TEP (nic0.TEP_VLAN_ID) en todos los hosts afectados. Completa todas las eliminaciones de NIC dinámicas de NSX-TEP en todos los hosts antes de volver a agregar interfaces para evitar conflictos de direcciones IP entre hosts:
```
gcloud compute instances network-interfaces delete HOST_INSTANCE_NAME \
    --zone=ZONE \
    --network-interface=nic0.TEP_VLAN_ID \
    --project=PROJECT_ID
```
Después de que se borren todas las NIC dinámicas de NSX-TEP en todos los hosts, vuelve a crear la interfaz nic0.TEP_VLAN_ID en cada host con la dirección IPv4 de TEP asignada por NSX Manager.

Nota: La marca --private-network-ip acepta una dirección IPv4 o el nombre de un recurso de dirección IP interna reservada. Si usas direcciones IP reservadas, especifica la dirección IP reservada existente que coincida con la dirección IP de TEP asignada por NSX, que se reservó originalmente para otro host. No borres ni vuelvas a crear tus recursos de direcciones IP internas reservadas.
```
gcloud compute instances network-interfaces add HOST_INSTANCE_NAME \
    --zone=ZONE \
    --parent-nic-name=nic0 \
    --vlan=TEP_VLAN_ID \
    --subnetwork=TEP_SUBNET_NAME \
    --no-address \
    --private-network-ip=TEP_IP_ADDRESS \
    --project=PROJECT_ID
```

Vuelve a conectar todas las instancias de host de Bare Metal al NEG de NSX:

gcloud compute network-endpoint-groups update NSX_NEG_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --add-endpoint="instance=HOST_INSTANCE_NAME"

Antes de ejecutar los comandos anteriores, reemplaza lo siguiente:

NSX_NEG_NAME: el nombre de tu NEG zonal de NSX.
HOST_INSTANCE_NAME: Es el nombre de la instancia de ESXi de equipos físicos.
ZONE: Es la zona en la que reside la instancia de Bare Metal.
TEP_VLAN_ID: Es el ID de VLAN asignado a la NIC dinámica NSX-TEP (por ejemplo, 4), que forma el nombre de la interfaz nic0.TEP_VLAN_ID.
TEP_SUBNET_NAME: el nombre de tu subred de NSX-TEP.
TEP_IP_ADDRESS: Es la dirección IPv4 de TEP o el nombre del recurso de dirección IP interna reservada existente que coincide con la dirección IP asignada al host de ESXi (vmk10) por NSX Manager.
PROJECT_ID: Es el ID de tu proyecto de Google Cloud .

No coincide la MTU de VDS con los marcos jumbo de la VPC de Google Cloud

Google Cloud Las redes de VPC admiten una unidad de transmisión máxima (MTU) de hasta 8896 bytes para marcos jumbo. De forma predeterminada, VCF configura los switches distribuidos de vSphere (VDS), los adaptadores de VMkernel (vSAN, vMotion y NSX-TEP) y los perfiles de nodo de transporte de NSX con una MTU de 9000 bytes. Si un host envía paquetes de más de 8896 bytes a través de la infraestructura de VPC, la red de VPC descarta las tramas de gran tamaño, lo que causa errores de replicación de vSAN, tiempos de espera de vMotion o problemas de fragmentación de la superposición de NSX.

Solución alternativa: Configura la MTU en 8896 bytes en la especificación de implementación de VCF antes de la puesta en marcha o actualiza la configuración de la MTU en vCenter Server y NSX Manager después de la implementación:

Actualiza la MTU del VDS en el cliente de vSphere

En el cliente de vSphere, ve a Herramientas de redes y selecciona el switch distribuido de vSphere para tu clúster.
Haz clic con el botón derecho en el switch distribuido y selecciona Configuración > Editar configuración.
Haz clic en la pestaña Avanzada, configura MTU (Bytes) como 8896 y haz clic en Aceptar.

Actualiza los adaptadores de VMkernel y los perfiles de NSX

Para cada host de ESXi en el clúster, ve a Configurar > Herramientas de redes > Adaptadores de VMkernel, edita los adaptadores vMotion (vmk1) y vSAN (vmk2) y establece la MTU en 8896.
En la IU de NSX Manager, ve a Sistema > Estructura > Perfiles > Perfiles de vínculo ascendente, edita los perfiles de vínculo ascendente de host y perímetro activos, y establece MTU en 8896 (y establece la MTU de la estructura física global en Sistema > Estructura > Configuración > Configuración de estructura global en 8896).

Modo de conmutador virtual de NSX

En VCF 9.x, el modo de conmutador virtual predeterminado configurado en NSX Manager se establece en Ruta de datos mejorada estándar, que no se admite en los hosts de VMware Solution.

Solución alternativa: En la sección NSX del instalador de VCF, desmarca la casilla de verificación Apply the default virtual switch mode configured in NSX Manager y, en Operational Mode, selecciona Standard, como se muestra en la siguiente captura de pantalla (haz clic para ampliar):

Configuración de NSX que muestra la casilla de verificación del modo de conmutador virtual predeterminado desmarcada y el modo operativo establecido en Estándar.

Falla de resolución de DNS con el reenvío entrante de Cloud DNS en subredes de transmisión de capa 2

Cuando habilitas una política de servidor de entrada de Cloud DNS en la red de VPC que aloja tus nodos de VMware Engine, Cloud DNS reserva automáticamente una dirección IP interna DNS_RESOLVER en cada subred regional de la red de VPC. Esto incluye la subred de administración de ESXi sin etiquetar (MGMT) y las subredes de NIC dinámicas con etiquetado de VLAN (vSAN, vMotion y NSX-TEP) que usan la transmisión del protocolo de resolución de direcciones (ARP) de capa 2 y el aprendizaje de MAC personalizado (ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING).

Si configuras hosts ESXi o dispositivos de administración de VCF para consultar una dirección IP de DNS_RESOLVER desde la misma subred o desde cualquier subred de nodo habilitada para la transmisión de ARP y el aprendizaje de MAC, el host trata la dirección IP del reenviador como un vecino local de capa 2 y envía solicitudes de transmisión de ARP para resolver su dirección MAC. Debido a que el agente de reenvío entrante de Cloud DNS es un servicio de proxy deGoogle Cloud en lugar de un extremo de capa 2 en la subred, no responde a las solicitudes de ARP ni participa en el aprendizaje de MAC personalizado. Como resultado, la entrada de vecino permanece incompleta (esxcli network ip neighbor list) y las consultas de DNS (nslookup) se agotan.

El mismo comportamiento se aplica a los extremos de Private Service Connect (PSC) (GCE_ENDPOINT), como el extremo que se usa para conectarse al depósito regional sin conexión. Si implementas un extremo de Private Service Connect en una subred de nodo con etiquetado de VLAN o transmisión de ARP de capa 2, la resolución de ARP para la dirección IP del extremo falla y las conexiones al depósito sin conexión se agotan.

Solución alternativa: Usa una subred estándar existente (que no sea de VLAN ni de transmisión de capa 2) en la misma región y red de VPC, o crea una subred estándar dedicada si aún no existe una, para tu dirección IP de entrada de Cloud DNS DNS_RESOLVER (y para tu extremo de depósito sin conexión de Private Service Connect). Si ya existe una subred estándar en la región, Cloud DNS ya asignó una dirección IP DNS_RESOLVER en esa subred que puedes usar:

Si aún no existe una subred estándar en la misma región y red de VPC, crea una subred estándar dedicada sin especificar la marca --resolve-subnet-mask. No conectes esta subred a las interfaces principales del nodo ni a las NIC dinámicas con etiquetado de VLAN:
```
gcloud compute networks subnets create DNS_SUBNET_NAME \
    --network=VPC_NAME \
    --region=REGION \
    --range=DNS_SUBNET_RANGE \
    --project=PROJECT_ID
```
Recupera la dirección IP de DNS_RESOLVER reservada por Cloud DNS en la subred estándar:
```
gcloud compute addresses list \
    --filter="purpose=DNS_RESOLVER AND subnetwork:DNS_SUBNET_NAME" \
    --project=PROJECT_ID
```
Antes de ejecutar los comandos anteriores, reemplaza lo siguiente:
- DNS_SUBNET_NAME: Es el nombre de la subred estándar existente o dedicada para el reenvío entrante de Cloud DNS.
- VPC_NAME: Es el nombre de tu red de VPC.
- REGION: Es la región de Google Cloud en la que residen tus nodos de equipos físicos.
- DNS_SUBNET_RANGE: Es un rango CIDR IPv4 principal que no se superpone para la subred estándar dedicada (por ejemplo, 10.0.100.0/28).
- PROJECT_ID: Es el ID de tu proyecto de Google Cloud.
Configura tus hosts de ESXi, los dispositivos de administración de VCF y el kit de herramientas de VMware (dns_server en config.json) para usar la dirección IP de DNS_RESOLVER de DNS_SUBNET_NAME en lugar de las direcciones IP de DNS_RESOLVER asociadas con las subredes de administración de ESXi (MGMT), vSAN, vMotion o NSX-TEP.