VMware: mantenimiento de hosts y máquinas virtuales en los clústeres de varias plantasVMware: host and virtual machine maintenance across several plants' clusters

Qué vas a conseguir

Mantener al día los clústeres de cada planta y de la sede central sin parar la producción: parches de ESXi y firmware aplicados host a host, máquinas virtuales con sus herramientas al día, sin snapshots olvidados ni datastores llenos, y cada intervención encajada en los turnos de la planta. En una planta, una parada de un servidor de MES o de etiquetado para la línea; el mantenimiento se planifica con producción, no solo con IT.

Antes de empezar

• Acceso a cada vCenter (uno central o uno por región) con un usuario nominal y permisos sobre Lifecycle Manager.
• El inventario por planta: hosts, modelo y fabricante del servidor, versión de ESXi y qué VM son críticas para la línea.
• La herramienta del fabricante para firmware y salud del hardware (por ejemplo, la integración de su consola de gestión con vCenter como hardware support manager).
• La capacidad de cada clúster para funcionar con un host menos (N+1). Si no la tiene, el mantenimiento obliga a apagar máquinas.
• El derecho a descargar parches: desde el cambio de licenciamiento de Broadcom, VMware vSphere se vende por suscripción por núcleo, y las descargas y actualizaciones dependen de tener el contrato activo para esos hosts. Compruébalo antes de planificar una ronda de parches.

1. vSphere Lifecycle Manager: imágenes, no líneas base

Con imágenes, cada clúster tiene una definición deseada: versión de ESXi, el vendor add-on del fabricante y, si está integrado, el firmware y drivers add-on. Lifecycle Manager compara cada host con esa imagen y lo corrige.

• Las líneas base (baselines) están en desuso desde vSphere 8 y no existen en vSphere 9: si un clúster sigue con ellas, planifica el paso a imagen en una ventana tranquila.
• La misma imagen para todos los clústeres del mismo hardware, aunque estén en países distintos. Se aprueba primero en un clúster de pruebas o en el de la sede central y después se extiende planta a planta.
• Run Pre-check antes de cada corrección: detecta VM que impedirán el modo mantenimiento, problemas de HA o de vSAN antes de abrir la ventana.

2. Modo mantenimiento con DRS

Con DRS en Fully Automated, poner un host en modo mantenimiento migra sus VM con vMotion a los demás hosts. Lifecycle Manager lo hace solo, host a host, durante la corrección.

• Si el clúster usa vSAN, elige la opción de migración de datos: Ensure accessibility para un mantenimiento corto, Full data migration si el host se va a retirar.
• El admission control de HA puede impedir entrar en mantenimiento si el clúster queda sin capacidad de reserva. No se desactiva para salir del paso sin entender qué deja de proteger.
• Las VM con reglas must run on un host concreto (licencias ligadas al host, por ejemplo) no se mueven: hay que apagarlas o cambiar la regla con el responsable de la aplicación.

3. VMware Tools, hardware virtual y snapshots

›Connect-VIServer vcenter01.contoso.local›Get-Cluster CL-PLANTA-01 | Get-VM | Select-Object Name, HardwareVersion, @{N='Tools';E={$_.ExtensionData.Guest.ToolsVersionStatus2}} | Sort-Object ToolsName            HardwareVersion  Tools----            ---------------  -----srv-p1-mes01    vmx-19           guestToolsNeedUpgradesrv-p1-lbl01    vmx-21           guestToolsCurrentsrv-p1-fs01     vmx-21           guestToolsCurrent›Get-Cluster CL-PLANTA-01 | Get-VM | Get-Snapshot | Where-Object { $_.Created -lt (Get-Date).AddDays(-3) } | Select-Object VM, Name, Created, @{N='SizeGB';E={[math]::Round($_.SizeGB,1)}}VM              Name                    Created              SizeGB--              ----                    -------              ------srv-p1-mes01    antes de actualizar MES 02/10/2026 21:14:05  148,3

• VMware Tools: se actualizan con la ventana de parches del sistema operativo invitado, porque pueden requerir reinicio. Las VM de proveedores industriales, solo con la versión que el proveedor soporta.
• Hardware virtual: subir la versión requiere apagar la VM. Se programa con Upgrade VM Compatibility en el siguiente reinicio del invitado, y no se sube por subir: solo si la versión de ESXi lo permite en todos los hosts a los que puede migrar la VM.
• Snapshots: no son copias de seguridad. Un snapshot de semanas crece sin parar, ralentiza la VM y puede llenar el datastore. Regla: ninguno con más de 72 horas sin un ticket que lo justifique, y revisión semanal de los que dejan las copias de seguridad sin consolidar.

4. Datastores, certificados y salud del hardware

• Capacidad: la alarma de uso de datastore por defecto avisa al 75 % y es crítica al 85 %. En una planta, un datastore lleno para todas las VM que escriben en él a la vez, línea incluida.
• Certificados: en Administration › Certificates › Certificate Management revisa la caducidad del certificado de máquina de vCenter y de los certificados de confianza; los de los hosts, en Configure › System › Certificate de cada host. Un certificado caducado puede dejar a los hosts desconectados de vCenter.
• Salud del hardware: Monitor › Hardware Health en cada host y la consola del fabricante para discos, fuentes y memoria. En las plantas, con polvo y temperatura, los ventiladores y las fuentes fallan antes que en un CPD.

5. El calendario coordinado con los turnos de planta

• Todas las horas en la hora local de la planta, y el cambio aprobado por el responsable de producción.
• Las paradas largas (verano, Navidad, paradas técnicas) se reservan para lo que obliga a apagar: firmware de cabina, cambio de versión mayor de ESXi o de vCenter.
• Una planta por ventana. Si algo sale mal, solo hay una planta afectada y el equipo puede centrarse en ella.

6. El ticket: "un host no entra en modo mantenimiento"

Sábado, 09:15, ventana de la Planta 01. La tarea Enter maintenance mode de esx-p1-03 lleva 20 minutos en el 2 %.

1. Qué VM quedan en el host y por qué no se mueven: la pestaña de DRS del clúster y los avisos de la tarea suelen decirlo.
2. Las causas típicas en planta:

›$vms = Get-VMHost esx-p1-03.contoso.local | Get-VM›$vms | Get-CDDrive | Where-Object { $_.IsoPath -or $_.HostDevice } | Select-Object Parent, IsoPath, HostDeviceParent          IsoPath                                  HostDevice------          -------                                  ----------srv-p1-scada01  [ds-local-esx03] iso/drivers-hmi.iso›$vms | Get-UsbDevice | Select-Object Parent, NameParent          Name------          ----srv-p1-lic01    USB 2.0 Licence Dongle

• Una ISO en un datastore local del host: la VM no puede migrar porque los demás hosts no ven ese disco. Se desconecta la unidad de CD.
• Un dispositivo USB conectado al host (llaves de licencia de software industrial, muy habituales): la VM no migra con vMotion. Se apaga con el responsable de la aplicación o se pasa la llave a un servidor USB en red.
• Una regla de afinidad must run on, una VM con disco en un datastore local o DRS en modo manual.
• Capacidad: el resto de hosts no puede absorber la carga sin violar el admission control de HA.

1. No fuerces apagados sin hablar con la planta: la VM de licencias puede parar a todos los puestos de ingeniería.
2. Cuando el host queda vacío, entra en mantenimiento y la corrección sigue. Anota la causa en el inventario para que el Pre-check de la próxima ventana la detecte antes.

Siguientes pasos

• La guía de VMware vSphere y vCenter del Nivel 3 cubre el clúster, HA, DRS y vMotion desde el principio.
• La de Veeam Backup explica por qué quedan snapshots tras una copia y cómo limpiarlos.
• La de Nutanix del Nivel 4 sirve si alguna planta usa otra plataforma de virtualización.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.