ESX

VMware salió con los tapones de punta a Hyper V de Microsoft ofreciendo vSphere Essential Plus 4.1 Kit el cual viene dotado de uno de los features que más premios le dió a la empresa de Palo Alto, efectivamente  hablamos de que incluye de serie VMotion.

Ahora si VMware se posiciona fuertemente en entornos pequeños de manera de que nadie “quiera” mover sus soluciones de ahí. Digo quiera, porque la verdad que con todo lo que incluye el kit de VMware Essential Plus 4.1 es realmente una solución por demás completa.

Repasemos los features de esta versión:

• 3 licencias para VMware ESXi o VMware ESX
• VMFS (Virtual Machine File System)
• 4-way Virtual SMP
• VMware vCenter Server Agent
• VMware vStorage APIs / VMware Consolidated Backup (VCB)
• VMware Update Manager
• VMware High Availability (HA)
• VMware Data Recovery
• VMware vCenter Server for Essentials (maneja hasta 3 ESX)
• VMware vMotion

Siendo del todo sinceros, si tenemos HA y VMotion, me parece que su precio es más que atractivo. Imaginen lo que cuesta el pago de horas extras por tareas programadas, solo usando vmotion se pueden evitar hasta el 90% de ellas. Ya con eso, las empresas lograrán justifican cada centavo de lo que vale la licencia.

Diego Quintana

Fuente | Sitio Oficial VMware

Consiguelo en| Wetcon Partner Enterprise de VMware

El último release de VMware vSphere (versión 4.1) además de traer la noticia de que esta es la última versión en incluir las dos versiones del hypervisor (ESX y ESXi) y algunos dudas y preocupaciones por parte de sus usuarios con respecto a lo que se viene en cuanto a sus infraestructuras virtuales, esta versión de VMware no es una típica pequeña actualización ya que vienen incluidas unas cuantas mejoras y funcionalidades nuevas más que interesantes:

Integración de VMware ESX/ESXi

A partir de esta versión del hypervisor podremos integrar nuestros servidores físicos con el servicio de directorio que tengamos implementado en nuestra organización pudiendo de esta forma validarnos en el hypervisor utilizando usuarios definidos en el mismo evitando tener que compartir la contraseña de la cuenta de root o bien tener que crear cuentas individuales en cada uno de los servidores.

Instalación por medio de scprits de VMware ESXi

Esta nueva funcionalidad nos permite automatizar la instalación de nuestros servidores ESXi en el disco local de nuestros servidores contando con varias opciones para realizar las mismas como por ejemplo inicio por medio de PXE (Preboot Execution Environment) o montando el CD en el drive local del servidor y accediendo al archivo de configuración del mismo por medio de la red. Este archivo de configuración permite ejecutar comandos PRE/POST, first boot e incluso contar con opciones como agregar el host a un vCenter Server.

Compresión de memoria

La compresión de memoria permite comprimir las páginas de memoria compartidas entre las diferentes máquinas virtuales por medio de transparent page sharing. Con esta función se gana performance ya que trabajar con la memoria compartida comprimida y montada en memoria es mucho más performante que bajar estas páginas de memoria a disco.

Mejoras en el soporte de consola local de ESXi

En las versiones anteriores de ESXi para acceder a la consola local teníamos que ingresar el comando "unsupported" dándonos una idea de donde estabamos trabajando. A partir de esta versión podemos acceder a la consola directamente de forma local o bien de forma remota por medio de SSH pudiendo habilitar estos accesos tanto desde la consola del VMware ESXi como desde el VMware vCenter Server.

Mayor escalabilidad

A partir de esta versión podemos llegar a tener hasta 3000 máquinas virtuales por cluster, 10000 máquinas virtuales encendidas (15000 registradas) por vCenter Server por este motivo es que a partir de esta versión y para garantizar la escalabilidad de los entornos el vCenter Server correrá únicamente sobre sistemas operativos de 64 bits.

Control de carga sobre servicios de almacenamiento y red

Esta es la primer versión de hypervisores de VMware en contar con control y distribución de carga de storage y red lo cual aumenta las funcionalidades del servicio de VMware DRS (Distributed Resource Scheduler) acercándonos a un mayor control en la calidad de servicio brindada por la infraestructura Virtual.

En fin, no es una actualización menor… que vendrá para la versión 5 del producto?

Nicolás Solop

Seguime en Twitter

Hyperic (empresa adquirida por VMware en 2009 y sumada a la división de Spring Source) anunció la disponibilidad inmediata de la versión 4.4 de su solución de monitoreo y gestión de plataforma la cual incluye mejoras sustanciales para la gestión de ambientes virtuales basados en VMware vSphere. Gracias a esta nueva integración Hyperic mantiene actualizado el inventario de la plataforma virtual de los hosts ESX/ESXi permitiendo a los administradores de tecnología encontrar y resolver problemas de performance sin importar si estos ocurren en ambientes virtuales, físicos o en nubes privadas o públicas.

¿Qué problemas resuelve la versión 4.4 de Hyperic?

Esta nueva versión del producto fue desarrollada en base a los requerimientos de los clientes y usuarios de la aplicación con el objetivo de garantizar funcionalidades acordes con las necesidades reales de los mismos. Para esto el equipo de desarrollo tomó básicamente dos puntos sobre los cuales trabajar, primero el despliegue de aplicaciones custom en ambientes virtuales y segundo el mantenimiento de la infraestructura virtual de estas aplicaciones el cual cambia constantemente ya sea con una demanda mayor o con una demanda menor de acuerdo a los requerimientos de uso de los usuarios finales de estas aplicaciones. Las aplicaciones de monitoreo “legacy” que no incluyen funcionalidades de virtualization-aware cuentan con grandes problemas de “visibilidad” de puntos de demanda de aplicaciones debido al dinamismo de las nuevas infraestructuras.

Hyperic 4.4 resuelve los siguientes problemas en la versión Enterprise de su producto:

• Diagnóstico rápido de problemas de performance de aplicaciones

• Mantenimiento automático de la infraestructura de aplicaciones

• Alertas virtualization-aware

La experiencia

En 2006 Hyperic desarrolló la primer solución de monitoreo de performance de aplicaciones sobre ambientes virtuales VMware ESX y VMware GSX cubriendo las siguientes funcionalidades que se mantienen en la versión 4.4 del producto:

• Garantía de migración de aplicaciones a ambientes virtuales
• Resolución de problemas automática
• Monitoreo de ambientes y virtuales y consolidación de logs y eventos

Con el lanzamiento de VMware vSphere 4.1 y toda la movida que trajo de actualizaciones de muchos de los productos relacionados me tomé el trabajo de analizar un poco las release notes de VMware Converter 4.2  ya que me encuentro en estos momentos en medio de un proyecto de virtualización de unos cuantos equipos físicos dentro de los cuales hay una gran variedad de equipos Linux en todas sus formas y colores.

Para mi sorpresa en las release notes de VMware Converter 4.2 encontré esta declaración:

The VMware vCenter Converter 4.2 is a substantial upgrade from vCenter Converter 4.1 and includes the following new functionality (previously found only in vCenter Converter Standalone 4.0.x):

• Physical to virtual machine conversion support for Linux sources including:

  • Red Hat Enterprise Linux 2.1, 3.0, 4.0, and 5.0

  • SUSE Linux Enterprise Server 8.0, 9.0, 10.0, and 11.0

  • Ubuntu 5.x, 6.x, 7.x, and 8.x

Esto es muy bueno ya que Ubuntu va ganando terreno paso a paso en las empresas y tener una herramienta que nos permita importarlos dentro de un ambiente virtual es algo que se necesitaba hace un tiempo largo ya.

Nicolás Solop

Muchas veces mientras trabajamos con implementaciones de VMware con muchos hosts físicos nos encontramos con que en algunos casos mientras ejecutamos pruebas de funcionalidades como VMotion y DRS nos encontramos con errores que no nos esperábamos.

En el caso de hoy les presento un caso de un cluster donde no podíamos realizar VMotion de ningún servidor virtual de un equipo al otro y llegando al 10% del proceso de migración en caliente nos arroja el error:

Migrate virtual machine
test_1
A general system error occurred: Failed to start migration pre-copy. Error 0xbad004b.
Connection reset by peer.

Luego de investigar un poco el tema y de no encontrar problema de colectividad por medio del comando vmkping entre los dos nodos físicos involucrados decidimos comenzar a revisar el resto de los servidores físicos involucrados.

Encontramos que otro de los servidores tenía configurada la misma dirección IP de VMkernel que uno de los servidores involucrado en la tarea de VMotion anterior. Luego de modificar la dirección IP por una correcta el proceso finalizó correctamente.

No es la primera vez en la que me encuentro con problemas para ejecutar VMotion y en muchos casos la forma de resolverlos no es la misma por lo tanto voy a ir armando una lista de problemas/soluciones y una guía de troubleshooting de VMotion!.

Slds!

Nicolás Solop.

Dentro de las mejores prácticas de VMware se recomienda el testeo del correcto funcionamiento de la memoria RAM de los servidores que correran VMware vSphere por al menos 72 horas.

La idea de esta verificación es asegurarnos que la memoria física que utilizaremos no presenta errores de lectura/escritura lo cual nos permitirá trabajar de forma confiable sobre la plataforma y nos ayudará en un futuro en caso de producirse algún tipo de problema en la misma.

En los cursos oficiales de VMware se recomienda el uso de la herramienta memtest de memtest.org el cual es un software de uso libre disponible en internet en la página web www.memtest.org

Este producto realiza un escaneo de memoria RAM a bajo nivel, de manera de detectar errores de hardware ó errores lógicos.

Es recomendable que Memtest sea ejecutado y dejarlo trabajar durante al menos 24 horas para asegurar que la memoria se encuentra en excelente estado.

A continuación se detalla el procedimiento para descarga y ejecución de MEMTEST .

Esperamos les sirva.

Saludos cordiales,

Nicolás Solop

Únete al grupo de virtualización en español en LinkedIn

En algunos casos los archivos de configuración de las máquinas virtuales (archivos de extensión .vmx) se corrompen o en otros casos algunas manos mágicas los eliminan. Si tenemos la suerte de que nuestros archivos de disco (archivos de extensión .vmdk) siguen donde deberían podemos realizar los siguientes pasos para que volver a la vida a nuestra máquina virtual:

1. Ingresar a la infraestructura virtual con un usuario con privilegios de administrador

2. Hacer clic derecho sobre uno de los servidores ESX

3. Dar clic sobre Create New Virtual Machine

4. Clic sobre Custom Virtual Machine

5. Seguir todo el procedimiento hasta llegar a la ventana donde pide seleccionar el disco

6. Dar clic sobre Use Existing Disk y buscar en los datastores el archivo .vmdk indicado

7. Continuar con el procedimiento hasta finalizarlo

Luego de esto podremos encender la nueva máquina virtual y tendremos todos los datos de la anterior disponibles.

Espero les sirva.

Saludos,

Nicolás Solop

Únete al grupo de virtualización en español en LinkedIn

Enfrentando una actualización de equipamiento y sumado a que estaba trabajando en preparar una serie de documentos sobre optimización y performance sobre vSphere, he necesitado realizar sucesivas tareas de VMotion en nuestra granja de ESX (8 servidores corriendo vSphere 4 Enterprise Plus) y me he encontrado con la necesidad de aumentar la cantidad de VMotions simultaneos que podía hacer el vCenter.

Cuando o porque configurar esta opción?, si tenemos un DRP en linea, les aseguro que esta puede ser una excelente ocación.

Para ello hay que recordar que si desean realizar este Tweak al vCenter, deberán tener en cuenta que tienen que tener configurado al menos dos placas Gigabit en Etherchannel o conexión a 10 Gpbs, también será ideal conocer algo sobre networking sobre VMware.

El motivo?.  Utilizar ese tipo de configuración será la unica forma real de poder sacar verdadero provecho de multiples vmotions dado que la demanda de red es realmente alta. Es así como también es  recomendado habilitar JUMBO FRAMES para las placas involucradas en el VMkernel portgroup.

• Ahora bien, para empezar, deberán ingresar al vCenter.
• Abrir el archivo vpdx.cfg ubicado en  - C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter -
• Editar las siguientes lineas

<ResourceManager>
<maxCostPerHost>16</maxCostPerHost>
</ResourceManager

• Salvar los cambios
• Tipear en START > RUN > SERVICES.MSC
• Reiniciar el servicio -VMware VirtualCenter Server -
• Listo, ya está configurado el vcenter para soportar hasta 4 VMotions en simultaneo.

Ahora bien, que es ese 16 ?, la respuesta la da VMware, la ponderación que se realiza en vCenter para utilizar la funcion Migrate se encuentra definida del 1 al 4, siendo 1 la migración en modo COLD, y el 4 en modo HOT (o sea VMOTION).

Para soportar 4 Vmotions en simultaneo multiplicamos (4 vmotions) x ( 4 tareas) = 16 (valor final en el archivo vpxd.cfg).

De esta manera su virtual center está preparado para realizar mas de un vmotion en simultaneo, ahora bien pueden configurar este parametro hasta poder optimizar la maxima velocidad que su red les permita, Tengan principal consideracion en separar el trafico y segundo separar las NICS FISICAS si es que optan por valores superiores a 4.

Si necesitan una mano, no duden en consultarnos.

Saludos

Ing.Diego Quintana

VCP310-VCP410-VAC-VTSP

Tal como dice el refrán, una imagen vale más que mil palabras, mas aún si hablamos de una imagen real capturada de un centro de cómputos donde implementamos VMware Sphere 4 y View.

Acostumbrados a ver las presentaciones de VMware donde hablan de la gran densidad de maquinas virtuales por core, o sobre la magia del overcommit de memoria, creo que es bueno compartir una captura de pantallas de un escenario de la vida real donde se alcanzan ratios de 56 a 1 sobre ESX 4 utilizando INTEL Xeon 5540 (Nehalem) sobre un Proliant BL460c G6.

Las máquinas virtuales corren windows XP  con 1vCpu – 1GB de memoria Ram y la infraestructura de virtualización sobre servidores blades.

Para alcanzar los ratios antes descriptos es necesario realizar el dimensionamiento adecuado y diseñar la solución considerando cada uno de los componentes de la misma, Storage, Networking, Seguridad y su administración.

Sin lugar a dudas hoy VMware es el líder en su segmento y con este tipo de imágenes queda claro el porqué.

Luego de 18 meses de investigación y desarrollo conjunto entre ingenieros de VMware y de Mitel lograron derribar la barrera de la latencia producida por la virtualización entregando de esta forma la primer solución de virtualización de voz del mercado.

La combinación de la virtualización junto con los productos de Mitel como el Mitel Communications Director permite a las empresas que cuenten con sus centros de datos virtualizados hacer uso de las nuevas versiones de producto de Mitel en forma virtual reduciendo consumo eléctrico espacio y tareas de administración.

El desarrollo de ambas empresas tiene como objetivo permitir a sus clientes la consolidación de aplicaciones de voz junto con aplicaciones estándar en una misma plataforma esperando como resultado mejoras en la productividad, una utilización de los recursos eficiente y la disponibilidad de las tecnologías de voz incluso en casos de contingencia.

El problema de la virtualización de la voz

El desarrollo para aplicaciones estándar (no de tiempo real) siguió su propio curso con el correr de los tiempos pero al intentar virtualizar aplicaciones en tiempo real como la voz es extremadamente complejo debido a la latencia inyectada por la capa de virtualización.

La plataforma de virtualización soportada para correr las soluciones de voz de Mitel al día de hoy es VMware vSphere ESX 4.

Sobre Mitel: Mitel es líder en la provisión de soluciones de comunicación unificada para organizaciones de todos los tamaños.

Más información en el comunicado de prensa: Mitel and VMware Announce First Customers to Leverage Voice Virtualization

 
Nicolás Solop

Únete al grupo de virtualización en español en LinkedIn