VMware: Actualizar desde vSphere ESXi 6.x a ESXi 6.7 Update 3b (ESXi670-201912001) usando el nuevo vSphere Update Manager (VUM)

Saludos amigos, hemos visto ya en el pasado cómo actualizar nuestros Hosts de ESXi de manera interactiva y uno a uno usando el online depot, muy útil y simple para uno o dos ESXi, pero impráctico para un entorno con cientos de ESXi, con lo que hoy os traigo un post con los pasos para actualizar los Hosts de ESXi usando el nuevo vSphere Update Manager que viene de manera embebida en el vSphere Client HTML5 de la 6.7 U2 y superior, ¡vamos allá!Detalles de la Build

Download Filename:	ESXi670-201912001.zip
Build:	15160138
Download Size:	473.7 MB
md5sum:	153ea9de288d1cc2518e747f3806f929
sha1checksum:	e9761a1a8148d13af8a920decd9d729658d59f1c
Host Reboot Required:	Yes
Virtual Machine Migration or Shutdown Required:	Yes

Novedades en vSphere ESXi 6.7 U3b

Muchas novedades trae el hypervisor, todas ellas en Inglés, aquí, algunas de las más relevantes:

• PR 2396958: DNS short name of ESXi hosts cannot be resolvedThe DNS short name of ESXi hosts cannot be resolved. You see an error similar to:
  nslookup <shortname>
** server can't find <shortname>: SERVFAIL
  Fully Qualified Domain Names (FQDN) resolve as expected.
• PR 2388157: vSAN permissions allow access to other datastoresThe +Host.Config.Storage permission is required to create a vSAN datastore by using vCenter Server. This permission provides access to other datastore, managed by the vCenter Server system, including the ability to unmount those datastores.
• PR 2423301: After you revert a virtual machine to a snapshot, change block tracking (CBT) data might be corrupted When reverting a virtual machine that has CBT enabled to a snapshot which is not a memory snapshot, and if you use the QueryChangedDiskAreas() API call, you might see an InvalidArgument error.This issue is resolved in this release. With ESXi670-201912001, the output of the QuerychangedDiskAreas () call changes to FileFault and adds the message Change tracking is not active on the disk <disk_path> to provide more details on the issue.
  With the fix, you must power on or reconfigure the virtual machine to enable CBT after reverting it to a snapshot and then take a snapshot to make a full backup.
  To reconfigure the virtual machine, you must complete the following steps:
  1. In the Managed Object Browser graphical interface, run ReconfigVM_Task by using an url such as https://<vc or host ip>/mob/?moid=<the virtual machine Managed Object ID>&method=reconfigure.
  2. In the <spec> tag, add <ChangeTrackingEnabled>true</ChangeTrackingEnabled>.
  3. Click Invoke Method.
• PR 2240272: If a two host vSAN cluster has a network partition, one or more vSAN objects might become inaccessibleOne or more vSAN objects might become temporarily inaccessible for about 30 seconds during a network partition on a two host vSAN cluster. A rare race condition which might occur when a preferred host goes down causes the problem.
• PR 2412159: With multi-vMotion vmknics configured, normal ping causes an error in vSAN health vMotion: Basic (unicast) connectivity checkA vSAN cluster that has multi-vMotion VMNICs configured might report a false alarm raised by vSAN health vMotion: Basic (unicast) connectivity check.
• PR 2412475: You see Sensor -1 type hardware health alarms on ESXi hosts and receive excessive mail alertsAfter upgrading to ESXi 6.7 Update 3, you might see Sensor -1 type hardware health alarms on ESXi hosts being triggered without an actual problem.If you have configured email notifications for hardware sensor state alarms in your vCenter Server system, this can result in excessive email alerts. These mails might cause storage issues in the vCenter Server database if the Stats, Events, Alarms, and Tasks (SEAT) directory goes above the 95% threshold.
• PR 2385716: Virtual machines with Changed Block Tracking (CBT) enabled might report long waiting times during snapshot creationVirtual machines with CBT enabled might report long waiting times during snapshot creation due to the 8 KB buffer used for CBT file copying. With this fix, the buffer size is increased to 1 MB to overcome multiple reads and writes of a large CBT file copy, and reduce waiting time.

Además de éstas, que son realmente importantes dependiendo de nuestro, entorno.

Adicionalmente, esta versión de ESXi ya contiene las últimas VMware Tools disponibles, v11.0.1  que traen muchas mejoras como son por ejemplos mejoras en VMXNET3 y mucho más.

A nivel de seguridad, incluye los siguientes bulletin, muchos de ellos de carácter importantes y uno crítico:

Bulletin ID	Categoría	Severidad
ESXi670-201912401-BG	Bugfix	Critical
ESXi670-201912402-BG	Bugfix	Important
ESXi670-201912403-BG	Bugfix	Important
ESXi670-201912404-BG	Bugfix	Important
ESXi670-201912405-BG	Bugfix	Important
ESXi670-201912101-SG	Security	Critical
ESXi670-201912102-SG	Security	Important

Configuración de baseline con el update de ESXi 6.7 U3b (ESXi670-201912001) en VUM

El primero paso es abrir nuestro flamante vSphere HTML5 client e irnos hasta Menu – Update Manager:Nos iremos hasta Updates y organizamos por 6.7 y luego por fecha y veremos lo siguiente:

Haremos click ahora, desde nuestro VCSA, en la pestaña de Updates, en Create and Attach a Baseline:Seleccionaremos un nombre para la misma y una breve descripción, además diremos que es de tipo Patch:

Seleccionaremos los criterios para buscar entre los cientos de parches que tenemos en Update Manager:

Seleccionaremos el parche que queremos aplicar, en este caso el llamado ESXI670-201912001:

Y si todo está correcto en el summary, haremos click en Finish:

Aplicando VUM ESXi baseline a un clúster y hacer remediate de los mismos (Upgrade de ESXi a 6.7 U3b, ESXi670-201912001)

Tener en cuenta que aplicar este baseline a los Hosts y remediarlos significa actualizarlos a la nueva versión, simplemente tenerlo en cuenta antes de seguir esos pasos.

Hay varias maneras de aplicar el baseline de ESXi, en mi caso me gusta hacerlo por Clúster, para ello nos iremos a nuestra vista de Hosts and Clusters, una vez en el Clúster, haremos click en Updates en el menú principal.

Una vez en esta vista, podremos ver Host Updates y haremos click en Attach para añadir nuestra baseline con la imagen de ESXi:

Seleccionaremos el upgrade que queremos, en mi caso puedo ver la descripción que seleccioné antes, vSphere ESXi 6.7 U3b:

Al aplicar la baseline, VUM no sabe aún si los Hosts cumplen o no con esta baseline, haremos click en Check compliance para saberlo, VUM nos mostrará que ninguno de los Hosts cumple con los requisitos del baseline, estar en 6.7 U3b:

Con lo que ahora, desde el submenú de Host Updates de nuevo, seleccionaremos la baseline y haremos click en REMEDIATE:

Y podremos ver como el proceso comienza a aplicar la actualización, el proceso es, hacer vMotion de las VMS a otro host, poner el host en modo mantenimiento, aplicar el Upgrade, reiniciar y sacarlo del modo mantenimiento, y así con todos:

Cuando termine, ya desde el propio VUM, podremos ver que todos nuestros Hosts están ahora en modo Compliant con nuestra baseline, además si nos vamos a cualquiera de los Hosts, podremos ver que ya tenemos el nuevo ESXi 6.7 U3b:

Eso es todo amigos, este modo es el modo profesional y que os recomiendo para realizar upgrades de ESXi 6.x a 6.7 U3b, gracias por la lectura.