Tanto en la versión anterior de VMware, VMware ESX 3.x, como en la ultima versión, VMware vSphere ESX 4.x, el servidor web Access está apagado por defecto.

El servidor vCenter y VMware vSphere ESX 4.x incluyen un servidor Web (Web Access) – en concreto es una versión “rebajada” de servidor web Apache Tomcat. Sin embargo, la versión thin del hypervisor de VMware, VMware ESXi, no incluye esta funcionalidad.

Si recibes el error “503 Service Unavailable” cuando intentas conectarte al servidor Web, tanto del servidor vCenter como del servidor VMware ESX, es porque el servicio Web Access no está arrancado (por defecto).

Tip: Para arrancar el servicio Web Access en el servidor VMware vSphere ESX 4.x, bájate al Service Console y ejecuta el siguiente comando: service vmware-webAccess start.

Para arrancar el servicio Web Access en el servidor de vCenter, arranca el servicio correspondiente en la pestaña services de tu servidor Windows.

Es un placer para mi presentaros mis nuevos videos de formación VMware vSphere online sobre la tecnología de Virtualización con VMware vSphere. Después de recibir “toneladas” de emails con feedback de muchos de mis lectores pidiéndome que creara mas videos tutoriales sobre VMware vSphere, no me ha quedado mas remedio que hacerles caso.

En la actualidad ya tengo “liberados” online y gratuitamente, más de 10 episodios sobre la tecnología de virtualización de VMware vSphere.

Para ver los videos tutoriales de VMware vSphere, puedes acceder a la página general donde están todos los videos disponibles haciendo clic en el menú “Videos Tutoriales“ y seleccionando “Videos vSphere“. También puedes acceder a los videos tutoriales de VMware vSphere haciendo clic en este enlace directo.

http://www.josemariagonzalez.es/video-tutoriales/videos-formacion-vsphere

Como me pediste en tu feedback, cada Lunes liberaré un episodio que tratara sobre un tema en concreto en VMware vSphere. Espero que durante los próximos meses te diviertas viendo y siguiendo este curso de formación VMware vSphere online de la misma forma que yo me estoy divirtiendo creándolo para ti.

Estos son algunos de los videos tutoriales de VMware vSphere que ya están a disposición del público en general y que ya han visto más de 2.300 usuarios hasta la fecha.

Episodio #1: Como configurar Cisco Discovery Protocol en vSphere.

Episodio #2: Cisco Nexus 1000v Virtual Switch y Cisco Discovery Protocol.

Episodio #3: Configurando el Firewall del Service Console en vSphere.

Episodio #4: Calculando el tamaño de la base de datos en vSphere.

Episodio #5: Integrando VMware vSphere ESX 4.0 con Microsoft AD.

Episodio #6: Desmontando un DataStore NFS en vSphere 4.0.

Episodio #7: Creando un Host Profle en VMware vsphere 4.0.

Episodio #8: Creciendo un Datastore VMFS online.

Episodio #9: Configurando VMware vSphere ESXi directamente desde la consola.

Episodio #10: El backup de la configuración de VMware ESXi.

Episodio #11: Cambiando la configuración de la memoria del Service Console en VMware vSphere.

Episodio #12: Configurando Jumbo Frames en VMware vSphere.

Es posible definir resource pools a nivel de servidor VMware ESX/ESXi o a nivel de clúster VMware DRS. Sin embargo, si a la hora de crear un clúster no seleccionas la opción Enable VMware DRS, la opción de New Resource Pool estará deshabilitada.

Para poder crear un New Resource Pool en un Clúster VMware DRS, asegúrate de habilitar la opción Enable VMware DRS durante la creación de tu clúster VMware o, en su defecto, puedes habilitar dicha opción después de la creación del clúster, seleccionando el clúster con el botón derecho del ratón y seleccionando Edit Settings. Después, haz clic en Enable VMware DRS.

Los resource pools creados a nivel VMware ESX/ESXi pueden ser heredados ( grafted ) e incluidos en un clúster vSphere VMware DRS, cuando incluyes un servidor ESX/ESXi con resource pools ya creados a nivel de host, a un clúster VMware DRS.

Sin embargo, la opción por defecto cuando añades un servidor ESX/ESXi a un cluster DRS es “Put all of this host´s virtual machines in the cluster´s root resource pool. Resource pools currently present on the host will be deleted”.

Para heredar los resources de tu servidor host ESX/ESXi a tu clúster DRS, asegúrate de seleccionar “Create a new resource pool for this host’s virtual machines and resource pools. This preserves the host’s current resource pool hierarchy”.

Los resource pools heredaros serán nombrados Grafted from + nombre del servidor VMware ESX/ESXi. Si posteriormente eliminas el servidor host ESX/ESXi de tu cluster DRS, los resource pools serán “retenidos”.

No obstante, si decides desactivar la opción DRS de tu cluster, perderás todos los resource pools de dicho cluster, previo aviso eso si, y tendrias que re-crearlos de nuevo.

Esto ha sido todo, hasta la próxima semana con un nuevo tip.

El wizard de la migración en caliente, VMware VMotion, valida los requerimientos del servidor origen y servidor destino así como los requerimientos de la maquina virtual que quieres migrar.

Una máquina virtual no puede ser migrada en caliente cuando:

• La MV tiene una conexión activa a un virtual switch de uso interno.
• La MV tiene una conexión activa a un CD o disquete.
• La MV tiene configurada una afinidad a una CPU.
• La MV forma parte de un clúster Microsoft.

El wizard de migración en caliente, VMware VMotion, produce un warning cuando:

• La MV tiene una conexión a un virtual switch de uso interno pero no está conectado.
• La MV tiene una conexión a un CD o disquete pero no está conectado.
• La MV tiene uno o más snapshots.
• El servidor VMware vSphere ESX/ESXi no ha recibido un guest OS heartbeat (probablemente las VMware tools no han sido instaladas o configuradas adecuadamente).

El wizard de migración en caliente, VMware VMotion, muestra un mensaje de error si la máquina virtual no puede ser migrada desde el servidor origen al servidor destino. Sin embargo, con un mensaje de error de tipo warning, la máquina virtual puede ser migrada con VMotion sin problemas.

Asimismo, los servidores involucrados en la migración, servidor origen y servidor destino, deben cumplir los siguientes requerimientos:

• Visibilidad de todas las LUNs (FC, iSCSI, NAS) usadas por la MV.
• Una red Gigabyte Ethernet dedicada al tráfico VMotion. (En una red 10/100 también funciona pero va muchoooo mas lento. No ostante, VMware solo soporta una red Gigabyte para el trafico VMotion.
• Acceso a la misma red Ethernet física.
• El nombre de los virtual switch debe ser igual en ambos Servidores ESX (incluyendo mayúsculas y minúsculas). En VMware vSphere ESX/ESXi versión 4 update1, si los virtual switches no son nombrados iguales, el wizard de migración en caliente VMotion produce un warning pero la migración puede continuar.
• CPUs compatibles o similares (misma familia CPU). VMotion también funciona, si el servidor origen tiene Hyperthreading activado pero no el servidor destino

Seguro que se me escapan algunos requerimientos de VMotion, con lo que si no ves aquí todos, o crees que falta alguno, por favor déjame tu comentario.

VMware proporciona una utilidad llamada VMware CPU bootable Utility, la cual puedes descargar desde la propia web de VMware.

Una vez que arranques tu servidor ESX/ESXi desde CDROM con dicha utilidad, podrás comprobar si tu servidor VMware ESX/ESXI soporta las funcionalidades SSE, SSE2, NX/ED, Hyperthreading, Intel VT (Virtual Technology), AMD-V

VMware VMotion no tiene en cuenta la diferencia en la velocidad del reloj de la CPU de tus servidores ESX/ESXi, ni la diferencia en la memoria de la cache L1, L2, ni la diferencia en el numero de cores o sockets.

Asimismo VMware VMotion no tiene en cuenta las diferencias de memoria RAM entre los servidores ESX/ESXI involucrados en la migración en caliente.

La única pega que le veo a esta utilidad es que has de apagar tu servidor ESX/ESXi para comprobar que opciones y funcionalidades tiene soportado tu servidor VMware ESX/ESXi.

VMware vSphere tiene una manera muy “peculiar” de balancear el uso de ciclos de CPU física en un servidor VMware ESX/ESXi y pensé, a raíz de una discusión muy interesante iniciada por un usuario en los foros de VMware, que también te interesaría saber, mi querido lector, lo siguiente:

El VMware VMkernel dinámicamente “migra” las máquinas virtuales de CPU cada 20 milisegundos.

Para máquinas virtuales con múltiples CPU virtuales (vCPUs), el VMkernel intentara por todos los medios no poner más de un ciclo de ejecución de una misma máquina virtual en un mismo core. Sin embargo, con la tecnología hyperthreading habilitada, el scheduler del VMkernel tiene más CPUs que verificar.

El uso de la tecnología hyperthreading, permite convertir un core físico en dos – uno físico y otro lógico -, aunque esta tecnología no garantiza el doble de potencia para las máquinas virtuales, es decir, el escaldo no es lineal. Intel estima una mejora en el rendimiento de un 20%, aunque hay excepciones.

Hyperthreading suele estar deshabilitado en la BIOS del servidor físico. Mas cosas, las tareas del Service Console siempre son ejecutadas en la CPU con el ID número 0. El VMkernel nunca migrara ninguna tarea relacionada con el Service Console a otro core diferente.

Recuerda que en vSphere, una máquina virtual puede tener hasta un máximo de 8 vCPUs y ahora, el número de vCPUs puede ser impar. Aunque la máquina virtual puede usar tanto los cores físicos como los lógicos, el scheduler en VMkernel siempre intentara usar los cores físicos versus los lógicos, y siempre que hyperthreading este activado, obviamente.

Moraleja: un servidor vSphere con hyperthrering activado tendrá la capacidad de ejecutar mas threads simultáneos en paralelo (cpu fisica y cpu logica), por consiguiente, la teoría dice que el rendimiento de la infraestructura virtual seria mayor.

El VMkernel en VMware vSphere ESX/ESXi, detecta las páginas de memoria que son idénticas en todas las máquinas virtuales y asigna estas páginas de memoria RAM a la misma dirección de memoria física, con el consiguiente ahorro potencial de memoria física.

VMware VMkernel trata las páginas de memoria compartidas como páginas de memoria COW (Copy on write), lo que significa que son páginas de solo lectura cuando son compartidas y, páginas privadas cuando una de las máquinas virtuales hace algún cambio.

Esta técnica de compartición de memoria, Transparent Memory Page Sharing – de las siglas en ingles TMPS – está por defecto siempre activada, a menos que quieras deshabilitarlo manualmente, para lo que tendrás que modificar el fichero de configuración de cada una de las máquinas virtual (.vmx) donde quieras deshabilitar TMPS.

Aunque la máquina virtual no es consciente de esta técnica de ahorro de memoria, VMware estima un ahorro de hasta un 20% de la memoria física con dicha técnica en entornos homogéneos. Para entornos heterogéneos, es decir, entornos donde existen diferentes versiones de sistemas operativos en las maquinas virtuales de Windows (Windows 2000, Windows 2003, Windows 2008, etc) y las maquinas virtuales Linux (Red Hat, SuSe, Debian, etc), el ahorro de memoria física con TMPS es infinitamente menor.

Por consiguiente, para que TMPS sea efectivo, los sistemas operativos de las máquinas virtuales deben ser iguales, es decir, no solamente deben tener la misma versión de sistema operativo guest, sino que también deben incluir el mismo nivel de Service Pack (SP1, SP2, etc). Recuerda que NO es necesario hacer ningún cambio a nivel de sistema operativo guest para que la máquina virtual pueda usar esta técnica.

Asimismo, TMPS es lo que hace posible el modo overcommitted en VMware ESX/ESXi, es decir, con dicha técnica de gestión de memoria física es posible asignar mas memoria RAM a las maquinas virtuales que memoria física hay disponible en un servidor VMware ESX/ESXi, aunque por razones obvias, no es recomendable tener un servidor en modo overcommitted durante un largo periodo de tiempo.

El balloon-driver permite ceder memoria desde las máquinas virtuales al VMkernel para que este, pueda asignar dicha memoria a otras máquinas virtuales más necesitadas de memoria RAM.

Este mecanismo de compartición de memoria – balloon driver – también es conocido como vmmenctl. Cuando una maquina virtual necesita “ceder” parte de su memoria a otras maquinas virtuales, es el sistema operativo guest el que decide que páginas de memoria serán decidas ya que este conoce mejor las páginas de memoria que fueron accedidas en última instancia.

El sistema operativo guest dentro de la maquina virtual no es “consciente” de la comunicación que existe entre el mecanismo del balloon-driver y el VMkernel. No obstante, el sistema operativo guest es consciente de que el balloon-driver (vmmenctl) ha sido instalado, aunque no conoce cuál es el propósito final de dicho driver.

Así, cuando la memoria física del servidor ESX/ESXi escasea, el VMkernel elige una maquina virtual a la cual reclamara memoria RAM.

Por defecto, el VMkernel puede reclamar hasta un 65% de la memoria virtual de las maquinas virtuales durante el proceso de ballooning, siempre que estas maquinas virtuales no tengan memoria virtual reservada, en cuyo caso esta no podrá ser reclamada por el VMkernel si esta en uso.

El parámetro avanzado del VMkernel que controla cuanta memoria puede ser reclamada por esta técnica de ballooning es Mem.CtlMaxPercent y puede ser configurado hasta un total del 75% de la memoria virtual de las maquinas virtuales.

Para poder usar este mecanismo de compartición de memoria, es necesario tener instaladas las VMware tools en la máquina virtual, ya que de no tenerlas instaladas, la maquina virtual no podría usar esta técnica.

Un uso excesivo de actividad de balloon driver entre las máquinas virtuales y el VMkernel, seguido de una actividad “alta” del VMkernel swap, podría indicar que el servidor físico necesita más memoria física. Por consiguiente, el componente de memoria RAM física del servidor ESX/ESXi, podría contener un cuello de botella.

Hasta la proxima semana con un nuevo truco de VMware – mejor dicho -, hasta el próximo año.

El blog de Virtualización te desea un propero año nuevo

VMware recomienda mirar el indicador CPU Ready time para determinar si la máquina virtual tiene un cuello de botella en el componente vCPU (Virtual CPU).

Si el contador de uso de la vCPU es de un 100% (mostrado con el Task Manager en Windows), no significa necesariamente que la maquina virtual tenga un cuello de botella en la vCPU.

El siguente contador que deberias mirar es un contador de maquina virtual, CPU ready time. Si el contador de CPU Ready Time es de un 3-10 durante un periodo de tiempo prolongado (mas bien horas en lugar de segundos), es muy probable que la máquina virtual tenga un cuello de botella en la CPU.

VMware no recomienda analizar el rendimiento de una máquina virtual solo con la herramienta de Windows, Task Manager. El problema de analizar el rendimiento con solo el Task Manager de Windows, es que esta herramienta no te dara una imagen “fidedigna” de como se esta comportando la maquina virtual en cuestión, debido al conocido problema de time keeping el cual ocurre cuando virtualizamos una maquina física.

Puedes ver más información sobre el problema de time keeping en esta guía:

http://www.vmware.com/pdf/vmware_timekeeping.pdf

Cada máquina virtual que este encendida, necesita su propio fichero VMkernel swap. Este fichero permite al VMkernel, hacer un swap de la memoria RAM de la máquina virtual a disco, si la memoria física escasea. Nota que esta técnica es el último mecanismo para ahorrar memoria y que el rendimiento, tanto de la maquina virtual como del ESX, seria gravemente afectado.

Dicho fichero swap es creado cuando la máquina virtual es encendida y, es borrado cuando la máquina virtual es apagada. El tamaño del fichero swap es igual al tamaño de la memoria RAM asignada a esa máquina virtual. Por ejemplo, si asignamos un 1GB de memoria RAM a nuestra máquina virtual, el tamaño del fichero swap será de un 1GB, siempre y cuando, no asignes ninguna reserva.

En caso de reservar 256MB de memoria RAM, el tamaño del fichero swap será la diferencia entre el total de memoria asignada (1GB) y la reserva (256MB) , es decir, el tamaño de nuestro fichero swap seria 1GB – 256MB.

Por defecto, la localización del fichero swap estaría en el mismo volumen VMFS donde reside el disco virtual de la máquina virtual. La localización del fichero swap puede ser cambiada, aunque no es recomendable por VMware ya que podría afectar el rendimiento de una máquina virtual cuando se esté migrando en caliente con VMotion.

VMware Consolidated Backup se instala como un binario Windows en el directorio “C:\Program Files\VMware\VMware Consolidated Backup Framework”.

Una vez que lo hayas instalado, abre una venta MSDOS desde tu servidor y teclea el comando: vcbmounter.exe

vcbmount viene con una “infinidad” de opciones, combinaciones y flags pero las que nos ocupan en este post de hoy son las siguientes:

-h host
-u username
-p password
-t type (full backup o file backup)
-r directory

Por consiguiente, para hacer un full backup de una maquina virtual con el nombre MV_W2k y dejarla en el direcoriy c:/backup, debes teclear el siguiente comando:

vcbmounter.exe -h nombre_VirtualCenter -u administrator -p password -a name:MV_W2K -t fullvm -r c:/backup

Asimismo, si lo que quieres es hacer un backup a nivel de fichero, solo tienes que cambiar el switch “-t fullvm” por “-t file”.

Por ultimo, recuerda que VMware Consolidate Backup no es una solucion de backup per se. Es mas bien un framework el cual habilita a tu sofware de backup, integrarlo con VCB para crear así una solución de backup “aceptable” para tu entorno virtual y tus maquinas virtuales.

Muchos de los últimos emails que he recibido por tu parte, mi querido lector, han sido relacionados con las opciones de montar un software de clustering en VMware vSphere, con lo que he pensado resumir todos los email en un post.

En resumen, hay tres opciones para montar una solución de clustering con Microsoft sobre VMware vSphere ESX:

La primera opción es, el Clúster in-a-box, el cual te permite protegerte contra fallos de usuario, aplicación y sistema operativo. La idea es montar dos maquinas virtuales sobre el mismo ESX y “clusterizarlas” entre sí. Muchos de vosotros me comentáis que no tiene mucho sentido, y cierto es, ya que si el servidor ESX, el cual tiene las dos maquinas virtuales clusterizadas, se cae, perdemos todo el cluster por completo y por consiguiente, perdemos servicio.

Pero imagínate esta situación: un entorno de pruebas o demos, donde con un solo servidor y VMware vSphere ESX, podrías probar la funcionalidad de tu aplicación en un entorno cluterizado con tecnologías Microsoft (MSCS) y con una sola maquina física -ahora sí que tiene sentido, verdad?-

Configurar un cluster in-a-box con VMware, no tiene mayor complicación y está muy bien documentado en el Web de VMware. Lo único que tienes que tener en cuenta es que el Bus Sharing para el disco SCSI 0 (c:) de las maquinas virtuales ha de ser None y el Bus Sharing para el disco SCSI 1 (quorum) ha de ser Virtual. En esta opción, los discos RDM solo están soportados en modo virtual.

La segunda opción es un clúster entre ESX, el cual te protege, no solo contra fallos hardware, sino que también te protege contra fallos de usuario, aplicaciones y sistemas operativos. Recuerda que en esta configuración el Bus Sharing para el disco SCSI 0 de las maquinas virtuales ha de ser None y el Bus Sharing para el disco SCSI 1 puede ser tanto físico como virtual, aunque VMware recomienda que para esta configuración pongas tu disco RDM, el cual usaras para el disco quorum del software de clustering de Microsoft, en compatibilidad física.

La tercera opción es un clúster entre máquina física y máquina virtual, la cual te permite una solución de redundancia N+1 de bajo coste. Esta es la opción que he decidido mostrarte en la imagen adjunta del post y es muy extendida en datacenters, donde el tener una configuración de cluster N+1 es prohibitiva con relación al coste.

La opción de poder tener un servidor ESX con instancias virtuales y “clusterizadas” contra instancias físicas, repito, resulta muy útil, sobre todo cuando necesitamos reducir el coste de adquisición de tecnólogas de clustering. Te imaginas poder consolidar 4 cluster diferentes, compuestos por dos nodos por cluster -8 servidores en total-, en un clúster hibrido, compuesto por 5 nodos físicos, uno de ellos corriendo VMware vSphre, y 4 instancias clusterizadas!!! – no imagines, ya es posible.

Solo recuerda que en esta configuración, el disco quorum del cluster ha de ser un disco RDM y en modo físico.

VMware HA garantiza el re-inicio de las maquinas virtuales en caso de una caída o fallo del servidor físico vSphere ESX. VMware HA es configurado, gestionado desde el servidor de vCenter.

Antes de configurar VMware HA, deberías chequear que todas las máquinas virtuales, pueden encenderse en los nodos que vayan a formar el clúster. Recuerda que el acceso a recursos comunes como LUNs y redes virtuales para las máquinas virtuales es vital.

El 99,9% de los errores con VMware HA vienen derivados de una mala configuración del servidor DNS.

Asegúrate que tu servidor DNS funciona perfectamente y que puedes hacer ping por nombre corto, FQDN, alias y dirección IP desde todos los servidores ESX y desde el VirtualCenter.

Todos los servidores ESX que forman parte del cluster HA deben ver las LUNs donde están las maquinas virtuales. Recuerda que las maquinas virtuales que estén en discos locales de los servidores ESX, no serán restauradas en caso de failover.

Configura un teaming en la conexión del Service Console para dotar de redundancia la red de heartbeat.

Recuerda que HA no sustituye a productos de clustering como por ejemplo Microsoft Clustering Services (MSCS) ya que en VMware HA, aunque es mínimo, hay downtime de las maquinas virtuales.

VMware recomienda tener dos tarjetas de red físicas dedicadas para el control del latido del clúster (heartbeat).

Asimismo, el uplinks vmnic2 y vmnic0, en mi caso, deberían estar conectados a dos switches físicos diferentes. Esta es la única manera de no tener ningún punto de fallo, en el componente de la red.

Recuerda que no es necesario tener dos Service Conosle port, aunque si es recomendable para un clúster HA en producción.

Si te decides por la configuración de dos switches físicos con un uplink entre el switch físico y el switch virtual, debes cambiar el parámetro das.failuredetectiontime. Para cambiar este parámetro, entra en las opciones avanzadas (Advance Options) y entra el parámetro siguiente:

das.failuredetectiontime = 20000 (20 segundos)

Host failures, determina el número de fallos de tus host ESX y que tu cluster HA puede tolerar.

Admission control, es una política usada por VMware HA para asegurarse que el failover pueda ocurrir en caso de caída de uno de los host ESX.

Recuerda que aunque es posible crear VMware HA clusters de hasta 32 nodos, el host failure no puede ser mayor de 4. La razón es porque en VMware HA solo puede haber un máximo de 5 nodos con el role primario y con este setting VMware HA se asegura que siempre un nodo primario este “levantado”.

Para editar las opciones de host failures y admission control, debes de hacer clic con el botón derecho sobre el clúster y seleccionar Edit Settings:

Recuerda que el valor por defecto de Isolation Response, en VMware ESX 3.5 udpate4, es de Power Off, es decir, en caso de aislamiento de uno de los nodos del clúster (perdida del heartbeat) las máquinas virtuales se apagaran, para que estas puedan encenderse en otro nodo del clúster HA.

Restart Priory y Isolation Response son configuraciones a nivel de clúster aunque esta configuración puede también ser modificada a nivel de máquina virtual, en cuyo caso tendrá preferencia sobre el setting a nivel de clúster.