Solución de problemas de una máquina virtual que dejó de responder

Metas
En este artículo, se proporcionan pasos para aislar las posibles causas por las que una máquina virtual de vSphere deja de responder.

Una máquina virtual que no responde no responde a ningún intento de conexión y es posible que no pueda responder a ningún intento de realizar un ciclo de apagado y encendido. Hay una variedad de razones por las que una máquina virtual puede terminar en un estado que no responde. Este artículo le permite identificar y resolver estas causas comunes y, cuando se resuelvan, devolver la máquina virtual a un estado operativo.

Es posible realizar un apagado forzado de una máquina virtual sin solucionar la causa, pero esto impedirá la recopilación y el análisis de información que podría ayudar a determinar la causa raíz de la interrupción. 

Hechos
Una máquina virtual que se ejecuta en VMware ESX/ESXi no responde a ninguna entrada externa ni muestra actividad. Específicamente:

• El SO huésped no responde a la actividad del teclado o el mouse en la consola

• El SO huésped no responde a la comunicación de red, incluidos ping, RDP, SSH, etc.

• La pantalla de la consola de máquina virtual es estática y no cambia ni actualiza

• Las tareas realizadas en la máquina virtual fallan, agotan el tiempo de espera o no se inician

• La máquina virtual no produce tráfico de red o disco

Solución
Los servicios que proporciona una máquina virtual pueden dejar de responder o ser inaccesibles debido a una serie de causas, incluidos problemas con las aplicaciones o el SO huésped dentro de la máquina virtual, problemas con el monitor o los dispositivos virtuales de la máquina virtual, contención de recursos en el host o problemas con la infraestructura subyacente de almacenamiento o redes.
Si el SO huésped está produciendo alguna actividad, se está ejecutando correctamente. En este caso, es probable que la falta de respuesta se deba a un problema de conectividad o a la contención de recursos, o sea específica de un componente de nivel superior, como una aplicación o un servicio que se ejecuta dentro del SO huésped.

Valide el alcance:
Es importante tener síntomas precisos y una comprensión del alcance de un problema. Para confirmar el alcance del problema, realice estas comprobaciones:

1. Confirme que la máquina virtual realmente no responda. Es posible que la máquina virtual no responda a través de una interfaz, pero funcione correctamente en otras. 

2. Verifique que la máquina virtual esté encendida. Si la máquina virtual se apagó inesperadamente, vuelva a encenderla y solucione la causa del apagado inesperado.

3. Determine si este problema afecta a varias máquinas virtuales o solo a una. Si varias máquinas virtuales se ven afectadas, tenga en cuenta las similitudes entre las máquinas virtuales afectadas cuando intente limitar el alcance potencial. En particular, enfóquese en la infraestructura compartida de la que depende el grupo de máquinas virtuales afectadas y si todas las máquinas virtuales que dependen de esa infraestructura común se ven afectadas. 

4. Determine si el SO huésped responde a la interacción en la consola de la máquina virtual. Si se aisló un problema al SO huésped o a las aplicaciones dentro de la máquina virtual y el SO huésped responde en la consola, interactúe con el SO huésped en la consola para solucionar el problema. 

5. Determine si el SO huésped o sus servicios de aplicaciones responden a la interacción a través de la red.

6. Determine si el SO huésped informó algún error crítico a la consola y se encuentra en un estado detenido.

7. Determine si el host ESX/ESXi tampoco responde. Si el host tampoco responde, el alcance es mayor de lo que se suponía inicialmente.

Identifique la causa:
En este punto, ha establecido que una o más máquinas virtuales no responden tanto en la consola virtual como a través de la red. El propio host responde. Puede existir un problema con la accesibilidad o la contención de recursos, o con la infraestructura subyacente de almacenamiento o redes.
Para identificar la causa:

1. Determine si el problema se desencadena por una operación o tarea que se realiza en la máquina virtual. Por ejemplo, las operaciones de instantánea y vMotion paralizan una máquina virtual durante breves períodos de tiempo mientras el estado de la memoria se copia a través de la red o al disco.

2. Algunos errores de configuración comunes pueden hacer que una máquina virtual deje de responder, por ejemplo, mientras se espera un recurso. Revise la máquina virtual y la configuración del host. 

3. Las máquinas virtuales dependen de una infraestructura de respaldo funcional. Si hay un problema con la infraestructura de red o almacenamiento de respaldo de la que depende la máquina virtual, el hardware virtual que una máquina virtual presenta al SO huésped puede verse afectado. Aborde el problema subyacente de almacenamiento o redes.

4. Las máquinas virtuales dependen de los recursos disponibles del host (CPU, memoria) y el SO huésped consume esos recursos. Un problema con la disponibilidad o la programación de recursos dentro o fuera de la máquina virtual puede hacer que deje de responder. También es posible que la máquina virtual bloquee los recursos no disponibles o que gire al 100 % de utilización de vCPU. 

Plan de acción:
En este punto, ha establecido que el host que ejecuta la(s) máquina(s) virtual(es) responde y no encuentra ningún problema de infraestructura de almacenamiento compartido o red. El SO huésped no ha fallado con un error crítico, pero sigue sin responder en la consola de la máquina virtual y a través de la red.
Tome medidas para recuperar o recolectar información sobre la máquina virtual que no responde en función de la capa arquitectónica sospechosa:

• Si un problema se aisló en el SO huésped o en el %RUN es relativamente alta, pero el monitor de la máquina virtual funciona correctamente. Traslade la investigación al sistema operativo o las aplicaciones invitados de la máquina virtual. Un SO huésped puede dejar de responder dentro de una máquina virtual de la misma manera que en el hardware físico:

  1. Recolecte datos de rendimiento mientras se produce el problema.

  2. Intente inducir manualmente un estado de alarma del kernel dentro del SO huésped para recopilar información adicional sobre su estado interno. Si el SO huésped produce información de diagnóstico útil en respuesta a uno de estos eventos, comuníquese con el proveedor del SO huésped para investigar más a fondo.

  3. Si el paso 2 no produce información útil, suspenda la máquina virtual para recopilar información sobre su estado interno y abra un caso con el soporte de VMware:

     1. Suspenda la máquina virtual y recopile el .vmss Suspender archivo de estado.

     2. Recopile registros del host que ejecuta la máquina virtual.

     3. Vuelva a encender la máquina virtual y restablézcala.

     4. Comuníquese con el soporte de VMware y proporcione la información recolectada en los pasos 1, 3a y 3b.

• Si un problema se aisló en el monitor de la máquina virtual o en el %WAIT es relativamente alta, o los intentos por suspender la máquina virtual han fallado, recolectar datos de rendimiento y bloquear forzosamente la máquina virtual para recopilar información adicional sobre su estado interno:

  1. Recolecte datos de rendimiento mientras se produce el problema.

  2. Bloquee la máquina virtual para recopilar información sobre su estado interno.

     NOTA: Si fallan los intentos de bloquear la máquina virtual, pase a la siguiente sección e intente bloquear el host.

  3. Comuníquese con el soporte de VMware y proporcione la información recolectada en los pasos 1 y 2.

• Si se aisló un problema en el monitor de la máquina virtual, pero los intentos de suspender o bloquear la máquina virtual fallan, esto refleja un problema con el VMkernel. Recolecte un paquete de registros del host, evacúe todas las máquinas virtuales no afectadas del host y use un NMI para generar intencionalmente una pantalla de diagnóstico púrpura:

  1. Recolecte datos de rendimiento mientras se produce el problema.

  2. Mueva todas las máquinas virtuales no afectadas fuera del host mediante vMotion. Si es posible, utilice el modo de mantenimiento para evitar que se inicien máquinas virtuales adicionales en el host.

  3. Configure el host para que entre en estado de alarma al recibir una interrupción no enmascarable y, a continuación, emita un NMI para activar un estado de alarma.

  4. Después de que el host genere una pantalla de diagnóstico púrpura y haya completado el volcado de información de diagnóstico, tome una captura de pantalla o una fotografía de la consola y reinicie el host.

  5. Recopile información de diagnóstico del host.

  6. Comuníquese con el soporte de VMware y proporcione la información recolectada en los pasos 1, 4 y 5.

Artículos
relacionados1007819 de la base de conocimientos de VMware: https://kb.vmware.com/kb/1007819