En este tema se describen las soluciones que se pueden aplicar para los errores comunes de comprobación previa de mantenimiento. Cuando las comprobaciones previas del sistema revelan condiciones que pueden bloquear la actividad de mantenimiento en un pod, los errores aparecen en Horizon Universal Console para poder realizar las acciones necesarias de cara a solucionarlos.

Importante: Si recibe notificaciones sobre errores de actualización del pod, debe realizar las acciones especificadas para solucionar los errores de manera oportuna. Actuar a tiempo es fundamental. Si no se puede actuar para solucionar estos errores en el tiempo que VMware requiere, el pod pasará a un estado no compatible debido a la imposibilidad de solucionar el proceso de actualización del pod.

Como se describe en Pods de Horizon Cloud: mantenimiento y actualizaciones, el sistema notifica las condiciones de bloqueo de mantenimiento que están bajo el control del usuario en el entorno de Microsoft Azure. Dado que la solución queda bajo el control del usuario y VMware no puede resolver el problema, si se recibe una notificación de errores de actualización en la consola o se recibe un correo electrónico de notificación acerca de dichos errores, es necesario completar las acciones para resolverlos y, a continuación, ponerse en contacto con el equipo de soporte de VMware para continuar con la actividad de mantenimiento.

Errores de bloqueo de actualización que normalmente se pueden producir

Estos son los errores de bloqueo de actualización que normalmente se pueden producir y que se pueden solucionar en el entorno de Microsoft Azure.

Las directivas de suscripción bloquean el uso de las ofertas de Azure Marketplace desde el editor de vmware-inc.
Como se describe en esta página de la documentación, a partir de principios del año 2022, el servicio mejoró el código de actualización para utilizar de forma programática ofertas de VMware que VMware proporciona en Azure Marketplace. Cuando las comprobaciones previas a la actualización determinan que se evita el uso programático de esas ofertas de VMware en la suscripción, debe completar las acciones que se describen en esa página de documentación para resolver los errores de bloqueo de actualización.
La suscripción no tiene suficientes núcleos (vCPU) o tamaños de máquina virtual adecuados disponibles para crear instancias de todas las máquinas virtuales para las máquinas virtuales que serán paralelas.
Cuando se crean los componentes verdes, para cada máquina virtual en el pod actual, se crea otra máquina virtual. De esta manera, la cantidad de máquinas virtuales del administrador de pods y máquinas virtuales de Unified Access Gateway se duplica desde el momento en que se crean los componentes verdes hasta que se produce la migración de los componentes azules a los verdes en el momento programado en la consola. Para admitir la creación de estas máquinas virtuales verdes, los niveles de cuota de la suscripción para núcleos (vCPU) de las familias de máquinas virtuales de Microsoft relevantes deben ser suficientes para alojar las máquinas virtuales que serán paralelas, junto con la cuota que ya se haya utilizado de la suscripción para sus pods asociados existentes. Consulte para conocer los núcleos necesarios para los distintos tipos de máquinas virtuales y sus usos.
El pod actualmente está fuera de línea o no puede comunicarse con Horizon Cloud.
En la página Capacidad, compruebe que el pod que se va a actualizar notifica que está en estado conectado. Inicie sesión en el portal de Microsoft Azure y compruebe si la máquina virtual del administrador de pods y sus máquinas virtuales Unified Access Gateway (si el pod tiene alguna) están en ejecución. Si una máquina virtual no está en ejecución, enciéndala. Para obtener más información sobre los grupos de recursos en los que se encuentran las máquinas virtuales, consulte Arrendatarios de first-gen: grupos de recursos creados para un pod implementado en Microsoft Azure.
El permiso para crear o eliminar grupos de recursos no está habilitado para esta suscripción de Microsoft Azure.
La comprobación previa del sistema valida que la entidad de servicio asociada con este pod tenga los permisos necesarios que requiere el servicio. Si el permiso para crear o eliminar grupos de recursos no está habilitado en la suscripción del pod, esa automatización se bloqueará. Para solucionar esta situación, siga el mensaje de guía de validación sobre cómo habilitar los permisos necesarios mediante el portal de Microsoft Azure. Para obtener más información sobre los permisos que el servicio requiere que tenga la entidad de servicio para realizar las operaciones requeridas por el servicio, lea Operaciones requeridas por Horizon Cloud en las suscripciones de Microsoft Azure.

Cuota y núcleos necesarios para el tiempo de implementación de las máquinas virtuales verdes cuando se completa la migración desde máquinas virtuales azules

Si se le notifica un error de actualización debido a la falta de núcleos disponibles, utilice la siguiente tabla para ver la cuota adicional que necesita. Para los diversos tipos de máquinas virtuales que se utilizan en el pod actual tal como está, la tabla del final de este tema describe la cuota que utilizan esos tipos, la cuota adicional necesaria cuando se crean las máquinas virtuales del pod verde y la cuota total necesaria para ejecutar las máquinas virtuales azules y verdes desde el momento en que se crean las máquinas virtuales verdes hasta que se completa la migración a la compilación verde. Para obtener detalles sobre los tipos y los núcleos de la familia de máquinas virtuales que se utilizan en un pod, consulte el tema de la documentación Requisitos de máquinas virtuales para un pod en la Guía de implementación.

Tipos de máquinas virtuales y sus núcleos Descripción Cuota total para la ejecución de máquinas virtuales azules y máquinas virtuales verdes hasta que se complete el cambio a verde
Tipo de máquina virtual Standard_D4_v3, 4 núcleos cada una
Nota: Si el tipo Standard_D4_v3 no está disponible en la región de Microsoft Azure en la que se implementa el pod, el pod normalmente utiliza el tipo de máquina virtual Standard_D3_v2. Ese tipo también utiliza 4 núcleos.
Este tipo de máquina virtual se utiliza para las máquinas virtuales del administrador de pods.
Para un pod con una sola máquina virtual de administrador
La cuota debe permitir los 4 núcleos de la máquina virtual del administrador (azul) existente, además de los 4 núcleos adicionales de la máquina virtual del administrador que será paralela. Ocho (8) núcleos para cubrir este uso.
Para un pod con alta disponibilidad habilitada, que tiene dos máquinas virtuales de administrador
La cuota debe permitir los 8 núcleos de las máquinas virtuales del administrador (azul) existente (2 máquinas virtuales de 4 núcleos cada una), además de los 8 núcleos adicionales de las máquinas virtuales del administrador que serán paralelas. Dieciséis (16) núcleos para cubrir este uso.
En función de lo que elija al implementar el pod:
  • Máquina virtual tipo Standard_A4_v2 (tiene 4 núcleos)
  • Standard_F8s_v2 (tiene 8 núcleos)
 Este tipo de máquina virtual se utiliza para las máquinas virtuales de Unified Access Gateway en las configuraciones de puerta de enlace del pod. La cantidad de núcleos que la suscripción debe admitir depende de los tipos de puerta de enlace configurados en el pod.
Para un pod con solo una puerta de enlace externa
Esa puerta de enlace externa tiene dos máquinas virtuales Unified Access Gateway, es decir, 2 máquinas virtuales multiplicadas por el número de núcleos que tiene cada una. Para el conjunto futuro, su cuota debe permitir la cantidad total de núcleos de las máquinas virtuales de Unified Access Gateway existentes (azules) más una cantidad de núcleos duplicados para las máquinas virtuales de Unified Access Gateway verdes en paralelo.
  • Por ejemplo, si las máquinas virtuales son del tipo Standard_A4_v2 con 4 núcleos cada una, se necesitan 2 por 4 por 2, es decir, 16 núcleos para cubrir este uso.
  • Si las máquinas virtuales son de un tamaño de máquina virtual con 8 núcleos, se necesitan 2 por 8 por 2, es decir, 32 núcleos para cubrir ese uso.
Para un pod con solo una puerta de enlace interna
Esa puerta de enlace tiene dos máquinas virtuales de Unified Access Gateway, es decir, 2 máquinas virtuales multiplicadas por la cantidad de núcleos que tiene cada una. Para el conjunto futuro, su cuota debe permitir la cantidad total de núcleos de las máquinas virtuales de Unified Access Gateway existentes (azules) más una cantidad de núcleos duplicados para las máquinas virtuales de Unified Access Gateway verdes en paralelo.
  • Por ejemplo, si las máquinas virtuales son del tipo Standard_A4_v2 con 4 núcleos cada una, se necesitan 2 por 4 por 2, es decir, 16 núcleos para cubrir este uso.
  • Si las máquinas virtuales son de un tamaño de máquina virtual con 8 núcleos, se necesitan 2 por 8 por 2, es decir, 32 núcleos para cubrir ese uso.
Para un pod con ambos tipos de puertas de enlace
Esa puerta de enlace tiene cuatro máquinas virtuales de Unified Access Gateway, es decir, 4 máquinas virtuales multiplicadas por la cantidad de núcleos que tiene cada una. Para el conjunto futuro, su cuota debe permitir 4 veces los núcleos de las máquinas virtuales de Unified Access Gateway existentes (azules) más una nueva multiplicación por dos para las máquinas virtuales de Unified Access Gateway verdes en paralelo.
  • Por ejemplo, si las máquinas virtuales son del tipo Standard_A4_v2 con 4 núcleos cada una, se necesitan 4 por 4 por 2, es decir, 32 núcleos para cubrir este uso.
  • Si las máquinas virtuales son de un tamaño de máquina virtual con 8 núcleos, se necesitan 4 por 8 por 2, es decir, 64 núcleos para cubrir ese uso.