VMware ESXi 6.x – Aislamiento de host

Iban Fernandez 18/06/2018

Os proponemos una solución exitosa para cuando sufrimos un aislamiento del host en nuestro clúster de VMware, y que, además, no requiere ningún tiempo de inactividad para las cargas de trabajo en ejecución (o el host en cuestión).

Escenario:

  • Después de un rescaneo de almacenamiento en el host o en el clúster, un host ESXi deja de responder en el vCenter aun teniendo VMs en ejecución (Aislamiento de host).
  • Los intentos de reconexión del host a través del vCenter, no funcionan.
  • La conexión directa del cliente (thick client) al host, no funciona.
  • Los intentos de ejecutar “services.sh” desde el CLI, hacen que el script se cuelgue después de “running sfcbd-watchdog stop".  Lo último que aparece en la pantalla es "Exclusive access granted".
  • El archivo /var/log/vmkernel.log muestra lo siguiente en este punto:

Archivo vmkernel.log:

2018-06-14T07:25:01.278Z cpu2:9424486)ALERT: hostd detected to be non-responsive

2018-06-14T07:25:10.758Z cpu10:7914294)NetPort: 1782: disabled port 0x200006c

Troubleshooting:

Los siguientes pasos para la resolución de problemas se obtuvieron del KB 1003409 de VMware.

  1. Verificar que el host esté encendido.
  2. Intentar reconectar el host en el vCenter
  3. Comprobar que el host ESXi es capaz de responder al vCenter con la dirección IP correcta y viceversa.
  4. Verificar que la conectividad de red existe desde el vCenter hasta la gestión del host ESXi IP o FQDN.
  5. Verificar que el puerto 903 TCP/UDP está abierto entre el vCenter y el host ESXi.
  6. Intentar reiniciar los agentes de gestión ESXi a través de DCUI o SSH para ver si resuelve el problema.
  7. Verificar si el proceso host ha dejado de responder en el host afectado.
  8. Verificar si el agente vpxa ha dejado de responder en el host afectado.
  9. Verificar si el host ha experimentado un PSOD (Pantallazo purpura).
  10. Verificar si hay un problema subyacente de conectividad de almacenamiento (u otro problema relacionado con el almacenamiento).

Siguiendo estos pasos de resolución de problemas, se suele quedar en el paso marcado en amarillo.

Resolución:

Estos son los pasos para solucionar el problema sin tener que apagar las VMs y reiniciar el host:

  1. Como el servicio hostd no responde, lo primero que hay que hacer es ejecutar “/etc/init.d/hostd restart” desde una segunda ventana de sesión SSH (dejando la primera con el proceso “services.sh restart” colgado).
  2. Mientras se ejecuta el comando de reinicio del servicio hostd, la sesión colgada se actualizará y mostrará lo siguiente: "Connect to localhost failed: Connection failure".
  3. Pulsar intro para regresar al intérprete de comandos de la shell.
  4. Ejecutar /etc/init.d/vpxa restart, que es el agente del vCenter en el host.
  5. Una vez completado, volvemos a ejecutar “services.sh restart” y esta vez debería ejecutarse sin problemas.
  6. Una vez se hayan reiniciados todos los servicios, volvemos al cliente vSphere y actualizamos la pantalla.  Ahora deberíamos ver que el host ha vuelto a ser administrado y que ya no está desconectado.

Recomendaciones:

  • Actualizar el firmware de la BIOS de los hosts.
  • Actualizar el firmware de las tarjetas de red de los hosts.
  • Desactivar ACK Retardado en el Host.
  • Actualizar el firmware de los switches.
  • Actualizar el firmware de las cabinas.