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

Oracle VM: LiveSync - High Availability, LiveMigration sin SAN

Los de Thinsy(EnSpeed) han anunciado que ya esta disponible para descarga las caracteristicas de Live Migration(Vmotion en terminos vmwaristicos) y VMFailover(HA en terminos vmwaristicos) para OracleVM. La noticia no sería tan importante si no hubiesen anunciado que esto se puede hacer sin una SAN, es decir que con Direct Attached Storage sería suficiente.
Como dice la nota de prensa:

Saratoga, California – April 17, 2008 – Thinsy Corporation today announced the immediate availability of a new version of their Peer to Peer SAN Replacement technology LiveSync, for Oracle VM Server 2.1.1. Once the LiveSync rpm is installed on the Direct Attached Storage equipped Oracle VM Servers, High Availability Failover and LiveMigration are enabled. Clone VM support, a new feature which enables the cloning of VMs in less than fifteen seconds was also unveiled by Thinsy Corporation.

Yo por el momento no lo he visto asi que permanezco incredulo pero podria ser un fuerte varapalo para VMware puesto que la compra de una SAN es una de las cosas que suele tirar para atrás a las empresas a la hora de comenzar con la virtualizacion. Proximo episodio en su casa...

Thin Provisioned: Problemas con Storage VMotion, migraciones y clonaciones

Cada vez es más usual trabajar con VMware sobre NFS. La combinacion con una NetApp y sus FlexVolumes hace que sea algo muy flexible y facil de provisionar y administrar. Con la capacidad de las cabinas NetApp de realizar Thin Provisioning somos capaces de dar grandes volumenes de datos pero ocupar solo lo necesario. El concepto se ve facilmente de forma grafica. Por defecto, cuando provisionamos VMDKs por NFS las cabinas NetApp lo administran como thin provisioned. Hasta el momento esto no habia dado problemas de ningun tipo, es mas, es una gran ventaja.

Las pruebas muestran que, aunque los VMDKs son provisionados como thin en su creacion, luego se pueden convertir a thick a lo largo de su vida por una serie de operaciones como son (Quiza haya mas):
:( Migracion de los VMDKs de un datastore a otro (aunque el destino tambien sea NFS) convierte los VMDKs a thick.
:( Realizar clones de los VMDKs thin hace que los clones sean thick.
:( Realizar Storage VMotion tambien provoca que los discos se vuelvan thick.

¿Como solucionarlo?

Si tenemos una NetApp con single file SnapRestore estamos de suerte. Bueno, al menos las dos primeras operaciones antes descritas sí que podemos conseguir que nos mantengan los VMDKs de forma thin. (Para la tercera Storage VMotion no sirve).

Pasos:

1. Una vez preparada la VM (sysprep si es windows), tomaremos un snapshot del volumen que la contiene [snap create vol-name snapshot-name ].
2. Posteriormente creamos una VM en el Virtual Center pero sin disco. (Esto crea los ficheros de conf y el directorio)
3. Ahora podemos correr un SnapRestore para recuperar el .vmdk y el -flat.vmdk. [snap restore -t file -s snapshot-name -r new filename and path original filename and path]
4. Editaremos el .vmdk de la nueva VM para que apunte al nuevo -flat.vmdk. Y ya solo nos queda Edit Settings y añadir el disco.

como funciona VMware HA

Bueno despues de varios posts cortos aqui va uno largo que llevo preparando tiempo.

La documentacion de VMware acerca de VMware HA deja bastante que desear y realmente es un producto que muchas veces necesitas conocer más a fondo para resolver problemas que te encuentras, por eso veo necesario tener una pequeña guía (técnica) de cómo funciona VMware HA:

VMware HA monitoriza constantemente todos los ESX de un cluster y detecta las caidas de estos. En cada host hay un agente corriendo que mantiene el heartbeat con los demas hosts del cluster. La perdida del heartbeat inicia el proceso de reiniciar las maquinas virtuales en los otros hosts proporcionando de esta forma un fail over de las maquinas virtuales con una parada minima(downtime = tiempo de reinicio) de servicio.

Es importante resaltar que HA es reactivo, es decir actua cuando ocurre algo y NO usa Vmotion y DRS es proactivo: usa vmotion y actua para que no ocurra nada o para que no se de la situacion en la que pueda ocurrir.

El hecho de que las VMs se inicien en un host o en otro cambió en el VC2 y el VC2.1: El primero lo hacia alfabeticamente, es decir la VM se iniciaba en el siguente host alfabeticamente que tuviese recursos, en cambio en el VC2.1 el host que iniciara la VM sera el host que tenga mayor capacidad(sin reservar) para levantarla. Una vez que HA ha realizado el paso de VMs, el DRS entra en juego y verá si es necesario mover las VMs.

VMware HA no controla la caida individual de una VM, ésto puede tratarse con una alarma, ya sea con el Virtual Center o con un software de monitorizacion externo.

Arquitectura:

La creacion y administracion de los clusters de HA se hace a traves del VC. El servidor de administracion del Virtual Center instala un agente en cada host del cluster de forma que cada host pueda comunicarse con los otros y mantener la informacion del estado de los hosts y poder asi decidir que hacer en caso de caida de otro hosts.
En cada cluster hay un host que es el primario(suele ser el primero) que actua como controlador y es el que inica las accciones de failover. De hecho, cuando se introduce un nuevo nodo al cluster, éste ultimo necesita comunicarse con el primario para completar la configuracion. Si el nodo primario cae, HA inmediatamente promociona uno de los nodos a primario.
Actualmente AAM no permite mas de 4 hosts y el parametro de max number of failures se refiere al maximo numero de primarios que podria haber en un cluster.

- Cuando queremos quitar un nodo del cluster lo podemos poner en Maintenance Mode y apagar las VMs o migrar (vmotion) sus VMs (si DRS esta activado, éste nos lo propondrá o lo hara directamente).
- Cuando se añade un nuevo nodo al cluster, todas las VMs se ponen a default: Restart Prioriy = Medium e Isolation Response = PowerOff

Nota: Para apagar temporalmente HA ponemos el ESX en maintenance mode y para apagar temporalmente DRS lo configuramos como partially automated.

El agenteVC (vpxa) se comunica con las VMs y VMAP (este ultimo contiene la lista de que hosts estan corriendo que VMs). El agente AAM (HA agent) monitoriza AAM en otros hosts (heartbeat via red SC), para evitar el split brain cuando los nodos se quedan aislados, cada nodo tiene una direccion a la que hace ping para ver si esta aislado (option das.isolationaddress ).
[Mas opciones avanzadas: http://pubs.vmware.com/vi35/resmgmt/wwhelp/wwhimpl/common/html/wwhelp.htm?context=resmgmt&file=vc_cluster_das.10.9.html]

Los requesitos para que funcione HA son:

• Capacidad de encender la VM desde cualquier host
• Acceso a recursos comunes(red, SAN)
• Resolucion de DNs en el cluster(tiene muchisima dependencia /etc/hosts y /etc/resolv.conf)

Parametros a Configurar:

Orden de reinicio de las VMs: Establece que prioridad de reinicio tienen las VMs. Se debe establecer a Disabled si no queremos que se use HA en dicha VM.

Admision Control: Aqui se prioriza el uptime o que las maquinas tengan sus recursos siempre.

Isolation response: Que hacer si se queda aislado el host: el power off de las VM liberará el lock de los discos.

Nota: Cuando se añade un nuevo nodo al cluser, todas las VMs se ponen a default: Restart Prioriy = Medium e Isolation Response = PowerOff

¿Que ocurre si el VC Server se cae?

El Virtual Center Management Server(servidor del VC) no es un unico punto de fallo porque si cayera el VC Server los clusteres de HA siguen pudiendo reiniciar las maquinas virtuales en otro host en caso de caida de uno de los hosts de forma que el funcionamiento general sigue pero la informacion de que recursos estan disponibles será la del estado del cluster antes de caer el VC Server.

Si entramos con el VIC a un ESX y cambiamos algo mientra el VC esta caido entonces eso cambios si tienen efecto y cuando repongamos el VC los verá.(En cambio si el VC no esta caido y modificamos algo con el VIC a traves de un ESX , el VC no lo verá y tendrá desactualizado su VMap etc...)

VMware HA esta continuamente monitorizando qué recursos hay para ser capaz de reiniciar las maquinas en diferentes hosts en caso de caida de uno de ellos. El agente AAM se ejecuta en la service console de los hosts y mantiene una base de datos en memoria de los nodos del cluster usando los heartbeats para coordinar los nodos que estan activos y los que no (los que no son activos son los que estan sin red o en maintenance mode).

El hecho de que una maquina virtual pueda ser levantada en otro servidor ESX(host) es posible gracias a la tecnologia de locking de la pila de almacenamiento del ESX que les permite a varios ESX acceder a un mismo disco simultaneamente.

¿Que ocurre cuando un host se cae? (Cronologia del Fail-Over)

Todo el proceso dura 15 segundos despues de que el host se quede aislado y no mande mas heartbeats:

t=0s: Un host deja de tener conectividad(o se queda aislado en la red) y deja de mandar heartbearts. El nodo intanta hacer pings a la isolation address para ver si efectivamnete esta aislado.(la verification address es el default gw de la interfaz de la service console, para cambiarla hay que cambiar el parametro das.isolationaddress en advanced parameters). Si no puede hacer ping a su isolation address entonces el nodo sabe que esta aislado y no que los otros nodoas se han caido.

t menor que 12s: Si antes de 12 segundos vuelve la conectividad, todo vuelve a la normalidad. Los demas hosts marcaran al hosts con problemas de red como activo y no pasará nada. El host no se marcará a si mismo como aislado.

t entre 12s y 15s: El host se marca como aislado(isolated) y empieza a apagar sus maquinas para liberar locks(respuesta por defecto y configurable). Si justo la conectividad vuelve en este momento las maquinas virtuales se apagaran(si esta conf por defecto) pero no se levantarán(reiniciarán) en otros hosts porque los otros no le han marcado todavia al host como caido(failed). El apagado de las maquinas es hard.

t=15s: Los demas hosts declaran el host como caido(failed) y en consecuencia adquieren el lock de las maquinas virtuales y las levantan(si asi lo hemos configurado, si no la VM seguira corriendo en el host aislado y el mecanismo de locking prevendrá que no se inicie en otro sitio).

http://kb.vmware.com/selfservice/viewContent.do?language=en_US&externalId=2956923

¿Que ocurre si Current failover capacity != Configured failover capacity? (Red Cluster)

Esto ocurre cuando han fallado mas hosts que los previstos. Las VMs con mayor prioridad haran el fail over las primeras. Para la version 3.02 de ESX y anteriores, el valor de HA Failover Capacity se calcula así: El valor de Failover Capacity está determinado por el valor del slot que tiene el cluster. El slot es calculado con una combinacion de la CPU y Memoria total que hay en los hosts.

Ejemplo:
Tenemos 4 hosts y el valor CONFIGURADO de Failover Capacity es 1 Los hosts tienen esta memoria: ESX1 = 16 GB
ESX2 = 24 GB
ESX3 = 32 GB
ESX4 = 32 GB
En el cluster tenemos 24 VMs configuradas y funcionando. De las 24, hay que determinar cual es la que mas "configured memory" tiene. Por ejemplo pongamos 2GB. Las demas tienen menos o igual a 2GB de memoria configurada. Con esto ya podemos hacer el cálculo:
1. Escojemos el host ESX que tenga menor memoria RAM intalada. En este caso es ESX1 y tiene 16 GB

2. Dividimos este valor por el mayor valor de la memoria RAM de nuestras maquinas virtuales(2GB en el ejemplo). Nos sale 8 (16 / 2). Esto significa que tenemos 8 slots disponibles(como minimo) en cada ESX.

3. Como tenemos 4 hosts y la failover capacity configurada es de 1, nos podriamos quedar con 3 hosts en la peor situacion(que cayera uno). Por ello el numero total de VMs que podemos encender en esos 4 hosts es 24 VMs. ( 8 slots x 3 hosts en el caso peor = 24 VMs)

4. Si el numero total de VMs excede 24 entonces nos dará: "Insufficient resources to satisfy HA failover" y el el valor de "current failover capacity" será puesto a 0. Si el numero de VMs encendidas es menor que 24 no obtendriamos este mensaje.

Nota: Si se sigue viendo el mensaje despues de bajar el numero de maquinas encendidas, chequea las reservations de CPU y Memory en las VMs y en los resource pools porque esto puede modificar el calculo. Se debe evitar reservations de CPU y memoria innecesarias en las VMs porque esto puede causar que ocurran estos tipos de errores dado que tenemos que asegurar que el recurso esta disponible.



Para que el Virtual Center deje de estar en una situacion en la que los recursos son insuficientes para satisfacer VMware HA posdemos hacer lo siguente:

1.- Marcar "Allow Virtual Machines to be powered on even if they violate availability constraints" en la confiduracion del cluster. En este caso se ignoran los calculos anteriormente descritos y se intentará encender el maximo numero de VMs posibles en caso failover. Con esta opcion se puede establecer la restart priority (en "Virtual Machine Options") en la configuracion del cluster, de esta forma, las VM prioritarias seran encendidas antes y posteriormente las menos prioritarias hasta en punto en el que ya no se pueda encender ninguna VM más

2.- Si tenenmos una VM que tiene configuarada una gran cantidad de memoria, podemos o bien rebajar su memoria configurada o bien sacarla del cluster y ejecutarla en otro ESX standalone. Esto incrementará el numero de slots disponibles con el hardware que tenemos.

3.- Incrementar la cantidad de memoria en los servidores de forma que haya mas slots disponilbes con las reservatiosn de RAM actuales.

4.- Quitar las reservas de CPU en todas las VM que sean mayores que la velocidad maxima de los procesadores fisicos.

Nota: El calculo descrito arriba es muy limitado como se puede ver y va a ser revisado en las siguentes versiones del Virtual Center.

Troubleshooting:

- Conectividad IP: pings desde todos a todos y con el nombre corto y el FQDN. Pings al VC server

- DNS!!!:

• Se pueden resolver los nombres cortos(sin el dominio) en cada ESX de los otros ESX
• El FQDN es menor de 29 caracteres?
• Mirar el /etc/hosts y /etc/resolv.conf poner en esos ficheros el "hostname.FQDN" tambien.
• Se puede editar el nsswitch.conf y cambiar: "hosts: dns files". Asi mira primero en dns y si estan caidos en local.

- Que la red y el almacenamiento sea visible por los nodos.
- Que no haya habido usuarios que hayan accedido con el VIC al host en concreto bypasseando al Virtual Center y hayan cambiado las reservations.
- Logs: /opt/LGTOaam512/log/* y /opt/LGTOaam512/vmsupport/* .
Principalmente aam_config_util_listprimaries.log (hosts primarios) y aam_config_util_listnodes.log

Errores y problemas tipicos:

"Could not find a primary host to configure DAS on"
A host that was removed from the VC inventory still appears on the internal list of hosts for this cluster.
Workaround: create a new cluster and add hosts to this new cluster.
Resolved in ESX Server 3.0.1 and VC 2.0.1.

"Configuring HA failed" or "while using HA, the vm did not failover".
Size of Fully Qualified Domain Name (FQDN) or short host name.
Workaround:
If the host short name is more than 29 characters, change the HOSTNAME entry in /etc/sysconfig/network to the shorter name.
If using an FQDN that is greater than 29 characters:
• Change the FQDN to less than or equal to 29 characters.
• Remove the existing cluster.
• Create a new cluster.
• Add all the hosts back to the cluster.

HA Configuration Fails
Check DNS, FQDN
You have just added a new host to the cluster
• Check /opt/LGTOaam512/log/aam_config_util_addnode.log
• /var/log/vmware/vpx/vpxa.log
• In VC, right click on the host that shows the HA problem and click reconfigure for HA.
• Were all the hosts responding?
• If not –new host cannot communicate with any of the primary hosts.
• Solution:
• Disconnect all the hosts that are not responding before you can add the new host.
• The new host becomes the first primary host.
• When the other hosts become available again, their HA service is reconfigured. ESX Server is running slowly.

Top command shows vmware-hostd using a lot of resources
vmware-hostd Uses a Lot of CPU or Has Generated a Core Dump Why DRS / HA cluster that contains VMs originally built on an ESX Server 2.x host.
Fix: To adjust resource allocation for vmware-hostd: For each VM, right click it and go to Edit Properties. Select Resources. Ensure you "touch" each CPU and memory resource:
• Restart hostd: type: service mgmt-vmware restart
• Set resources to the settings you want.

"HA service doesn't start up" or "HA error on the host, after booting successfully after host failure"
Due to problem rejoining the rest of the cluster
Fix: use the ReconfigureHA task on the host to correctly configure the HA service on the host.

Deploying a VM from a template into a cluster, the updated BIOS settings are lost.
Affects HA/DRS clusters but not DRS-only clusters.
Fix: Change the BIOS setting in the affected deployed VM.

la funcion Shadow Copies de NetApp sobre CIFS

El otro dia en Madrid asistimos a una demostración de NetApp. Hacía tiempo que tenía ganas, la verdad es que es una pasada, lo que no creo que sea igual es el precio....

Algo que muchos conocerán pero que me llamó muchisimo la atencion es la utilidad de acceder a las shadow copies de volumenes compartidos. Me explico, estas cabinas son capaces de presentar al usuario de la NAS que se ha conectado por CIFS una especie de historial (o versiones) de los archivos que almacena en los volumenes compartidos, es decir la funcion de snapshots de NetApp se integra con VSS(Microsoft Volume Shadow Copy Service) de tal forma que los usuarios pueden ver los snapshots tomados en la cabina via el cliente de VSS.
Es tan facil como pinchar en el menu contextual de un archivo (boton derecho), ir a propiedades y pichar la pestaña Versiones. La verdad es que es asequible para cualquier usuario y quitaría mucho trabajo a los administradores de sistemas que tienen que tirar de backup.

vmreference VI3 card

Aunque sea posteo corto pero posteo. Aqui os dejo un enlace a un pdf muy muy útil en mi opinion. Es una especie de chuleta de Virtual Infrastructure 3 de VMware. Tips condensados en una hoja por las dos caras, desde la instalación, la localización de logs, resource pools, licencias, puertos, red, virtual center... vamos, una buena chuleta:

http://vmreference.googlepages.com/vmreferenceVI3Card1.1.pdf

Link para preparar VCP de VI3 de Vmware

Hace mil años que no escribo nada... cosas del curro.
Aqui va un link que puede venir bien para echar un vistazo rapido y clarificar conceptos:
http://www.markwilson.co.uk/blog/data/vcpcram.pdf