Este servidor vCenter se acaba de actualizar a 5.1 actualización 1. Estoy revisando los hosts y actualizando el firmware, luego los actualizo de varias versiones de 5.0 a 5.1u1.
vCenter 5.1u1 parece tener un nuevo comportamiento interesante: está eliminando hosts del modo de mantenimiento cuando se vuelven a conectar después de desconectarse, pero de manera muy inconsistente, lo he visto tal vez 4 o 5 veces en ~ 25-30 reinicios de host. Solo lo he visto suceder en hosts 5.0 que aún no se han actualizado a 5.1.
En la imagen, puse el host en modo de mantenimiento y lo reinicié en el modo de actualización automática del DVD HP SPP. Después de su proceso habitual de actualización de ~ 40 minutos, el host volvió a estar en línea ... y 7 segundos antes incluso de registrar que el host se había vuelto a conectar, vCenter le había enviado una tarea para salir del modo de mantenimiento.
Según tengo entendido, el único momento en que vCenter debe dejar un host fuera del modo de mantenimiento es cuando vCenter lo pone en modo de mantenimiento (como una tarea de actualización de VUM).
¿Por qué este vCenter saldría unilateralmente de un host del modo de mantenimiento iniciado por el usuario?
Editar, información adicional:
Ejecuté las actualizaciones de firmware en 5 hosts más, todo al mismo tiempo. Dos de ellos salieron del modo de mantenimiento después de reconectarse, tres no. El factor común de quienes salen del modo de mantenimiento parece ser cuánto tiempo estuvieron fuera de línea ; los dos que tomaron algunos intentos para arrancar en los medios virtuales son los dos que quedaron fuera del modo de mantenimiento.
- esx31 (imagen de arriba): 45 minutos sin respuesta
- esx19 (mantenimiento de salida): 87 minutos sin respuesta
- esx24 (permaneció en mantenimiento): 32 minutos sin respuesta
- esx29 (permaneció en mantenimiento): 39 minutos sin respuesta
- esx32 (se mantuvo en mantenimiento): 30 minutos sin respuesta
- esx34 (maint salido): 70 minutos sin respuesta
Editar: La idea del tiempo de desconexión parece haber sido una pista falsa, ya que no está sucediendo constantemente.
Además , en el vpxd.logmodo de mantenimiento de salida, el inicio de la tarea parece seguir siempre inmediatamente esta vim.EnvironmentBrowser.queryProvisioningPolicyllamada SOAP. Aquí están las líneas, ligeramente recortadas para mayor claridad:
15:27:49.535 [info 'vpxdvpxdVmomi'] [ClientAdapterBase::InvokeOnSoap] Invoke done (esx31, vim.EnvironmentBrowser.queryProvisioningPolicy)
15:27:49.560 [info 'commonvpxLro'] [VpxLRO] -- BEGIN task -- esx31 -- HostSystem.exitMaintenanceMode --
Tenga en cuenta que en los nodos que no obtienen la tarea de salida, el vim.EnvironmentBrowser.queryProvisioningPolicyevento aún ocurre. No veo ninguna otra diferencia en los eventos antes o después de esto en el proceso de reconexión, aparte de los eventos adicionales causados por salir del modo de mantenimiento.
Dada la mención del registro de las políticas de aprovisionamiento, la búsqueda de problemas de modo de mantenimiento relacionados con la implementación automática genera quejas sobre un comportamiento similar (aunque no estoy usando la implementación automática en absoluto).
fuente
Respuestas:
He visto que esto sucede con los hosts ESXi 4.1 después de que un parche activara accidentalmente la carpeta / tmp / scratch. Es posible que desee verificar si ese directorio todavía existe en los hosts que salieron del modo de mantenimiento automáticamente.
Si faltan, querrás mkdir para crearlo. Además, querrá verificar si el scratch persistente está configurado correctamente en cada host siguiendo este artículo de VMware KB:
VMware KB: creación de una ubicación scratch persistente para ESXi 4.xy 5.x
fuente