VMware vSphere 4.1: Novedades de la nueva versión de vSphere

Hace algunas semanas se lanzó el último release de VMware vSphere (versión 4.1) con importantes mejoras respecto a la versión anterior.  Esta no es una típica actualización menor de VMware, ya que considera importantes mejoras en funcionalidades existentes y agrega otras nuevas bastante interesantes.

En un articulo anterior listé algunas mejoras de esta nueva version.  En este articulo daremos una mirada más profunda en las mejoras más destacadas de esta nueva versión.

No más ESX

Una de las novedades de esta versión es que será la ultima en incluir las 2 versiones de hypervisor que actualmente provee VMware, hablamos de ESX y ESXi.  A partir del proxima actualización mayor de VMware ya no contaremos con ESX, siendo ESXi el único hypervisor que ofrecerá VMware.

Las funcionalidad y performance de ESX y ESXi son las mismas.  La diferencia entre los 2 hypervisores residen en su arquitectura y en la forma en que se administran.  ESX depende de una consola de servicio basada en Linux tanto para la ejecución de scripts, como para instalar agentes de terceros para el monitoreo de hardware, respaldo o administración de sistemas. ESXi no tiene dicha dependencia estableciendo mejoras importantes en cuanto a seguridad y confiabilidad.

Debido a que no depende de un OS de propósito general, ESXi tiene una huella o footprint ultra delgada, lo cual reduce la posibilidad de encontrar vulnerabilidades de seguridad y la necesidad de aplicar parches para reparar dichas vulnerabilidad, reduciendo de esta forma las ventanas de donwtime en nuestra plataforma virtual.  Además, esto permite que ESXi se encuentre pre-instalado en servidores x86 standard, pudiendo incluso ser instalado en una memoria USB.

Las funcionalidad de la Consola de Servicio de ESX son reemplazadas por interfaces de linea de comando remoto (RCLI), llamadas vCLI y PowerCLI.  Estas herramientas pueden ser usadas para administrar ESX y ESXi, por lo que se pueden comenzar a utilizar antes de migrar a ESXi de manera de familiarizarse con dichas herramientas.

Mejoras en el uso de la memoria.

La compresión de memoria permite comprimir las páginas de memoria compartidas entre las diferentes máquinas virtuales (transparent page sharing).   Esto permite una mejora de hasta un 30% de la performance de las maquinas virtuales, reduciendo la contención de memoria y cuellos de botella.

Mejoras en el control de los recursos de almacenamiento 

En esta nueva versión se pueden configurar prioridades de QoS para el uso del almacenamiento para cada maquina virtual, de manera de garantizar el acceso a los recursos de almacenamiento.  Adicionalmente, ahora se cuenta con estadísticas de la performance de los dispositivos de almacenamiento, sin importar que protocolo de almacenamiento se utilice.

Mejoras en el control de los recursos de red

En esta nueva versión se pueden configurar prioridades de QoS para el uso de los recursos de red por tipo de flujo, de manera de garantizar el acceso a los recursos de red existentes.  

Mejoras en la Escalabilidad

En esta nueva versión se expanden exponencialmente los limites máximos soportados por los Host ESX/ESXi y por vCenter Server.  Por ejemplo, ahora se pueden tener hasta 1.000 hosts por instancia de vCenter Server (En la versión 4.0 el máximo eran 300) y hasta 10.000 maquinas virtuales encendidas por instancia de vCenter Server (En la versión 4.0 el máximo eran 3000 VM encendidas).

Estas mejoras en la escalabilidad permiten crear nubes privadas y públicas el doble de grande que antes, con la posibilidad de correr más del doble de maquinas virtuales en un cluster, administrar hasta el triple de maquinas virtuales encendidas y hosts desde una única instancia de vCenter Server.

Para soportar este gran crecimiento, vCenter Server ahora solo puede ser instalado sobre sistemas operativos de 64 bits.  Recomiendo leer el documento actualizado de Configuraciones Máximas de vSphere.

Mejoras en la Disponibilidad y Seguridad

En esta nueva versión de vSphere se extienden las funcionalidades de disponibilidad y seguridad, permitiendo migraciones en caliente más rápidas y la capacidad de atender en paralelo cualquier operación.

Se proveen mejoras a vMotion permitiendo una velocidad de migración hasta 5 veces más rápida y permitiendo hasta 8 migraciones en paralelo.  HA por su parte trae nuevas funcionalidades de diagnostico y chequeo de salud para mejorar la disponibilidad de las maquinas virtuales.

Por el lado de la seguridad, a partir de esta versión de vSphere podremos integrar nuestros hosts con el servicio Active Directory que tengamos implementado en nuestra organización.  De esta forma se nos provee de los medios para la administración centralizada de usuarios sin la necesidad de contar con vCenter Server.  Esto nos da la posibilidad de asignar privilegios a usuarios y grupos, permitiendo ademas distribuir reglas de permisos a través de los hosts. 

Estas nuevas funcionalidad mejoran la seguridad de nuestra plataforma al poder autenticarnos contra los Hosts utilizando usuarios definidos en el mismo.  Esto ademas nos permite evitar el tener que compartir la contraseña de la cuenta Root y la necesidad de tener que crear cuentas individuales en cada uno de los servidores.

Mejoras en la Interoperatibilidad

vSphere cuenta con una arquitectura abierta e interoperable.  vSphere 4.1 permite a los partners el uso de nuevas APIs de almacenamiento para integración con los arreglos de storage, mejorando así la performance y disponibilidad.  Esto se suma a las APIs de almacenamiento y de seguridad (VMSafe) existentes.

Por otro lado, vSphere 4.1 ofrece un listado de compatibilidad de hardware (HCL) mucho más extenso, lo que permite soportar más sistemas operativos, dispositivos, aplicaciones y proveedores de servicios en comparación a otras plataformas de virtualización.

Read More

VMware vSphere: Extender un Datastore

Luego de la introducción realizada en el articulo anterior, sobre el aumento de la capacidad de un Datastore VMFS, y del procedimiento para Expandir un Datastore, a continuación detallaremos el proceso de Extender un Datastore VMFS existente.
En nuestro escenario contamos con un Datastore creado sobre una LUN de 150GB. Adicionalmente se ha creado una nueva LUN de 150GB la cual utilizaremos para Extender nuestro Datastore. Esta LUN adicional no debe contar con una particion VMFS existente, de lo contrario no podrá ser utilizada para Extender nuestro Datastore.

Proceso de Extender un Datastore

	En la lista de Datastores que se encuentran visibles para un host ESX/ESXi, podemos ver nuestro Datastore de 150GB de capacidad.
	Luego de atachar una nueva LUN en nuestro Host, de 150GB, y realizar un Rescan de los Datastore en el host, podemos utilizar el espacio disponible para Extender nuestro Datastore.
	Hacemos click derecho sobre el Datastore y seleccionamos la opcion "Propiedades"
	A continuación vemos el tamaño de nuestro Datastore (150GB) y la capacidad maxima de la LUN donde se encuentra el Datastore (150GB). Hacemos click en el boton Increase
	A continuación vemos la LUN que creamos recientemente, de 150GB y que aparece identificada como LUN 5. Notar que la columna "Expandable" debe decir "No". Seleccionamos dicha LUN y hacemos click en "Next"
	A continuación nos muestra un resumen del Layout de la nueva LUN, indicando el espacio disponible para poder Extender nuestro Datastore. Podemos notar que el asistente nos indica que la LUN se encuentra en blanco. Hacemos click en "Next" para continuar.
	A continuación seleccionamos el tamaño adicional que se utilizará para Extender el Datastore. El tamaño maximo es mostrado por defecto. Seleccionamos el tamaño que utilizaremos y hacemos click en Next para continuar.
	A continuación nos muestra un resumen del tamaño en que quedará nuestro Datastore (300GB). Se detallan tambien los Extents que componen nuestro Datastore. Hacemos click en Finish para completar el proceso.
	En las propiedades del Datastore podemos ver que ahora la capacidad total es de 300GB, utilizando todo el espacio disponible en los Extents que forman nuestro Datastore. Podemos ver además que nuestro Datastore esta compuesto por dos Extents, cada uno de 150GB. Hacemos click en Close para terminar
	En la lista de Datastores que se encuentran visibles para un host ESX/ESXi, podemos ver ahora que nuestro Datastore tiene una capacidad de 300GB.

Con esto ya tenemos el procedimiento detallado para aumentar la capacidad de nuestro Datastore, ya sea Expandiendolo o Extendiendolo.

Read More

VMware vSphere: Expandir un Datastore

Luego de la introducción realizada en el articulo anterior, sobre el aumento de la capacidad de un Datastore VMFS, a continuación detallaremos el proceso de Expandir un Datastore VMFS existente.
En nuestro escenario contamos con un Datastore creado sobre una LUN de 100GB, la cual fue luego expandida a una capacidad de 150GB en el arreglo de Storage, por lo que actualmente nuestro Datastore puede ser expandido para utilizar la capacidad completa de la LUN.

Proceso de Expandir un Datastore

	En la lista de Datastores que se encuentran visibles para un host ESX/ESXi, podemos ver nuestro Datastore de 100GB de capacidad. Luego de aumentar la capacidad de la LUN en el Storage y realizar un Rescan de los Datastore en el host, podemos utilizar el espacio disponible.
	Hacemos click derecho sobre el Datastore y seleccionamos la opcion "Propiedades"
	A continuación vemos el tamaño de nuestro Datastore (100GB) y la capacidad maxima de la LUN donde se encuentra el Datastore (150GB). Hacemos click en el boton Increase
	A continuación vemos la LUN donde se encuentra nuestro Datastore, donde se muestra la columna "Expandable" indicando que que existe espacio disponible para expandir nuestro Datastore. Que esta columna indique "Yes", quiere decir que un Datastore esta utilizando esta LUN y que tiene un espacio libre adyacente. Seleccionamos dicha LUN y hacemos click en "Next"
	A continuación nos muestra un resumen del Layout actual de la LUN, indicando el espacio disponible para Expandir el Datastore. Notar la capacidad actual de nuestro Datastore (100GB) y la capacidad libre disponible (50GB). Hacemos click en "Next" para continuar.
	A continuación seleccionamos el tamaño adicional que se utilizará para Expandir el Datastore. El tamaño maximo es mostrado por defecto. Seleccionamos el tamaño que utilizaremos y hacemos click en Next para continuar.
	A continuación nos muestra un resumen del tamaño en que quedará nuestro Datastore. Nosotros seleccionamos expandir nuestro VMFS al tamaño maximo de la LUN, por lo que aqui veremos que nuestro Datastore utilizará ahora los 150GB disponibles. Hacemos click en Finish para completar el proceso.
	En las propiedades del Datastore podemos ver que ahora la capacidad total es de 150GB, utilizando todo el espacio disponible en la LUN. Hacemos click en Close para terminar
	En la lista de Datastores que se encuentran visibles para un host ESX/ESXi, podemos ver ahora que nuestro Datastore tiene una capacidad de 150GB.

En el siguiente articulo veremos el proceso para agregar un Extent a nuestro Datastore de manera de extender su capacidad.

Read More

VMware vSphere: Aumentando la capacidad de un Datastore

En este articulo hablaremos de las tecnicas de Extend y Expand para aumentar el tamaño de un Datastore en VMware vSphere.
Cuando se necesita crear una nueva VM sobre un datastore, o cuando una VM en un Datastore requiere mas espacio, se puede aumentar dinamicamente la capacidad de un datastore VMFS. Aumentar el tamño de un volumen VMFS te permite contar con más espacio o posiblemente mejorar la performance. Existen dos formas de aumentar el tamaño de un datastore VMFS:

• Agregar un Extent a un volumen VMFS.
  
  
  
  • Esta caracteristica permite agregar dinamicamente un nuevo Extent a un datastore VMFS.
  • Un Extent es una particion sobre una LUN
  • Se puede agregar un nuevo Extent a un datastore VMFS existente, pudiendo un Datastore estar compuesto por hasta 32 Extents.
• Expandir un Datastore VMFS.
  
  
  
  • Esta caracteristica permite expandir dinamicamente un Datastore VMFS en la particion donde esta localizado.
  • Solo Datastores con espacio libre inmediatamente despues de estos son expandibles.
  • Si una LUN tiene más capacidad de la que ha sido configurada en una particion VMFS, gracias a que la mayoria de los arreglos de storage modernos pueden agregar capacidad expandiendo una LUN dinamicamente, permitirá que esta particion VMFS sea expandida para utilizar todo el espacio disponible en la LUN.
  • En vez de agregar un nuevo Extent, se puede aumentar el tamaño del Datastore para utilizar toda la capacidad disponible en la LUN donde se encuentra el Datastore.

Comparando metodos para aumentar la capacidad de un Datastore.

	Expandir un Datastore	Agregar un Extent a un Datastore
Estado de la Maquina Virtual	Encendida	Encendida
Nuevas LUNs aprovisionadas	No	Si
Limites	Un Datastore puede ser expandido cuantas veces se requiere hasta alcanzar 2TB-512B de tamaño	Un Datastore puede tener hasta 32 Extents, cada uno de hasta 2TB-512B
Nueva particion	No	Si
Impacto en la disponibilidad de las VMs	Ninguno si el Datastore tiene solo un Extent.	Introduce dependencia en el primer Extent

De este cuadro podemos concluir lo siguiente:

• No hay necesidad de apagar las VM cuando se aumenta el tamaño de un Datastore, ya sea con un Expand como agregando nuevos Extents.
• Si se crea una nueva LUN, no se puede expandir el Datastore, pero se puede extender el datastore para utilizar el nuevo espacio disponible (Extent)
• Al Expandir un datastore no se crean nuevas particiones, en cambio al utilizar nuevos Extents se crean nuevas particiones.
• Al utilizar Extents existe una dependencia del primer Extent, debido a que este contiene la metadata para el conjunto completo de Extents. Si la LUN que contiene el primer Extent se pierde, podria causar la perdida de toda la data en un conjunto completo de Extents.

El metodo que se elija para aumentar el tamaño de un Datastore VMFS depende de lo que se quiera lograr. De todas maneras se debe tener en cuenta que es recomendado, para efectos de balanceo de carga, tener varios Datastore pequeños, a tener un unico Datastore de gran tamaño que incluya todas las maquinas virtuales.

En el siguiente link hay un interesante articulo que discute sobre Expandir o Extender un Datastore para aumentar la capacidad de este:
http://professionalvmware.com/2009/01/to-extend-or-not-to-extend-that-is-the-question/

A continuación detallaremos el proceso para aumentar la capacidad de un Datastore utilizando ambos metodos:

• Expandir un Datastore
• Extender un Datastore

Espero que esta información les sea de utilidad, y cualquier pregunta no duden en consultar.

Read More

VMware ESX/ESXi: Buenas practicas con Snapshots.

Algunas buenas practicas respecto a los Snapshots en VMware ESX/ESXi. Esto aplica para hosts ESX/ESXi 3.x y 4.x.
Buenas Practicas

• Snapshots no son respaldos! Como un archivo de Snapshot es solo un registro de cambios del disco virtual original, no se debe confiar en un Snapshot de la misma forma en que se confia en un Backup para realizar restauraciones. La maquina virtual está corriendo sobre el ultimo Snapshot, no sobre los archivos VMDK originales.
• La cantidad maxima soportada de Snapshots en una cadena es de 32, sin embargo VMware recomienda utilizar no más de 2 o 3 Snapshots en una cadena.
• No utilice un Snapshot por más de 72 horas. Se recomienda su uso por no más 24 hrs.
  
  
  • Esto evita que los Snapshots crezcan demasiado, lo cual puede provocar complicaciones a la hora de borrar un snapshot o hacer un "Commit" de este en el disco virtual original. La recomendación es tomar el Snapshot, realizar los cambios requeridos sobre la maquina virtual y finalmente hacerle un Commit al Snapshot tan pronto como como se haya verificado el correcto funcionamiento de la maquina virtual.
  • Hay que tener especial cuidado con el uso de Snapshots en una maquina virtual altamente transaccional, tal como un servidor de correo o de base de datos. Estos Snapshots pueden crecer en tamaño de manera muy rapida, pudiendo llenar el espacio del Datastore. Hacer un Commit del Snapshot en la maquina virtual tan pronto como se haya verificado el correcto funcionamiento del proceso que se haya estado probando.
• Si se está utilizando algún producto de terceros que toma ventaja del uso de Snapshots (como soluciones de respaldo de maquinas virtuales), se recomienda monitorear constantemente los sistemas configurados para respaldos, de manera de asegurar que no queden Snapshots remanentes por periodos extensos de tiempo.
  
  
  • Los Snapshots debieran estar presentes solo durante la duración del proceso de respaldo.
  • Los Snapshots tomandos por una solución de terceros (a través de la API) podrian no ser visibles en el vCenter Snapshot Manager. Se recomienda chequear los Snapshots a través de la linea de comandos de manera regular.
• Un numero excesibo de Snapshots en una cadena, o Snapshots muy largos en tamaño pueden degradar la performance de la maquina virtual y del host que la hospeda.
• Configurar alarmas automatizadas de vCenter Server para gatillarlas cuando una maquina virtual se esté ejecutando desde un Snapshots.
• Confirmar que no hay Snapshots presentes (a través de la linea de comando) antes de realizar una operación de Storage vMotion. Si hay Snapshots presentes, estos deben ser borrados antes de realizar un Storage vMotion. Migrar una maquina virtual con Snapshots a otro Datastore podria causar perdida de datos y hacer que la maquina virtual quede inservible.

Para mayor información acerca de los Snapshots en VMware utilice los siguientes links:

• Understanding virtual machine snapshots in VMware ESX (1015180)
• Working with snapshots (1009402)
• Seccion de uso de Snapshots en la Basic System Administration Guide de ESX

Para ver el articulo completo, dirijase al articulo KB 1025279 de VMware.

Read More

vCenter Converter: Hot Cloning de un servidor Linux

En este articulo, detallaremos el proceso de migración en caliente o Hot Cloning de un servidor Linux utilizando vCenter Converter Standalone (vCenter Converter Enterprise no suporta la migración en caliente de un servidor Linux). El proceso en si es bastante sencillo, pero he visto muchas dudas respecto al uso de la Helper VM Network, lo que en muchos casos puede llevar a que el proceso de migración no sea exitoso.

Primero una pequeña introducción.
vCenter Converter Standalone facilita la interoperatibilidad entre los siguientes productos:

• Productos VMware pueden ser usados como origen y destino de una conversión con Converter Standalone.
  
  
  • VMware Workstation
  • VMware ACE
  • VMware Fusion
  • VMware Server
  • VMware Player
• VM corriendo sobre ESX/ESXi que sea o no administrado por vCenter
• Restauración de imagenesde VM hechas con VCB.

vCenter Converter Standalone consiste de un cliente, un servidor y un agente. El cliente puede correr en un equipo separado, pero el Servidor y el Agente de Converter Standalone deben siempre correr en el mismo equipo. De esta forma se puede administrar Converter Standalone de forma local o remota.

El cliente Converter Standalone envia los requerimientos de conversión al Servidor. El Servidor gestiona los requerimientos y los envia al agente mientras que el agente Converter Standalone ejecuta la tarea de conversión.

Converter Satandalone crea una VM basada en el servidor fisico de origen. El proceso de migración no es destructivo por lo que se puede seguir utilizando el servidor fisico luego de la conversión, teniendo cuidado con los conflictos de IP y nombre de equipo que pueden existir.

Converter Standalone solo permite realizar migraciones en caliente o Hot Cloning. Hot Cloning realiza la clonación del servidor de origen mientras este esta ejecutandose, por lo que permite una clonación sin tener la necesidad de apagar el servidor.

Cuando se crea una migración en caliente, la VM resultante no es una copia exacta del servidor de origen, debido a que los procesos continuan en ejecución en el servidor de origen durante la conversión. Esto es especialmente critico si se van a migrar servidores de Bases de Datos u otros sistemas transaccionales. De todas maneras se puede configurar Converter Standalone de manera de sincronizar el servidor de origen con la VM creada despues de la migración. Esto se realiza transfiriendo los bloques que fueron cambiados durante el periodo de clonación, luego de que los servicios sean detenidos por el Converter Standalone.

Para información más detallada respecto a como trabaja vCenter Converter Standalone, refierase a la documentación oficial de VMware.

Proceso de Clonación

A continuación detallaremos el proceso de migración en caliente de un servidor Linux..

	Ingresamos a vCenter Converter Standalone e ingresamos la IP servidor de Converter, junto con las credenciales apropiadas.
	Una vez dentro de la consola de Converter, presionamos el boton "Convert Machine" lo cual iniciará el asistente para la migración.
	A continuación seleccionamos el tipo de servidor de origen, pudiendo ser un servidor fisico, una VM sobre ESX, Workstation u otro producto VMware, una imagen de respaldo de una VM (Ej. VCB, Acronis, etc.), una VM de terceros (Virtual PC, MS Virtual Server, Parallels, etc.) o un Virtual Appliance. En nuestro caso seleccionamos la primera opción. A la derecha podremos ver un cuadro con los Sistemas Operativos soportados. Este cuadro variará dependiendo de la opción de servidor de origen que hayamos elegido.
	A continuación ingresamos la IP o FQDN del servidor a virtualizar, junto con las credenciales de root o administrador. Finalmente seleccionamos la familia de Sistema Operativo, en nuestro caso Linux. Hacemos click en Next para continuar.
	A continuación seleccionamos el destino donde se creará la VM virtualizada. Esto puede ser un Host ESX/ESXi o una instancia de Virtual Server o vCenter Server. En nuestro caso seleccionamos un host ESX e ingresamos las credenciales con los permisos suficientes.
	A continuación, seleccionamos el host de destino o el Resource Pool donde ubicaremos la VM. Del mismo modo, seleccionamos un nombre para la VM y un Datastore donde se almacenarán los discos virtuales. Hacemos click en Next para continuar.
	A continuación nos mostrará un resumen de la configuración de la VM a crear a partir del servidor fisico. En este punto nos debemos detener para personalizar el proceso de migración. En primer lugar hacemos click en Edit, a la derecha de "Data to copy"
	A continuación podemos seleccionar que volumenes de discos vamos a migrar, a la vez que podemos redimensionar los volumenes para agregar o quitar espacio.
	Si seleccionamos la vista "Advanced", además podremos seleccionar en que Datastore se creará cada volumen, pudiendo ubicar los distintos discos virtuales en Datastores separados. En este punto además podemos cambiar el tipo de disco de manera de utilizar Thin Provisioning si asi lo deseamos.
	A continuación editamos la configuración de dispositivos. Aqui podemos seleccionar el numero de procesadores virtuales, el controlador de discos a utilizar y la memoria disponible para la VM.
	A continuación editamos la configuración de Red. Aqui podemos seleccionar el numero de adaptadores de red a utilizar por la VM, asi como la red a la que se conectará cada adaptador. Finalmente seleccionamos si cada adaptador estará o no habilitado.
	A continuación editamos las propiedades avanzadas. En este punto podemos configurar si la VM será encendida al terminar la migración y si el servidor fisico será apagado en el mismo momento. Si el sistema operativo es Windows XP o posterior, tendremos la posibilidad de seleccionar la opción de sincronizar los cambios que ocurren durante el proceso de migración, asi como personalizar las preferencias de la VM. Esto no aplica para Linux. Del mismo modo podemos seleccionar la opción de instalar las VMware Tools como parte del proceso de migración. En mi caso esto no aplica ya que estoy realizando el procedimiento sobre una VM con las tools ya instaladas.
	A continuación configuramos las opciones de la Helper VM Network. Cuando se convierte un servidor Linux, Converter crea una Helper VM en el host de destino. Esta VM necesita acceso de red al servidor de origen y al host de destino para realizar la conversión. Por defecto esta VM obtiene su IP automaticamente por DHCP, pero si esto no esta soportado en tu red debes configurar la red manualmente.
	A continuación se deben agregar sufijos DNS para la resolución de nombres. Hacemos click en Next para continuar.
	A continuación vemos un resumen de la configuración seleccionada. Si todo esta OK, hacemos click en Finish para comenzar la migración.
	Mientras se está realizando la migración, verás la maquina creada en el host seleccionado de la siguiente forma.
	A medida que la migración avanza, veremos que Converter nos muestra el avance de la migración, asi como el tiempo restante.
	Una vez completada la tarea, lo veremos de la siguiente forma en Converter.
	Al mismo tiempo, en el host de destino seleccionado veremos la maquina creada luego de la migración. Como podemos ver, la VM tiene la IP que seleccionamos al configurar la Helper VM Network. Si queremos que esta VM reemplace completamente al servidor de origen utilizado en el proceso de migración, debemos configurar la VM con la IP del servidor de origen. Esto luego de haber apagado el servidor de origen para evitar conflictos de IP y nombre de servidor.

De esta forma ya tenemos migrado nuestro servidor Linux, pudiendo realizar el proceso en caliente y practicamente sin Downtime.

Como siempre, si tienen cualquier consulta, no duden en preguntar!!!

Read More

VCP-410, Examen aprobado!!!

Y bueno, después de un par de semanas estudiando bastante y durmiendo poco, este viernes por fin aprobé el examen para la certificación VCP-410!!!  Logré un puntaje de 475 de un máximo de 500, lo que me deja más que feliz =)

Para los que esten interesados en certificarse, hay muy buenos materiales de estudio para preparar el examen.  Como base hay que apoyarse en la documentación oficial VMware que es recomendada en el Exam Blueprint para VCP.

Yo además me apoye en el libro Mastering VMware vSphere 4 de Scotte Lowe, el cual explica de manera muy detallada y didactica todos los componentes de VMware ESX/ESXi y vCenter Server.  Es un excelente material de estudio para preparar el examen.

No olvidar que es requisito obligatorio asistir a un curso oficial de VMware para obtener la certificación. En mi caso, yo asistí al curso "VMware vSphere: Install, Configure, Manage" dictado en Fast Lane.

Y finalmente, y quizás lo más importante, es la practica que uno tenga implementando y configurando VMware ESX/ESXi y vCenter.  Yo tengo 3 años de experiencia implementando y configurando ESX/ESXi 3.x y 4.x, así como Virtual Center 2.5 y vCenter 4.x, lo cual redujo en gran medida las horas necesarias en estudiar para el examen.

Y para quienes quieran practicar para el examen, pueden utilizar el vSphere  4 Mock Exam.

Read More

VMware vSphere 4.1: Issues luego de migrar vCenter Server

En general, la migración de vCenter Server a la versión 4.1 no genera mayores complicaciones, sin embargo se han reportado algunos problemas los cuales hasta ahora no tienen una solución "oficial" de parte de VMware.

1) Luego del Upgrade a la versión 4.1 de vCenter Server, se produce un error en el Converter Health Status en la sección vCenter Services Status. No obstante este error no impide el normal funcionamiento de vCenter Converte ni otra funcionalidad de vCenter Server. Hasta ahora no ha habido una solución oficial a este problema.
Este error esta reportado en las comunidades de VMware en el link http://communities.vmware.com/thread/276101 y se mantiene sin solución hasta ahora.

Actualizado: Este error ha sido solucionado luego de la publicación del KB-1025010.

2) Luego del Upgrade a la versión 4.1 de vCenter Server se han presentado fallas en los agentes HA en los hosts pertenecientes a un cluster HA. En mi caso este problema se produjo en hosts con versión ESXi 4.0. Los hosts con versiones ESX 3.x y superior no me produjeron problemas luego del upgrade de vCenter.
Para este segundo issue hay dos formas de solución, una más intrusiva que otra. A continuación el detalle para cada una:

• Opción 1
  
  
  
  • Deshabilitar HA en el cluster HA afectado
  • Esperar a que HA sea removido desde todos los hosts en el cluster
  • Re-habilitar Ha en el cluster.
• Opción 2
  
  
  
  • Deshabilitar HA en el cluster HA afectado
  • Poner el host en modo de Mantención
  • Remover el host del cluster
  • Remover el host de vCenter Server (removerlo, no solo desconectarlo). Esto es necesario para que se desinstale el agente vCenter
  • Conectarse a la consola del host (Al ser ESXi esto debe ser con acceso directo al servidor).
  • Resetear la configuración del sistema a sus valores por defecto y dejar que el servidor se reinicie
  • Reconfigurar la password Root y la red de administración.
  • Agregar el host a vCenter
  • Configurar el host (Red, seguridad, etc.)
  • Agregar el host nuevamente al cluster, lo que restaurará el agente HA.

La opción más sencilla y menos intrusiva es la opción 1, sin embargo no a todos les ha funcionado según lo reportado en la siguiente discusión en las comunidades VMware: http://communities.vmware.com/message/1570813. En mi caso particular, la opción 1 no me fue de utilidad, por lo que tuve que ejecutar el proceso indicado en la opción 2, lo cual es basicamente reconfigurar un ESXi desde cero. Quizas esto se pueda ver facilitado con la funcionalidad de Host Profile de vCenter 4.x.

Esperemos que pronto haya algún articulo oficial de VMware que nos permita solucionar ambos issues de una manera menos intrusiva.

Read More