La corrección de hosts se ejecuta de diferentes formas en función de los tipos de líneas base que asocie a un objeto y de si el host corregido está en un clúster o no.
Corrección de actualización de hosts
Cuando se actualiza un host ESXi 6.5 o ESXi 6.7 a ESXi 7.0, todos los VIB personalizados compatibles permanecen intactos en el host después de la actualización, independientemente de si los VIB se encuentran o no incluidos en el archivo ISO del instalador.
Se pueden actualizar hosts mediante imágenes personalizadas de ESXi que contienen módulos de terceros para ESXi 7.0. En ese caso, los módulos de terceros que son compatibles con ESXi 7.0 permanecen disponibles en el host actualizado.
La actualización de hosts en una red de alta latencia donde vSphere Lifecycle 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 almacén de vSphere Lifecycle Manager antes de la actualización. Mientras esto ocurre, el host permanece en modo de mantenimiento.
vSphere Lifecycle Manager 7.0 admite la actualización de ESXi 6.5 y ESXi 6.7 a ESXi 7.0.
La actualización a ESXi 7.0 requiere un dispositivo de arranque de al menos 4 GB. Cuando se arranca desde un disco local, SAN o LUN iSCSI, se precisan hasta 128 GB de espacio de disco para crear particiones del sistema ESXi. Puede crear un almacén de datos de VMFS en un disco de arranque de más de 128 GB.
Corrección de revisiones de hosts
La aplicación de revisiones es el proceso de corrección de hosts ESXi en función de líneas base de revisión.
La corrección de hosts ESXi 6.5 y 6.7 a sus respectivas versiones de actualización de ESXi es un proceso de aplicación de revisiones, mientras que la corrección de hosts ESXi de la versión 6.5 o 6.7 a 7.0 es un proceso de actualización.
vSphere Lifecycle 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, vSphere Lifecycle Manager detecta el requisito previo del almacén 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 del almacén de vSphere Lifecycle Manager y no está en conflicto con el host, vSphere Lifecycle Manager informará de que existen conflictos con esta revisión después de una comprobación de cumplimiento. Puede aplicar la revisión en el host y realizar copias intermedias de ella.
- Cuando se seleccionan varias versiones de la misma revisión, vSphere Lifecycle Manager instala la más reciente y omite instalar las versiones anteriores.
Durante la corrección de revisiones, vSphere Lifecycle Manager instala automáticamente los requisitos previos de las revisiones.
Con vSphere Lifecycle Manager 7.0, puede corregir los hosts de la versión ESXi 6.5 y ESXi 6.7 en función de las revisiones de los paquetes sin conexión, los cuales se importan en el almacén de vSphere Lifecycle Manager de forma manual.
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, vSphere Lifecycle Manager no instala automáticamente los requisitos previos de la extensión. Si falta alguno de los requisitos previos de la extensión, las operaciones de corrección podrían fallar. 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 línea base de la extensión original.