Las corrección de hosts se ejecuta de diferentes formas en función de los tipos de líneas base que se hayan asociado y de la presencia del host en un clúster.

Corrección de hosts de un clúster

Para los hosts ESXi de un clúster, el proceso de corrección se realiza secuencialmente de manera predeterminada. Con Update Manager, puede elegir ejecutar la corrección de hosts en paralelo.

Cuando se corrige un clúster de hosts de manera secuencial y uno de ellos no logra entrar en modo de mantenimiento, Update Manager notifica un error, y el proceso falla y se detiene. Los hosts del clúster que se corrigen permanecen en el nivel actualizado, mientras que los que no se corrigen después de la corrección del host con errores no se actualizan. Si el host de un clúster habilitado para DRS ejecuta una máquina virtual donde están instalados Update Manager o vCenter Server, DRS primero intenta migrar la máquina virtual que ejecuta vCenter Server o Update Manager en otro host, de modo que la corrección se lleva a cabo correctamente. En caso de que no se pueda migrar la máquina virtual a otro host, se produce un error en la corrección del host, pero el proceso no se detiene. Update Manager continúa con la corrección del próximo host del clúster.

La corrección de actualizaciones de hosts ESXi en un clúster solo continúa si todos los hosts del clúster pueden actualizarse.

La corrección de hosts en un clúster requiere que se deshabiliten temporalmente las funciones del clúster, como VMware DPM y el control de admisión de HA. También se debe desactivar FT si está habilitado en alguna de las máquinas virtuales de un host y desconectar los dispositivos extraíbles que estén conectados a las máquinas virtuales de un host, de modo que puedan migrarse con vMotion. Antes de iniciar un proceso de corrección, se puede generar un informe que incluya el clúster, el host o la máquina virtual en los que estén habilitadas las funciones de clúster. Para obtener más información, consulte Informe de comprobación previa a la corrección.

Nota: Cuando se realiza la corrección en un clúster compuesto por no más de dos hosts, es posible que deshabilitar el control de admisión de HA no sea suficiente para garantizar una corrección exitosa. Es posible que tenga que deshabilitar vSphere Availability (HA) en el clúster. Si mantiene HA habilitado, se producen errores en los intentos de corrección del host en el clúster, ya que HA no puede proporcionar la recomendación a Update Manager para colocar cualquiera de los hosts en modo de mantenimiento. La razón es que si uno de los dos hosts entra en modo de mantenimiento, no queda ningún host de conmutación por error disponible en el clúster. Para garantizar una corrección exitosa en un clúster de 2 nodos, deshabilite HA en el clúster o ponga los hosts en modo de mantenimiento manualmente y, a continuación, realice la corrección de los dos hosts en el clúster.

Al corregir un clúster de hosts en paralelo, Update Manager corrige varios hosts de manera simultánea. Durante una corrección en paralelo, si Update Manager encuentra un error al corregir el host, este se omite y el proceso de corrección continúa para los otros hosts del clúster. Update Manager evalúa continuamente la cantidad máxima de hosts que puede corregir de forma simultánea sin afectar la configuración de DRS. Puede limitar el número de hosts que se corrigen simultáneamente a una cantidad específica.

Update Manager corrige hosts que forman parte de un clúster de vSAN secuencialmente, incluso si selecciona la opción para corregirlos en paralelo. Esto se debe a que está diseñado para que solo un host de un clúster de vSAN puede estar en modo de mantenimiento en todo momento.

En el caso de varios clústeres en un centro de datos, los procesos de corrección se ejecutan en paralelo. Si se produce un error en el proceso de corrección de uno de los clústeres del centro de datos, los clústeres restantes se corrigen de todos modos.

Corrección con respecto a varias líneas base o grupos de líneas base

A partir de vCenter Server 6.7 Update 2, es posible seleccionar varias líneas base en lugar de agruparlas primero en un grupo de líneas base. Cuando se corrigen hosts con respecto a varias líneas base o grupos de líneas base que contienen una línea base de actualización y líneas base de revisión o extensión, la actualización se lleva a cabo en primer lugar.

Corrección de actualización de hosts

Cuando se actualiza un host ESXi 6.0 y ESXi6.5 a ESXi6.7, todos los VIB personalizados compatibles permanecen intactos en el host después de la actualización, independientemente de si los VIB están o no incluidos en el archivo ISO del instalador. Esto se debe a que los hosts ESXi 6.x son compatibles con binarios.

Se pueden actualizar hosts mediante imágenes personalizadas de ESXi que contienen módulos de terceros para ESXi6.7. En ese caso, los módulos de terceros que son compatibles con ESXi6.7 permanecen disponibles en el host actualizado.

La actualización de hosts en una red de alta latencia donde Update Manager y los hosts están en diferentes ubicaciones puede tardar varias horas, ya que el archivo de actualización se copia en el host desde el repositorio del servidor de Update Manager antes de la actualización. Mientras esto ocurre, el host permanece en modo de mantenimiento.

Update Manager 6.7 admite la actualización de ESXi 6.0.x y ESXi6.5.x a ESXi6.7.

Importante: Después de actualizar el host a ESXi 6.7, no podrá revertir el software a las versiones ESXi 6.0.x o ESXi 6.5.x. Realice una copia de seguridad de la configuración del host antes de realizar una actualización. Si ocurre un error en la actualización, puede reinstalar el software ESXi 6.0.x o ESXi 6.5.x desde el que realizó la actualización y restaurar la configuración del host. Para obtener más información sobre cómo realizar una copia de seguridad de la configuración de ESXi y restaurarla, consulte el tema Actualizar vSphere.

Corrección de revisiones de hosts

Update Manager controla las revisiones de hosts de las siguientes maneras:

  • Si la revisión de una línea base de revisión requiere la instalación de otra revisión, Update Manager detecta el requisito previo del repositorio de revisiones y lo instala junto con la revisión seleccionada.
  • Si una revisión entra en conflicto con otras revisiones instaladas en el host, es posible que no se realicen copias intermedias de la revisión en conflicto o que no se instale dicha revisión. Sin embargo, si otra revisión de la línea base resuelve el conflicto, la revisión en conflicto se instala. Por ejemplo, supongamos que una línea base contiene la revisión A y la revisión C, pero la revisión A entra en conflicto con la revisión B, que ya está instalada en el host. Si la revisión B se vuelve obsoleta debido a la revisión C, y esta última no está en conflicto con la revisión A, el proceso de corrección instala las revisiones A y C.
  • Si una revisión entra en conflicto con las revisiones en el repositorio de revisiones de Update Manager, pero no está en conflicto con el host, Update Manager informa que existen conflictos con esta revisión después de una examinación. Puede aplicar la revisión en el host y realizar copias intermedias de ella.
  • Cuando se seleccionan varias versiones de la misma revisión, Update Manager instala la más reciente y omite las versiones anteriores.

Durante la corrección de revisiones, Update Manager instala automáticamente los requisitos previos de las revisiones.

Con Update Manager6.7, se pueden corregir los hosts de las versiones ESXi 6.0 y ESXi6.5 con paquetes sin conexión que se hayan importado manualmente.

Antes de la corrección, puede realizar copias intermedias de las revisiones para reducir el tiempo de inactividad del host.

Corrección de extensiones de hosts

Durante la corrección de extensiones, Update Manager no instala automáticamente los requisitos previos de la extensión. Esto puede generar errores en algunas operaciones de corrección. Si el requisito previo que falta es una revisión, puede agregarlo a la línea base de la revisión. Si el requisito previo faltante es una extensión, puede agregarlo a la misma línea base de la extensión, o bien a otra. Puede corregir el host con las líneas base que contienen los requisitos previos y la extensión original.

Corrección de hosts ESXi con arranque PXE

Update Manager permite corregir los hosts ESXi con arranque PXE. Update Manager no aplica revisiones que requieren el reinicio de los hosts ESXi con arranque PXE.

Si hay otro software instalado en el host ESXi con arranque PXE, es posible que el software se pierda al reiniciar el host. Actualice el perfil de imagen con el software adicional para que este aparezca después del reinicio.