VI3: ¿Dónde estan los logs?

Muchas veces(cuando tenemos problemas sobretodo) no sabemos dónde mirar en nuestro entorno Virtual Infrastructure 3 para enterarnos de lo que está pasando. Otras veces es el propio soporte de VMware el que nos pide los logs para saber que es lo que ocurre.

He aquí una lista de los logs más importantes y su ubicacion:

Ubicacion: Host ESX

Vmkernel - /var/log/vmkernel – guarda actividades relacionadas con las VMs y el host ESX.
Vmkernel Warnings - /var/log/vmkwarning – actividades relacionadas con VMs..
Vmkernel Summary - /var/log/vmksummary - Se usa para determinar las estadisticas de uptime y disponibilidad para el ost ESX. El log legible por el humano está en /var/log/vmksummary.txt
ESX Server host agent - /var/log/vmware/hostd.log - Contiene informacion del agente que administra y configura el host ESx y las VMs. (Es un log que rota).
Service Console - /var/log/messages - Mensajes generales usados para resolver problemas de VMs en el ESX.
Web Access - /var/log/vmware/webAccess - Sin comentarios..
Authentication log - /var/log/secure - Registra las conexiones que requieren autenticacion como los demonios de vmware y acciones que inicia el demonio xinetd.
VirtualCenter agent - /var/log/vmware/vpx - Informacion del agente que se comunica con el VirtualCenter.
Virtual Machines - En el mismo directorio que estael fichero .vmx hay un fichero llamado vmware.log que contiene informacion util cuando unaVM se cae o acaba inesperadamente.
HA - /opt/LGTOaam512/log/* y /opt/LGTOaam512/vmsupport/* .
Principalmente aam_config_util_listprimaries.log (hosts primarios) y aam_config_util_listnodes.log


Ubicacion: Virtual Center

Logs de Instalacion del Virtual Center

Los logs de instalacion están en el directorio %TEMP% del usuario que instaló el software

• vmlic.log resultados de test del serviodr de licencias durante la instalacion
• redist.log resultados de insalacion MDAC/MCAD QFE
• vmmsde.log log de instalacion de MSDE
• vmls.log log de instalacion del License server
• vmosql.log Creacion de la Base de Datos/transaciones de VCDB
• vminst.log Log de la instalacion y subtareas del VC server
• VCDatabaseUpgrade.log Detalles del upgrade de VC 1.x DB
• vmmsi.log Log de instalacion del VI client
• vpxd-0.log pequeño log de la primera vez que se arranco el servicio

Logs del Virtual Center
Los logs del Virtual Center están en el directorio%TEMP%\vpx del usuario que esta corriendo el demonio vpxd

vpxd-#.log (# es del 0-9)
vpxd-index contiene el # del actual acrhivo de log en uso. Los logs rotan cada vez que el vpxd es iniciado y/o cuando llegana 5MB.

Logs del VI Client

Los logs del VIC estan en %TEMP%\vpx del usuario que esta corriendo el cliente
viclient-#.log (# es del 0-9). Los logs rotan cada vez que el cliente es iniciado.

Logs Varios

• Core dump : %USERPROFILE%’Application Data’VMware
• Log del debug del License Server %ALLUSERSPROFILE%’Application Data’VMware’VMware License
• Server’lmgrd.log(se resetea cada vez que el servicio se inicia; no rotacion)
• %ALLUSERSPROFILE%’Application Data’Macrovision’FLEXlm’
• Web Access (Tomcat) Logs C:’Program Files’VMware’VMware VirtualCenter 2.0’tomcat’logs

¿Que hace cada proceso de un ESX?

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/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...