Siempre me he preguntado qué hace cada proceso en un servidor ESX de VMware. El saber a tan bajo nivel que es cada cosa:- nos da cierta seguridad porque al fin y al cabo es un *nix (windows la verdad es que me manejo a nivel de servidor pero no tan agusto como en un linux...),- nos puede venir bien para tener el concepto de qué hace funcionar esas maquinas virtuales y qué representan para el Red Hat 7.1 que en realidad lleva el servidor ESX.
- nos sirve también para cuando el VIC falla(lo hace de vez en cuando) y no nos da la informacion necesaria de lo que ha pasado o esta pasando(esto ultimo lo hace constantemente... aun asi es muy buen producto).Al grano,
¿qué procesos podemos ver corriendo cuando realizamos un 'ps' en nuestros ESX?
(Bueno para verlo bien deberemos ejecutar "
ps axfwwww", las w son de wide wide wide, porque si no los procesos de nombre largo apareceran cortados en nuestra consola).
[vmnixhbd]Este proceso del kernel modificado de VMware(vmnix) controla las HBAs de nuestro sistema.
[vmkdevd]Este proceso controla los dispositivos(devices o adapters) que pueden ser reconocidos por el vmkernel.
Estos dos ultimos procesos son consultados por el comando esxcfg-vmhbadevs que nos devuelve el mapping de nombres vmhbaX:X:X a nombres /dev/ de linux./usr/sbin/vmkloggerlogger -t VMware[init] -p daemon.errEstos procesos se encargan del log del vmk(vm kernel o vmnix).
/bin/sh /usr/bin/vmware-watchdog
Este proceso es un
supervisor (como su nombre indica perro guardian), es decir, es un proceso(un script de shell) que tiene el cometido de lanzar otro proceso y supervisar si se cae o no para levantarlo.
Es algo que me suena, jeje, reconozco que quiza en algunos servidores tenga tareas cronificadas para este tipo de labores... como dice un amigo: "Ese script me ha salvado de venir muchos domingos...".
Realmente lo que hace el proceso es lanzar el proceso especificado y volver a levantarlo si se cae. Dejará de hacer esto(en consecuencia dejara caido el servicio al cual supervisa) si se producen un numero de caidas sucesivas del proceso("quick failures" definido como "caidas entre las que hay menos tiempo que min_uptime") o un numero absoluto de caidas totales.Por ejemplo:
/bin/sh /usr/bin/vmware-watchdog -s vpxa -u 30 -q 5 /usr/sbin/vpxaSintaxis: /
usr/bin/vmware-watchdog -s tag [-u min_uptime] [-q max_quick_failures] [-t max_total_failures] command
-s Nombre/Tag del servicio que debe correr (en este caso vpxa)
-u Maximo tiempo en segundos entre caidas para considerarlas "quick failures". O minimo tiempo que debe estar levantado para que
-q Numero maximo de "quick failures"
-t Numero total de "failures"
command: Comando a ejecutar (por ejemplo /usr/sbin/vpxa).
/bin/sh /usr/bin/vmware-watchdog -s webAccess -u 30 -q 5 /usr/lib/vmware/webAccess/java/jre1.5.0_07/bin/webAccess -server -Xincgc -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/common/endorsed -classpath /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/bootstrap.jar:/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/commons-logging-api.jar -Dcatalina.base=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Dcatalina.home=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Djava.io.tmpdir=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/temp org.apache.catalina.startup.Bootstrap start \_ /usr/lib/vmware/webAccess/java/jre1.5.0_07/bin/webAccess -server -Xincgc -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/common/endorsed -classpath /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/bootstrap.jar:/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/commons-logging-api.jar -Dcatalina.base=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Dcatalina.home=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Djava.io.tmpdir=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/temp org.apache.catalina.startup.Bootstrap startComo vemos el proceso vmware-watchdog lanza y supervisa el proceso
webAccess de forma que si en los ultimos 30 segundos se cae mas de 5 veces, simplemente dejará de levantarlo.
Pero, ¿qué es el proceso "/usr/lib/vmware/webAccess/java/jre1.5.0_07/bin/webAccess": Este proceso controla el servidor web del ESX(sí, ese que no tiene todas las funcionalidades y por eso no se usa mucho...).
Su reinicio se realiza de esta manera: service vmware-webAccess restart.
Su log esta en: /var/log/vmware/webAccess
Puertos en uso: 8080, 8009, 8005,
/bin/sh /usr/bin/vmware-watchdog -s vpxa -u 30 -q 5 /usr/sbin/vpxa \_ /usr/lib/vmware/vpx/vpxaEl agente del Virtual Center(el encargado de cominicarse conel VC) es uno de los que mas CPU consume normalmente. Como en el caso anterior watchdog vigila que no se caiga muchas veces. Entres sus funciones estan las de: comunicarse con las VMs, comunicarse con el Virtual Center y mantener la informacion del estado de los hosts comunicandose con VMAP y poder asi decidir que hacer en caso de caida de otro hosts(HA).
Su reinicio se realiza de esta manera: service vmware-vpxa restart
Su log esta en: /var/log/vmware/vpx
Puertos en uso: 902, 903 (el xinetd usa el 902 de la interfaz local)
/bin/sh /usr/bin/vmware-watchdog -s hostd -u 60 -q 5 -c /usr/sbin/hostd-support /usr/sbin/vmware-hostd -u -a \_ /usr/lib/vmware/hostd/vmware-hostd /etc/vmware/hostd/config.xml -u -aEste proceso es, por lo general, el que más CPU consume del servidor. (Suele ser
tres veces más que el segundo que mas consume, el vpxa). Este proceso se ocupa, entreo otras cosas, de que el Virtual Infraestructure Client se entere de los cambios que se producen en el ESX. Los cambios realizados por linea de comandos en el ESX no seran visibles al Virtual Center sin reiniciar este demonio y, por consiguiente, que vuelve a leer el fichero de configuracion del ESX(/etc/vmware/esx.conf)
Su reinicio se realiza de esta manera: service mgmt-vmware restart
Su log esta en: /var/log/vmware/hostd.log
/bin/sh /usr/bin/vmware-watchdog -s cimserver -u 60 -q 5 /var/pegasus/bin/cimserver daemon=false \_ /var/pegasus/bin/cimserver daemon=false\_ /var/pegasus/bin/cimserveraEstos procesos son ajenos a VMware(de hecho Xen también los usa:
http://xen.org/files/xs0106_xen_managmnt_interf.pdf ).
Llevan el CIM(
Common Information Model), un standard industrial desarrollado por el Distributed Management Task Force (DMTF), para describir datos acerca de aplicaciones y dispositivos de forma que los administradores y los programas de gestion de software puedan controlar de la misma manera las aplicaciones y dispositivos en diferentes plataformas, asegurando la interoperativilidad. Usa tecnicas de Programacion Orientada a Objetos para proveer de una definicion consistente y una estructura de los datos. Por ejemplo, si una empresa compra cuatro servidores de diferentes vendedores, con CIM el administrador puede ver la misma info de cada uno de ellos: fabricante, SN, numero de dispositivo, capacidad de almacenamiento, relacion con aplicaciones... (Otros protocolos mas simples son SNMP y DMI)
Mas info:
http://www.openpegasus.org/
/usr/lib/vmware/bin/vmkload_app --setsid --sched.group=host/system/vmkauthd --sched.mem.min=4 --sched.mem.max=12 /usr/lib/vmware/bin/vmware-vmkauthdEste proceso es el cargador de aplicaciones del espacio de usuario. La aplicacion es ejecutada con los parametros indicados y administrada por el VMkernel. El proceso vmkload_app espera a que la aplicacion termine y sustituye (hace de repetidor/proxy) la entrada y la salida standard de la aplicacion. Si le enviamos una señal nº7(SIGNAL 7) a vmkload_app la señal sera reenviada a la aplicacion que corre debajo.
Solo las aplicaciones compiladas para el VMkernel pueden ser ejecutadas por este proceso, además, sólo son permitidos los binarios listados explicitamente en /etc/vmware/UserWorldBinaries.txt.
Con la opcion -k se puede mandar una señal a la aplicacion que esta corriendo.
Con la opcion -b se puede forzar a la aplicacion que esta ejecutandose a pararse y esperar que se enganche un debugger.
En concreto el proceso anterior esta
lanzando la aplicacion
/usr/lib/vmware/bin/vmware-vmkauthd desde el espacio de usuario contra el
VMkernel. Las opciones dicen que se ejecute en el schedules group host/system/vmkauthd, con un maximo de memoria de 12 y un minimo de 4 y que se cree una nueva sesion de terminal para el proceso vmkload_app.
/usr/lib/vmware/bin/vmware-vmkauthd se encarga
de la autorizacion el vmkernel(en concreto de que podamos usar la console de las VMs, como su fuera un redirector del KVM).
Su fichero de configuracion es /etc/vmware/configSu reinicio se realiza de esta manera: service vmware-vmkauthd restart
Este proceso parece que no usa ningun puerto directamente pero el 902 es el puerto well-know de vmkauthd y es usado por vpxa.
/usr/lib/vmware/bin/vmkload_app /usr/lib/vmware/bin/vmware-vmx -ssched.group=host/user -@ pipe=/tmp/vmhsdaemon-0/vmx6c1dbb9c3b513d69;vm=6c1dbb9c3b513d69 /vmfs/volumes/4640826e-e0c6126a-e819-001a64088132/Virtual_Machine_RHELAS4U2/Virtual_Machine_RHELAS4U2.vmxEstos procesos son la joya de la corona. Realmente son los procesos que representan las VMs, es decir, hay tantos procesos de este tipo como maquinas virtuales encendidas.
Para el ESX cada VM es un unico proceso lanzado desde el espacio de usuario a través de vmkload_app. Como se ve, hace referencia al archivo de conf de la maquina virtual(vmx).
La forma de apagar forzosamente una maquina virtual (cuando no queda más remedio) es haciendo un kill -9 a ese PID, de esta forma el proceso muere y la maquina virtual será reportada en el VIC como apagada. Si alguien quiere tenfo desarrollado un rpc que se instala en el ESX y permite "apagar" una maquina virtual de forma instantanea. Lo use para un cluster GFS de maquinas virtuales y es el equivalente de un switch de corriente que le quita la corriente a un servidor para realizar el fencing.
Adjunto imagen con la configuracion de puertos de VI3. Espero que sirva para aclarar el tema de los puertos:
Como relfexion: Realmente en todos los ESX que he mirado, los procesos que más CPU gastan son vmware-hostd y vpxa que no se ocupan realmente de ejecutar las VMs sino que se ocupan de conectar la infraestructura virtual. Sin embargo los procesos de las maquinas (los procesos
vmware-vmx) no consumen ni de lejos la misma CPU. ¿No deberia ser al revés si lo que estamos compartiendo con nuestros servidores virtuales es la CPU? Quiza sea un tema de cómo representa la CPU el Red Hat que lleva debajo..., quiza tengo algo mal en mis ESX...
Entradas
