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.

Quizás es uno más de muchos, pero la gracia del asunto es que he intentado resumir los pasos y cubrir varias versiones a la vez. Tenemos dos opciones, según el tipo de ESX que se tercie…

Acceder por SSH mediante la clave pública de root conlleva sus riesgos, pues se deja de emplear passwords para autenticarse en los servidores. Si tus máquina cliente no está en una red de confianza o si otras personas no confiables podrían tener acceso local a esta máquina, mejor no usar este método de autenticación. Hay otras formas de hacerlo que permiten reforzar la seguridad, con el uso de SSH-Agent y tokens USB (por ejemplo) pero que están fuera de este artículo.

Quizás en un futuro me plantee extender este tema, ya veremos ;-)

Servidores ESX 3.x/4.x

Será necesario conectarse físicamente al servidor para poder habilitar primero el acceso al servicio SSH.

• Pulsaremos Alt-F1 para acceder a la consola y entraremos en el sistema con las credenciales de root.
• Una vez dentro, habilitaremos el acceso y crearemos las claves SSH de root tal como viene a continuación.

  servidorx:~# esxcfg-firewall -e sshServer
  servidorx:~# ssh-keygen -t rsa
  
  Generating public/private rsa key pair.
  Enter file in which to save the key (/root/.ssh/id_rsa):
  Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in /root/.ssh/id_rsa.
  Your public key has been saved in /root/.ssh/id_rsa.pub.
  The key fingerprint is:
  xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@servidorx...

• Editamos el servicio SSH para que root pueda hacer login, y recargamos el servicio SSH de nuevo.

  servidorx:~# vi /etc/ssh/sshd_config
  
  [...]
  PermitRootLogin yes
  [...]
  
  servidorx:~# /etc/init.d/ssh reload
  

• Ya desde el servidor o cliente que queramos hacer login con autenticación mediante clave pública, copiaremos el archivo /root/.ssh/id_rsa.pub o /root/.ssh/id_dsa.pub (si no lo tuviésemos, podemos generar las claves de root mediante el comando ssh-keygen antes de copiarlo) dejándolo como authorized_keys2 en el servidor ESX destino x.x.x.x/root/.ssh/ para acceder por SSH sin password.

  clientex:~# scp /root/.ssh/id_*.pub x.x.x.x:/root/.ssh/authorized_keys2
  clientex:~# ssh x.x.x.x
  ...

  • Para empezar, hay que habilitar el uso de SSH, conectados físicamente al servidor: según la versión de ESXi variará la forma de hacerlo.

    :::::::: Para ESXi < 4.1 ::

    Pulsaremos Alt-F1 para acceder a la consola, aunque no aparecerá nada en pantalla salvo unas líneas de texto.  Teclearemos tal cual unsupported y pulsaremos Intro.

    Nos preguntará el password de root del servidor directamente y que tendremos que introducir. Una vez y felizmente dentro, hay que descomentar estas líneas de /etc/inetd.conf:

    ~ # vi /etc/inetd.conf
    [...]
    # Remote shell access
    #
    ssh stream tcp  nowait root /sbin/dropbearmulti dropbear ...
    ssh stream tcp6 nowait root /sbin/dropbearmulti dropbear ...
    [...]

    Y entonces habrá que recargar el servicio inetd de nuevo, para lo cual hay dos maneras igual de ilustrativas:

    La primera,más salvaje nos permitirá ver qué servicios están corriendo sobre ESXi en condiciones normales.

    ~ # /sbin/services.sh restart
    Running vmware-aam stop
    Stopping vmware-aam: success
    Running sfcbd-watchdog stop
    [...]

  La segunda, la fina, la que importa, ‘la favorita’:

  ~ # kill -HUP `cat /var/run/inetd.pid`

  :::::::: Para ESXi => 4.1 ::

  En las nuevas versiones, se puede habilitar directamente desde la consola de gestión estilo NCURSES que muestra ESXi, conectados físicamente al servidor. Hay que pulsar F2, introducir las credenciales y activar felizmente las siguientes opciones de este submenú.

  -- Troubleshooting Options
  Local Tech Support (pulsamos Intro para activarlo)
  Remote Tech Support (pulsamos Intro para activarlo)

  Nada más hay que hacer para activar el servicio SSH: sorprendente, ¿verdad?

  • Queda entonces configurar la autenticación mediante clave pública.Haremos prácticamente lo mismo que hemos hecho en el caso de los servidores ESX, con la salvedad de que no hay directorio /root, y que tampoco podemos generar el par de claves de root desde cualquier servidor ESXi.

    Primero generaremos desde cualquier servidor -no ESXi- el par de claves SSH que copiaremos luego al servidor ESXi destino en tres pasos:

    a) crearemos un par de claves para identificar el usuario root del servidor ESXi ( es decir root@servidorx);
    b) desde el servidor ESXi destino, crearemos el directorio .ssh en la raíz, con los permisos adecuados.
    c) desde el cliente origen copiaremos a servidorx:/.ssh las claves recién creadas, que serán las que identifiquen al usuario root del servidor ESXi en cuestión (root@servidorx).

    clientex:~# ssh-keygen -t rsa -f id_rsa -C root@servidorx
    
    (hacemos login en el servidor ESXi)
    servidorx:~# mkdir .shh; chmod 600 .ssh
    
    (volvemos al cliente de nuevo)
    clientex:~# scp -r id_*.pub x.x.x.x:/.ssh/.
    root@x.x.x.x's password:
    id_dsa             100% |************************|   668       00:00
    id_dsa.pub         100% |************************|   614       00:00

    Hecho esto, generaremos el archivo authorized_keys (ojo, no authorized_keys2) que necesitaremos para poder autenticarnos con la clave pública del usuario root de nuestra máquina cliente:

    clientex:~# scp /.ssh/id_*.pub x.x.x.x:/.ssh/authorized_keys

    Acto seguido, podremos entrar en el servidor sin password como era de esperar:

    clientex:~# ssh x.x.x.x
    You have activated Tech Support Mode.
    
    The time and date of this activation have been sent to the system logs.
    VMware offers supported, powerful system administration tools.  Please
    see www.vmware.com/go/sysadmintools for details.
    
    Tech Support Mode may be disabled by an administrative user.
    Please consult the ESXi Configuration Guide for additional
    important information.
    
    ~ #

  Espero que haya merecido la pena el viaje hasta aquí. Hasta pronto!

Servidores ESXi 3.x/4.x

De cara a los servidores ESXi es algo más complicado, pues el hipervisor está totalmente integrado en el kernel y no hay consola de servicio. Esto se traduce en que el servicio SSH se proporciona a través de DropBear y no de OpenSSHServer como estábamos acostumbrados hasta ahora.

Para empezar, comprobaremos que nuestro archivo de repositorios /etc/apt/sources.list está configurado para que podamos descargarnos las fuentes de los paquetes que queramos modificar.

Para ello, podemos copiar las líneas que especifiquen repositorios de paquetes que comiencen por deb, y una vez copiadas entonces sustituiremos el término deb por deb-src en cada una de ellas:

# vim /etc/apt/sources.list

deb http://ftp.rediris.es/debian lenny main contrib non-free
deb-src http://ftp.rediris.es/debian lenny main contrib non-free

Hecho esto, procederemos primero a actualizar las listas de paquetes disponibles. Luego instalaremos el conjunto de paquetes build-essential para poder bajarnos las fuentes, y el conjunto de paquetes devscripts para facilitar la tarea de la recompilación, instalación, etc.

Por último, no hay que olvidar incluir las dependencias de compilación del paquete, instalables fácilmente a través de apt-get build-dep.

Un buen lugar para dejar las fuentes puede ser /usr/local/src.

# cd /usr/local/src/.
# apt-get update
# apt-get install build-essential devscripts
# apt-get source vsftpd
[...]
dpkg-source: extracting vsftpd in vsftpd-2.0.7
dpkg-source: info: unpacking vsftpd_2.0.7.orig.tar.gz
dpkg-source: info: applying vsftpd_2.0.7-1.diff.gz

# apt-get build-dep vsftpd

A partir de aquí nos habremos descargado tanto las fuentes del paquete como el código fuente descomprimido con todos los ajustes que oficialmente el equipo Debian realizó en su día.

Si queremos trabajar directamente sobre el código fuente original, podemos tirar del archivo .orig.tar.gz. Por norma general, será siempre mejor seguir las líneas de mantenimiento de paquetes de Debian.

# ls
vsftpd-2.0.7            vsftpd_2.0.7-1.dsc
vsftpd_2.0.7-1.diff.gz  vsftpd_2.0.7.orig.tar.gz
# cd vsftpd-2.0.7

A partir de aquí modificaremos la configuración de cómo se compilará el software, así como el directorio debian que contiene todos los scripts involucrados en la configuración e instalación del paquete: Podemos incluir archivos que no se generan por defecto, modificar las operaciones que se realizan en la instalación y borrado de este paquete, etc…

/usr/local/src/vsftpd-2.0.7# vim defs.h
(definimos algunos parámetros previos a la compilación del paquete)
[...]define VSFTP_USERNAME_MAX      256

/usr/local/src/vsftpd-2.0.7# cd debian
/usr/local/src/vsftpd-2.0.7/debian# ls
README.Debian  copyright  vsftpd.dirs     vsftpd.logrotate  vsftpd.postrm
changelog      ftpusers   vsftpd.docs     vsftpd.manpages   watch
compat         patches    vsftpd.init.d   vsftpd.pam
control        rules      vsftpd.install  vsftpd.postinst

/usr/local/src/vsftpd-2.0.7/debian# vim ftpusers
(añadimos por ejemplo al un usuario ftp en la configuración)
ftpluser

/usr/local/src/vsftpd-2.0.7/debian# vim vsftpd.pam
(modificamos la configuración de pam, para utilizar la autenticación contra otros mecanismos)
[...]

/usr/local/src/vsftpd-2.0.7/debian# vim vsftpd.logrotate

/var/log/vsftpd.log {
    # ftpd doesn't handle SIGHUP properly
    compress
    missingok
    notifempty
    rotate 15
    daily
}

Una vez hechas las modificaciones, es necesario dejar un detalle del cambio en el paquete en el archivo debian/control, mediante el uso de la herramienta debchange.

Es siempre importante indicar de que se trata de una versión local (-l) para identificar el paquete que resultará de la recompilación, añadiendo nuestra dirección de correo, etc. Hecho esto, compilaremos el paquete mediante el uso de dpkg-buildpackage desde la raíz del directorio del código fuente.

/usr/local/src/vsftpd-2.0.7/debian# debchange -u low -l .sandboxed. & cd ..
vsftpd (2.0.7-1.sandboxed.1) unstable; urgency=low

* New maintainer, local version por personal use.
* This version supports now long usernames, tailored for an specific environment.-- sandbox 

<sandbox@boxed.4.u.net>  Mon, 19 Jul 2010 18:08:45 +0200

vsftpd (2.0.7-1) unstable; urgency=medium
* New maintainer, taking over package from Matej.
* New upstream release (Closes: #497149):
[...]

/usr/local/src/vsftpd-2.0.7# dpkg-buildpackage -rfakeroot -D -us -b & cd ..

Por último, descenderemos a la raíz de /usr/local/src e instalaremos el paquete recompilado…y ya habremos terminado.

/usr/local/src7# dpkg -i vsftpd_2.0.7-1.sandboxed.1_i386.deb