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

VMware ya publicó en su sitio la actualización de los valores máximos y mínimos para la versión vSphere 4.1. Para recordarles un poco, los máximos y mínimos generalmente son utilizados A) para dar la certificación de vmware VCP (VMware Certified Profesional), B) para realizar el correcto sizing de una solución de virtualización.

En esta nueva publicación, ya adentrada en la versión 4.1, vemos que se reflejan los nuevos cambios a nivel escalabilidad de vcenter y de ESX.

Les paso los más interesantes:

Hosts per vCenter Server: max 1000

Powered on virtual machines per vCenter Server: max 10000

Registered virtual machines per vCenter Server: max 15000

Concurrent vSphere Clients: max 100

Number of host per datacenter : max 400

Hosts per cluster: max  32

Virtual machines per cluster: max 3000

Virtual machines per host: max 320

LUNs per server: max 256

Fuente| VMware Máximos y Mínimos de vSphere 4.1

–

Ing. Diego Quintana vEXPERT 2010 VCP – VAC – VTSP

Como les contamos en el post anterior, vmware lanzó vsphere 4.1, y en el día de hoy anunciaron oficialmente la salida de vCenter Site Recovery Manage 4.1 .

Bajo la brand vCenter, Site Recovery Manager 4.1 busca simplificar cada vez más el diseño e implementación de los sitios de contengiencia basado en  la tecnología de virtualización VMWare. Como vExperts y Partnes de VMware tuvimos acceso a la Beta y en principio ya estamos preparando una review con capturas de pantalla para que puedan conocer como es el producto.

Mientras tanto les dejamos las principales características de SRM 4.1 :

Sistema Operativo

• Site Recovery Manager 4.1 es compatible con vCenter 4.1  y solo corre bajo Windows 64 bits.

Disaster Recovery Management

• Creación y administración de los planes de recuperación directamente desde la consola de vCenter.
• Mejoras en la extensión de los planes de recuperación utilizando scritps.
• Monitoreo de la disponibilidad del sitio remoto.
• Almacenar , ver y reportar los resultados de las pruebas de fail over directamente desde el vCenter.
• Manejo del plan de recuperación basado en roles de control de acceso.

Test Non Disrruptivo

• Utilización de  la tecnología de snapshots de los storage para realizar pruebas sin perdida de información.
• Conexión de maquinas virtuales a redes aisladas entre sí para realizar pruebas especificas.
• Ejecución de planes de prueba automáticos.

Networking

• Soporte a Distributed Switches en los sitios secundarios.

Para aquellos que quieran saber mas información les dejo el link a las releases notes.

En breve estaremos haciendo una review de SRM 4.1  y lees taeremos detalles y capturas de pantallas de esta nueva versión.

Saludos

Ing. Diego Quintana vEXPERT 2010 - VCP – VAC – VTSP

VMware lanzó la nueva versión de vSphere 4.1 y junto a este lanzamiento también encontramos novedades imporantes en terminos de licencias como de features nuevos.

Extraído del sitio original de vmware, a continuación les pasamos el detalle de que incluye y que no incluye las nuevas licencias de vmware.

Para aquellos que quieran compararlo con la versión 4.0, les dejo el post con la revisión de las licencias anteriores.

Al ver el nuevo gráfico de licencias pueden verificar que HA y VMotion están en la versión standard, mientras que Fault Tolerance (FT) ahora es parte del advanced.

Sin lugar a dudas, el cambio beneficiará a muchos más usuarios que antes y califico personalmente como un gran acierto el ofrecer vmotion y HA a los usuarios de vmware.

Si tienen dudas o desean comprar licencias de vmware, pueden contactarnos aquí.

Ing. Diego Quintana vEXPERT 2010 VCP – VAC – VTSP

El viernes 9 de Abril de 2010, VMware publicó el  VMSA-2010-0007 (alerta de seguridaD), que se encuentra catalogada como una actualización de alta criticidad dadas las múltiples vulnerabilidades encontradas en varios de sus productos.

A continuación haremos una breve descripción de la publicación.

Resumen de los productos alcanzados

• VMware ESXi 4.0 anterior al patch ESXi400-201002402-BG
• VMware ESXi 3.5 anterior al patch ESXe350-200912401-T-BG
• VMware ESX 4.0 sin los patches ESX400-201002401-BG,ESX400-200911223-UG
• VMware ESX 3.5 sin el patch ESX350-200912401-BG
• VMware ESX 3.0.3 sin el patch ESX303-201002203-UG
• VMware ESX 2.5.5 sin el Upgrade Patch 15.
• VMware Workstation 7.0,
• VMware Workstation 6.5.3 o anteriores,
• VMware Player 3.0,
• VMware Player 2.5.3 o anteriores,
• VMware ACE 2.6,
• VMware ACE 2.5.3 o anteriores,
• VMware Server 2.0.2 o anteriores,
• VMware Fusion 3.0,
• VMware Fusion 2.0.6 o anteriores,
• VMware VIX API para Windows 1.6.x,

Definiciones de los problemas encontrados

• Windows-based VMware Tools Unsafe Library Loading vulnerability
• Windows-based VMware Tools Arbitrary Code Execution vulnerability
• Windows-based VMware Workstation and Player host privilege     escalation
• Third party library update for libpng to version 1.2.37
• VMware VMnc Codec heap overflow vulnerabilities
• VMware Remote Console format string vulnerability
• Windows-based VMware authd remote denial of service
• Potential information leak via hosted networking stack
• Linux-based vmrun format string vulnerability

Para todos aquellos que tengan alguna de las versiones anteriores descriptas y necesiten asistencia para aplicar dichas actualizaciones, no duden en ponerse en contacto con nosotros.

Fuente | vmware - VMSA-2010-0007 VMware hosted products, vCenter Server and ESX

.

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

La configuracion de alarmas para conocer los distintos eventos que se presentan sobre la infraestructura virtual, sin necesidad de estar continuamente frente a la consola de administracion, es una de las practicas mas importantes para contar con una gestion proactiva de la plataforma.

En las ultimas versiones de Virtual Center y vCenter Server, se han observado mejoras en las funcionalidades de las alertas.

Si creamos una nueva alarma o editamos una de las existentes, podemos ver que lo primero que se debera ingresar es qué tipo de objeto vamos a estar monitoreando.

El tipo de objeto a monitorear y el tipo de variable o evento a monitorear definira el tipo de Alarma o Alarm Type

Luego se deben identificar los triggers, que son los disparadores de cada alerta, es decir la condision de las variables correspondientes al tipo de alarma seleccionada, que al cumplirse  ejecuta una accion deseada.

Estos triggers podran depender de si se trata de una condision relacionada a un cambio de estado o una metrica de performance de algun tipo, y de acuerdo a esta seleccion existen dos familias de eventos a ser capturados. Luego cada una podra tener distintos tipos de valores y parametros.
Por ultimo, de acuerdo a la accion, se dispararan eventos de comunicacion de la alarma (mediante el envío de mails o mediante el envío de traps snmp) o acciones de objetos de la infraestructura, como podra ser el apagado de un equipo, el encendido de otro, etc.

Estos se configuran a traves del tab Actions, en el caso de ejemplo es un simple envio de correo electronico.

Para detalles extra ver el post de Consejos para el envio de alertas por email

Espero les sirva!

Saludos,

Leandro Santoro

Respetando la estrategia de dar empuje a la API de vStorage anunciada junto con el lanzamiento de la linea vSphere, VMware anuncia el End of Life de VMware Consolidated Backup, la herramienta y conjunto de scripts que permitía el respaldo de maquinas virtuales, y archivos contenidos en éstas.

Esta noticia confirma la posicion de VMware de promover el uso de sus APIs por parte de terceros y la utilizacion de la herramienta de Data Protection para los ambientes donde ésta pueda cubrir las espectativas de los clientes.

A continuacion el anuncio:

Announcing End of Availability for VMware Consolidated Backup

	Dear Valued Customer, The purpose of this letter is to inform you of our vSphere backup product strategy, ongoing enhancements, and end of availability plans for VMware Consolidated Backup. VMware Backup Product Strategy VMware released vStorage APIs for Data Protection (VADP) with the vSphere 4.0 release in May, 2009. VADP is the next generation of VMware’s backup framework. We have also been working with several backup partners to integrate VADP into their solutions to make backup of vSphere Virtual Machines fast, efficient and easy to deploy compared to VCB and other backup solutions. Several of our major backup partners have already released VADP integrated backup products and we expect most of the major backup partners to have VADP integrated backup software by the upcoming feature release of the vSphere platform in 2010. Future Product Licensing Given the strong interest and adoption of VADP by our backup eco-system and the benefits offered by VADP compared to VMware Consolidated Backup (VCB), we are announcing the End of Availability for VCB starting with next vSphere feature release in 2010. Starting with the next vSphere platform feature release, VCB will be removed from vSphere platform. VADP integrated backup products (including VMware Data Recovery) will be the recommended option for efficient backup and restoration of vSphere Virtual Machines. This will allow us to focus new value added feature development on VADP instead of two backup frameworks (VCB and VADP). You can find more information about the use of vStorage APIs for Data Protection in our Developer Community. For information on the availability of VADP integrated release of your backup product please contact your backup vendor. End of Availability With the release of the next vSphere platform, we will continue to provide the binaries for VCB, but they will not be compatible with the next platform release. We will continue to provide support for VCB on the current vSphere platform per the VMware support policy. If you need assistance in the migration from VMware Consolidated Backup to the vStorage APIs for Data Protection, please contact your local reseller or storage backup vendor. Best regards, VMware Product Management

Fuente: vmware.com (link)

Leandro Santoro

La sincronización de información y la aplicación de cambios de configuración que se realizan mediante el vCenter sobre los ESX se realizan por medio de un usuario especial en cada uno de los ESX. Se trata del vpxuser, usuario unix local de los ESX que trabaja al mismo nivel que la cuenta root de estos.

Un dato importante al momento de encarar el aspecto de seguridad de los ESX, es la importancia de no realizar cambios sobre la cuenta vpxuser de cada ESX, ya que los atributos de dicha cuenta, como ser el password, son determinados en el momento de la incorporacion del host ESX a la infraestructura de vCenter. Esto se realiza justamente mediante el wizard de Add Host dentro de una estructura de datacenter.

A modo de ejemplo, a continuacion se muestra el comportamiento de dos ESX que fueron manipulados erroneamente mediante un cambio de password de la cuenta vpxuser luego de haber sido sumados a la infraestructura de vCenter.

Como ven, ambos figuran como desconectados y arrojan eventos de falla en la sincronizacion.

Error:

Cannot synchronize host <hostname>. Cannot complete login due to an incorrect user name or password.

Con solo realizar la desconexion y volver a conectar los hosts  se soluciona el problema ya que se vuelve a configurar automaticamente la cuenta vpxuser. Esto se realiza mediante el menu del ESX, opciones Disconnect y Connect respectivamente.

Tener en cuenta que este proceso de reconfiguracion solo es posible debido a que para la conexion del host debe ingresarse una cuenta root y su correspondiente password.

Como practica recomendada para los casos de segurizacion de los ESX recomendamos que si bien la cuenta root puede ser ensobrada y realizarle cambios de password periodicos sin impactar en la inraestructura, en cambio, la cuenta vpxuser debera ser siempre dejada a un lado de estos protocolos para que sea solo manipulada internamente por el proceso de reconexion, evitando impactos importantes en el comportamiento de la infraestructura virtual.

Espero les sea de utilidad.
Muchas Gracias!

Leandro Santoro

1. Descargar los siguientes scrips según la Base de Datos utilizada:
   • Para Microsoft SQL Server  utilizar  create_alarms_mssql.sql.
   • Para Oracle Database utilizar  create_alarms_oracle.sql.
2. Realizar un Back up de la base de datos y bajar el servicio de vCenter Server.
3. Abrir un query analyzer y ejecutar el script.

Detalle para Microsoft SQL Server:

1. Loguearse a la base de datos SQL con el mismo usuario del ODBC usado para el vCenter Server.
2. En el Microsoft SQL Server Management Studio, ingresar a Databases y luego a la Base_de_datos_del_Vcenter
3. Clic derecho y  New Query.
4. En el  query editor,  hacer copy y paste del contenido del script create_alarms_mssql.sql.
5. Presionar F5 para correr el script.
6. Inciar el Servicio de vCenter Server.

1. Bajar el servicio de vCenter Server
2. Usar sqlplus, loguearse a la base de datos con el mismo usuario de conección usado por el vCenter hacia la BD.
3. Tipear @ \create_alarms_oracle.sql
4. Ejecutar enter para correr el script.
5. Inciar el servicio de vCenter

Listo.

Las alarmas por Default ya quedarón nuevamente creadas.

Saludos.

Ref: KB Article: 1010399

________________________

Ing. Diego Quintana

VCP-VTSP-VSP-VAC