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.localGet-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 guestToolsCurrentGet-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
| Planta | Turnos | Ventana de mantenimiento | Qué se hace |
|---|---|---|---|
| Planta 01 | 3 turnos, lunes a viernes | Sábado 08:00-14:00 hora local | Lifecycle Manager host a host, Tools |
| Planta 02 | 24x7 | Parada programada mensual de la línea | Corrección, firmware, hardware virtual |
| Planta 03 | 2 turnos | Laborables 22:00-05:00 hora local | Host a host, sin tocar las VM de la línea |
| Sede central | Oficina | Martes 20:00-23:00 | Clúster de pruebas primero, con una semana de antelación |
- 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 %.
- 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.
- 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.
- No fuerces apagados sin hablar con la planta: la VM de licencias puede parar a todos los puestos de ingeniería.
- 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.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.
Apúntate y llévate las 33 ideas →