Problemas conocidos
En esta página, se describen problemas conocidos con los que puedes encontrarte cuando usas Google Cloud VMware Engine.
Problemas generales
Los siguientes son problemas generales conocidos que afectan a VMware Engine.
Las alarmas de error de pNIC de vCenter integradas se activan en eventos de red transitorios
Problema: Las alarmas de infraestructura de vCenter integradas, como "Se detectó una tasa de errores de pNIC alta", se pueden activar de forma intermitente en la consola del cliente de vSphere debido a anomalías transitorias de paquetes localizados.
Detalles: El framework de alertas integrado de VMware evalúa los contadores de la tarjeta de interfaz de red física (pNIC) subyacente en ventanas de muestreo breves y rígidas. Debido a este diseño, vCenter puede activar alertas inmediatas para eventos rutinarios y sin impacto, como el ruido transitorio o el comportamiento esperado de pérdida de paquetes en los vínculos superiores de vSAN en espera, incluso cuando la capa de red está en buen estado. Debido a la redundancia de ruta integrada, estas alertas no afectan la disponibilidad del entorno ni la integridad de los datos.
Solución alternativa: No se requiere ninguna acción del cliente ni solución alternativa. Debido a que no se espera una actualización de la sensibilidad del muestreo de alarmas de vCenter integrado a corto plazo, Google implementó inteligencia de plataforma subyacente para administrar y filtrar estos falsos positivos. En los entornos de producción de destino, Google suprime estas alertas integradas de la consola orientadas al cliente. En su lugar, el motor de análisis de Google Analytics supervisa los datos de la infraestructura y evalúa la capa física de forma continua con un promedio móvil de 30 minutos. Si el motor de análisis de Google identifica una degradación física persistente, como un cable o una óptica defectuosos, la plataforma alerta automáticamente al equipo de Atención al Cliente de Google para que investigue y resuelva el problema, y te envía de forma sistemática una notificación automática.
Estado: Esta es una limitación conocida de la lógica de evaluación de alarmas integrada de vCenter. Google administra este comportamiento a través de la inteligencia de plataforma integrada y subyacente. VMware está al tanto de este problema y recomendó una solución alternativa.
La actualización de HCX Manager se etiquetó de forma incorrecta como actualización de la versión de vSphere
Problema: La actualización de HCX Manager se etiqueta de forma incorrecta como una "actualización de la versión de vSphere" en la consola de Google Cloud .
Detalles: Aunque se envían notificaciones por correo electrónico específicas que identifican la actualización de HCX al menos 14 días y 24 horas antes del evento, las notificaciones automáticas "Se inició la actualización de tu nube privada" y "Se completó la actualización de tu nube privada" reflejan una actualización general de la nube privada. Además, la interfaz de la consola deGoogle Cloud etiqueta de forma explícita la operación como una actualización de la versión de vSphere. Esta discrepancia puede causar confusión, en especial para los clientes que completaron recientemente una actualización de pila completa (por ejemplo, vSphere 7.x a 8.x), ya que parece que el entorno está experimentando otra actualización importante de la plataforma.
Solución alternativa: Revisa las notificaciones por correo electrónico específicas de HCX que se enviaron antes del período de mantenimiento para confirmar el alcance del trabajo. Si el programa se alinea, el estado "Actualización de la versión de vSphere" en la consola de Google Cloud se refiere estrictamente a la actualización de HCX Manager. No es necesario que realices ninguna acción.
Estado: Esta es una limitación conocida del diseño actual del sistema de notificaciones.
Tiempo de aprovisionamiento para las nubes privadas de vSphere 8.0, actualización 3
Problema: VMware Engine ahora implementa nubes privadas nuevas con la versión 8.0, actualización 3, de VMware vSphere y NSX-T 4.2.1.2. Durante este período de actualización, la creación y la expansión de nubes privadas usan velocidades de aprovisionamiento estándar para todas las implementaciones nuevas con las versiones actualizadas.
Detalles: La creación de la nube privada puede tardar hasta 140 minutos.
Solución alternativa: No se necesita ninguna solución alternativa, pero planifica un tiempo adicional cuando implementes nubes privadas nuevas o expandas los clústeres existentes.
Detección: Es posible que observes tiempos de implementación más largos de lo habitual para las nubes privadas nuevas o cuando expandes los clústeres existentes.
Estado: Este es el comportamiento esperado debido a las actualizaciones de versión y las actualizaciones en curso.
La máquina virtual con Windows Server 2022 KB5022842 (compilación del SO 20348.1547) configurada con el arranque seguro habilitado no se inicia (90947)
Después de instalar la actualización KB5022842 (compilación del SO 20348.1547) de Windows Server 2022, el SO invitado no puede iniciarse cuando las máquina virtual están configuradas con el inicio seguro habilitado. Para solucionar este problema, puedes realizar una de las siguientes acciones:
Hay un límite de 100 prefijos para los anuncios de ruta de tu nube privada a tu red de VPC.
Si tu anuncio de ruta supera este límite, es posible que se descarten algunos prefijos. Para mantenerte dentro de este límite, implementa la agregación en NSX-T Edge.
VMware Engine se basa en Cloud Routers para anunciar rangos de direcciones IP (prefijos o CIDR) desde NSX a una red de VPC del productor de servicios. Estos prefijos se convierten en rutas dinámicas personalizadas en la red de VPC del productor de servicios que intercambia tráfico con tu red de VPC.
Cuando configuras tu red de VPC para importar rutas dinámicas personalizadas en esta relación de intercambio de tráfico, los prefijos de NSX prefijan las rutas personalizadas de intercambio de tráfico en tu red de VPC. La cantidad de prefijos de NSX que puedes importar está limitada por dos factores:
- Límite predeterminado de Cloud Router para la cantidad de prefijos únicos por región, que hereda VMware Engine
- La cantidad máxima de rutas dinámicas de un grupo de intercambio de tráfico en tu red de VPC
Las operaciones de nube privada que se intentan realizar antes de que la nube privada se implemente por completo fallan
En el portal de Google Cloud VMware Engine, se permiten operaciones como la elevación de privilegios, la expansión de nubes privadas y el reemplazo de nodos en nubes privadas operativas que aún no se aprovisionaron por completo. Sin embargo, si intentas realizar estas operaciones en VMware Engine antes de que la nube privada se implemente por completo (incluidos NSX-T y HCX), estas operaciones fallarán. No lo intentes hasta que hayas implementado completamente tu nube privada.
VMware Engine aún no es totalmente compatible con los Controles del servicio de VPC
Los Controles del servicio de VPC implementan una solución temporal (solución alternativa) para permitirte seguir consumiendo VMware Engine desde un proyecto en un perímetro de Controles del servicio de VPC. Consulta Controles del servicio de VPC para obtener más información.
Interoperabilidad de Apigee con el enrutamiento de Internet local
Si usas Apigee con el intercambio de tráfico entre VPC en la misma red de VPC
que VMware Engine y configuras VMware Engine para enrutar
el tráfico de Internet a través de una conexión local, es posible que la comunicación saliente de Apigee
también se enrute a través de tu conexión local.
Esta configuración se produce cuando habilitas los Controles del servicio de VPC en el
intercambio de tráfico de servicenetworking.googleapis.com, como se describe en
Configura el acceso a Internet para las VMs de cargas de trabajo.
Si el tráfico de Apigee se enruta a través de tu conexión local, Apigee ya no usa su dirección IP externa configurada para la comunicación saliente con los servicios de backend de la API externos. Si dependes de la dirección IP externa de Apigee para las configuraciones de firewall, debes actualizar las configuraciones de firewall para permitir el tráfico desde tu red local.
Es posible que los hosts de ESXi pierdan la conectividad de forma temporal durante la recopilación de información de diagnóstico.
Los hosts de ESXi en entornos con dispositivos PCIe de NVMe podrían perder la conectividad de forma temporal durante la recopilación de información de diagnóstico.
Causa principal
Cuando usas el comando vm-support o la IU de vCenter para recopilar información sobre
los sistemas ESXi, los registros se almacenan de forma temporal en el directorio
ramdisk /tmp. Si el sistema tiene muchos dispositivos PCIe NVMe o el archivo de registro es grande,
el directorio ramdisk /tmp se llena con rapidez, lo que puede provocar que
el host ESXi pierda la conectividad de forma temporal hasta que se complete la recopilación de
vm-support.
Solución alternativa:
Excluir el manifiesto de NVME de la sección de registros seleccionados en la página de creación del paquete de registros evita que el directorio ramdisk /tmp se llene y verifica que el host de EXSi no pierda la conectividad de red. Para excluir el
manifiesto de NVMe, haz lo siguiente:
- Accede a vCenter con el nombre de usuario y la contraseña de
cloudowner. - En el inventario, haz clic con el botón derecho en la instancia de vCenter Server en la que deseas aplicar la exclusión.
- Haz clic en Exportar registros del sistema….
- Selecciona el host de ESXi del que deseas excluir el paquete de registros.
- En Seleccionar registros, desplázate hasta Almacenamiento y desmarca la opción NVMe. Luego, haz clic en Registros exportados. Ahora se excluye el manifiesto de NVMe.
Para obtener más información sobre esta corrección, consulta VMware ESXi 7.0 Update 3q.
Error de traducción del nombre del recurso de nube privada
Si ejecutas VMware Engine Horizon (VDI) en Google Cloud VMware Engine, es posible que encuentres errores después de cambiar el nombre de los recursos de tu nube privada para cumplir con los estándares de Google Cloud CLI y la API de VMware Engine.
El siguiente error de ejemplo se produce cuando se cambian los nombres de los recursos de la nube privada sin editar correctamente el aprovisionamiento de los grupos de escritorios de Horizon:
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No resource pool available for the pool: ic-pool-1
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No datastores available for the pool: {}ic-pool-1
Para resolver este problema, completa los siguientes pasos antes de la fecha programada para la traducción de nombres:
- Accede al panel de VMware Horizon.
- Edita todos los grupos de Horizon Desktop para los grupos de clonación completa y de clonación instantánea, y configúralos como Inhabilitar aprovisionamiento.
Una vez que se complete el cambio de nombre del recurso de nube privada, completa los siguientes pasos:
Edita cada grupo de escritorios y vuelve a establecer la siguiente configuración en la pestaña Configuración de vCenter para los grupos de clonación completa y clonación instantánea:
- Grupo de recursos
- Datastore
Vuelve a establecer el estado de cada grupo en Habilitar aprovisionamiento.
Prueba cada grupo agregando o quitando un escritorio del grupo para verificar que el aprovisionamiento funcione correctamente.
El equipo de VMware Engine está trabajando de forma activa para proporcionar una solución de interoperabilidad lo antes posible. Para mantenerte al tanto de la disponibilidad de las características, comunícate con el equipo de cuentas.