Techtip: parar/suspender máquinas virtuales colgadas bajo VMware VSphere
En varias ocasiones es posible que se os haya colgado una máquina virtual bajo VSphere, y no hay ninguna manera de conseguir parar ó suspender la máquina virtual que se quedó colgada a través de la consola de cliente.
Puede ser el caso de que ocurra cuando estemos realizando ó consolidando un snapshot, o que al haber contención en el servidor (sobrecarga de consumo de memoria, procesador, acceso a disco, red…) las máquinas dejen de responder a través de la consola de cliente.
No os agostéis demasiado, siempre hay varias opciones:
- Correr a actualizar rápidamente el currículum a la página de InfoJobs…
- Quedarse atónito ante la consola de cliente, a la espera de que pase algo.
- Reiniciar en frío/caliente el servidor físico donde se aloja la máquina virtual.
- Intentar parar/suspender la máquina virtual vía SSH contra el servidor VSphere ESX/ESXi.
Sí, claro: la mejor opción es la última y de paso conservar el puesto de trabajo. Así que tenemos varias vías para conseguir que nuesta máquina virtual rebelde responda a nuestros designios.
::::Atención:::: si lo que os interesa es parar la máquina deprisa, corriendo y sin piedad, podéis saltar al último punto del artículo (0 +d). Para los pacientes y prudentes, mejor seguir el artículo tal cual (de 0 a d, junto con el Epílogo).
0) Listar las máquinas virtuales en ejecución desde línea de comandos
a) Intentar suspender la máquina virtual desde línea de comandos
b) Forzar la suspensión de la máquina virtual desde línea de comandos
c) Intentar parar la máquina virtual desde línea de comandos
d) Forzar la parada de la máquina virtual desde línea de comandos
Epílogo: Socorro! No funciona!
0) Listar las máquinas virtuales en ejecución desde línea de comandos
Una vez conectados por SSH al servidor en cuestión, consultaremos primero qué máquinas virtuales están en ejecución sobre el servidor ESX/ESXi. Para ello usaremos el comando vm-support.
::::Nota:::: Por lo que he visto, en los servidores ESX, el identificador de la máquina viene etiquetado como vmid, mientras que en los servidores ESXi, el identificador de la máquina viene etiquetado como wid
~ # vm-support -x VMware ESX Support Script 1.33 Available worlds to debug: wid=676864 vm.virtual.1 wid=1296980 vm.virtual.2 wid=1216967 vm.virtual.3 wid=1234567 vm.datarecovery
Nos será de utilidad conocer los identificadores asociados a las máquinas virtuales que estén en ejecución, pues puede que los necesitemos más adelante.
a) Intentar suspender la máquina virtual desde línea de comandos
Una vez visto que la máquina rebelde sigue en ejecución gracias al comando anterior, intentaremos suspenderla (en algunos casos, suele ser suficiente para poder retomar el control de la máquina más tarde).
El comando que utilizaremos en el mejor de los casos es vmware-cmd, especificando junto a él la ruta completa donde esté ubicado el archivo de configuración .vmx de la máquina virtual, y el comando a ejecutar (en este caso, suspend con el parámetro soft/trysoft).
Antes y después de lanzar el comando, controlaremos el estado de la máquina virtual con el comando getstate.
~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx getstate getstate() = on ~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx suspend trysoft [...esperamos un tiempo prudencial...] ~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx getstate getstate() = suspended
En el caso de que esto no funcione, podemos intentar lanzar el comando algo más agresivamente:
~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx getstate getstate() = on ~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx suspend hard [...esperamos un tiempo prudencial...] ~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx getstate getstate() = suspended
Si esto no funcionó, pasemos al siguiente punto.
b) Forzar la suspensión de la máquina virtual desde línea de comandos
Ya intentado el punto anterior, tendremos que lanzarnos a usar el comando vm-support junto con el vmid/wid que obtuvimos al principio:
~]# vm-support -Z 1234567 VMware ESX Support Script 1.30 Can I include a screenshot of the VM 1234567? [y/n]: y Preparing files: / Grabbing data & core files for world 1234567. This will take 5 - 10 minutes. Taking performance snapshots. This will take about 300 seconds. [...] Creating tar archive ... File: '/root/esx-2010-09-27--15.04.6179.tgz' NOTE: esx-2010-09-27--15.04.6179.tgz is greater than 20 MB. Please do not attach this file when submitting an incident report. Please contact VMware support for an ftp site. To file a support incident, go to http://www.vmware.com/support/sr/sr_login.jsp To see the files collected, run: tar -tzf '/root/esx-2010-09-27--15.04.6179.tgz' Done.
Habrá que esperar un poco, y finalmente consultar el estado de nuevo con vm-support -x ó vmware-cmd ruta-fichero.vmx getstate para comprobar que se haya suspendido la máquina virtual con éxito.
A malas si no funcionó, podemos probar a pararla del todo.
c) Intentar parar la máquina virtual desde línea de comandos
El comando que utilizaremos en el menos peor de los casos es vmware-cmd, especificando junto a él la ruta completa donde esté ubicado el archivo de configuración .vmx de la máquina virtual, y el comando a ejecutar (en este caso, stop con el parámetro soft/trysoft).
~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx getstate getstate() = on ~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx stop trysoft [...esperaremos un tiempo razonable...] ~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx getstate getstate() = off
En el caso de que esto no funcione, podemos intentar lanzar el comando algo más agresivamente:
~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx getstate getstate() = on ~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx stop hard [...esperamos un tiempo prudencial...] stop(hard) = 1 ~# vmware-cmd /vmfs/volumes/[...]/vm-datarecovery.vmx getstate getstate() = off
Si esto no funcionó, pasemos al siguiente punto que es ya el más agresivo de todos.
d) Forzar la parada de la máquina virtual desde línea de comandos
Primero de todo, necesitaremos el identificador de la máquina virtual que podemos extraer tal como viene explicado en el primer punto del artículo. Después usaremos el comando vm-support de la siguiente forma, respondiendo SÍ, SÍ y SÍ en el proceso (como en las bodas de hollywood).
~# vm-support -X 1234567 VMware ESX Support Script 1.30 Preparing files: | Can I include a screenshot of the VM 1234567? [y/n]: y Can I send an NMI (non-maskable interrupt) to the VM 11134? This might crash the VM, but could aid in debugging [y/n]: y Can I send an ABORT to the VM 1234567? This will crash the VM, but could aid in debugging [y/n]: y Preparing files: / [...] Creating tar archive ... File: '/root/esx-2010-09-27--16.10.5176.tgz' NOTE: esx-2010-09-27--16.10.5176.tgz is greater than 20 MB. Please do not attach this file when submitting an incident report. Please contact VMware support for an ftp site. To file a support incident, go to http://www.vmware.com/support/sr/sr_login.jsp To see the files collected, run: tar -tzf '/root/esx-2010-09-27--16.10.5176.tgz'
Y eso es todo.
Epílogo: Socorro! No funciona!
Muchas veces lo que resulta mejor es Suspender primero, y Parar en el peor de los casos. Si esto no funciona, podría haber algún problema con el almacenamiento del cluster ESX/ESXi. Asegúrate de que tienes conectividad con el almacenamiento, y SÓLO entonces si nada funciona es mejor reiniciar de forma ordenada el servidor ESX/ESXi.
Eso sí, ya en este caso habrá que enviar un ticket con todos los datos a soporte de vmware. Espero que todo esto os pueda servir de ayuda.
Etiquetas: techtip, técnico, vmware