- 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/vmklogger
logger -t VMware[init] -p daemon.err
Estos 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/vpxa
Sintaxis: /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 start
Como 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/vpxa
El 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 -a
Este 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/cimservera
Estos 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-vmkauthd
Este 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/config
Su 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.vmx
Estos 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
6 comentarios:
You are the best!!!
Sobre la reflexión. Aunque no vas mal encaminado, hemos de recordar que el COS (Console Operating System) es un "World" más... algo especial, eso sí, pero es sólo una parte del Hypervisor que permite que los procesos de servicio - los agentes de gestión, entre los que se cuentan los que nombras - se ejecuten en un entorno controlado por el Hypervisor... casi, casi, es una máquina virtual. Los "vmware-vmx" no son realmente las máquinas virtuales... son una especie de "pipe" por la que los agentes de gestión "ven" e interaccionan con las VM que ejecuta el Hypervisor. Lo mismo se extiende a otros muchos procesos. A diferencia de Xen o Hyper-V, donde la consola se está ejecutando junto con el Hypervisor en el DOM0, ESX no es directamente accesible, ya que la traslación binaria que utiliza para virtualizar el procesador le "obliga" a controlar constantemente a este, ya que al no confiar en la virtualización asistida por HW, ha de "autoprotegerse" y permitir que la consola (que como ya dije es un world más) pueda, de manera controlada y SEGURA, interaccionar con el hypervisor.
Si ejecutas un 'top' y un 'esxtop', verás que no tienen nada que ver.
Un saludo.
El esxtop me deja ver que la CPU de la console (CCPU?) esta idle la mayoria del tiempo.
Tambien nos muestra las VMs que estan corriendo y otras "VMs" como la console , vmotion, drivers,etc...
Lo que desconcierta es que haya VMs que puedan estar idle un 400%!, supongo que sera por los cores...
Voy a hacer un man esxtop...
Gracias J.L.!,
Jon
Establezcamos diferencias que, aunque en un principio puedan parecer semánticas, tienen su importancia. Los términos "World" y "Virtual Machine" no son sinónimos. Mientras una "Virtual Machine" SIEMPRE es un "World", un "World" no tiene porqué ser una Máquina virtual. ¿Porqué?... veamos qué significa cada término.
Un "World" es un proceso o conjunto de ellos que se ejecuta dentro del ámbito del servidor ESX, controle este o no su funcionamiento, aunque SIEMPRE será monitorizado por este. Un "World" no tiene porqué estar aislado "isolated", es decir, no tiene porqué utilizar recursos virtualizados (recordemos que ESX virtualiza TODO excepto la CPU). Normalmente los "World" (exceptuando a las VM) se ejecutan en la CPU0. Ejemplos claros de estos "World" son el VMotion, el Memory Scheduler, la propia consola. Nótese que el fallo de un "World" de este tipo SI puede afectar al Hypervisor... como ejemplo, intenta llenar el "/" del COS y verás lo que pasa. Otra característica que creo (pero que voy a confirmar) es que no hay traslación binaria y el control de los recursos del host (mem allocation, etc) lo hacen al estilo de un sistema operativo normal (es decir, y poniendo un ejemplo quizá demasiado básico), el vMotion se ejecuta en el vmkernel al estilo de como se ejecuta Word en un Windows, es decir, como una aplicación normal en un S.O. normal.
El otro tipo de "World" son las VM. Una VM SI está aislada del hypervisor, es decir, una circunstancia de fallo en una VM no afecta al resto del host ESX. en una VM SI hay traslación binaria, SI hay control de los recursos, y las VM NO interaccionan con el Hypervisor. Este se limita a "engañarlas"
El COS es un caso particular de World, ya que tiene un pié en cada mundo, ya que por un lado tiene una relación bidireccional con el VMkernel (es decir, no sólo recibe información del él sino que TAMBIEN puede enviar comandos de control al mismo). El COS es la interface entre los World del hypervisor y el "real world" (Welcome to the real world, Neo). De ahí que haya TANTA seguridad alrrededor del COS y que VMware nos aconseje cuidado con lo que ejeutamos en ella.
Otro caso "peculiar" es el iniciador iSCSI... Aunque es un módulo del vmkernel, necesita de la ayuda de la consola para "funcionar". De ahí que para establecer una conexión iSCSI para el vmkernel, sea necesario tener una "Service Console" que vea los targets iSCSI. Esto se debe en parte a lo poco elaborado que está el soporte iSCSI para ESX (Una de mis constantes reclamaciones a VMware).
Un saludote y a ver cuando quedamos para comer.
Gracias por esta información: Muy bien explicada. Voy a buscar más(si me de la vida) para enterarme bien de como va el asunto.[Supongo que lo que llaman world switching es el dar el procesador a una VM o a otra: el scheduler]
Aprendo de ti incluso en mi blog, gracias otra vez!
Que tal,
Tengo un problemilla con los procesos. Por más que los intento levantar, no consigo que se levanten los procesos que monitorizan el estado del sistema en el VI.
# /etc/init.d/vmware-vpxa restart
# /etc/init.d/mgmt-vmware restart
Se levantan pero antes de 5 segundos ya estan caidos de nuevo.
Alguna idea al respecto.
Muchas gracias
Publicar un comentario