Archive for February, 2010

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

El 25 de Febrero de 2010, VMware anuncia el lanzamiento de una nueva actualización de VMware Update Manager, esta vez hacia la version 4 Update 1 Patch.

Update Manager 4 Update 1 Patch 1

Evidentemente Microsoft tiro la primera piedra y ahora todos arrojan la suyas, tenemos un release que está en Versión 4 en Update 1 y en Patch 1 ??? cual será el siguiente paso ?, me parece que sería  bueno que VMware comience a ajustar sus tornillos en materia de QA, porque como ya vimos antes, tuvieron problemas con el procedimiento para actualizar de ESX 4 a ESX 4 Update 1a, y además  porque tienen mucho protagonismo en los datacenters corporativos como para andar tan distraídos, más aún cuando hablamos de un software que  justamente se dedica a aplicar parches.

Este Patch, soporta el escaneo y remediación de los siguientes HOST y VMS:

Host patching
ESX 3.5 or later
ESX 3i or later
ESX 3.0.3

Host upgrade
ESX 3.0.0 or later
ESX 3i or later

Virtual Machine Scanning and Remediation

Windows XP Professional, 32 bit, SP2 Required
Windows XP Professional 64 bit
Windows 2003 Datacenter
Windows 2000 Server, SP4 with Update Rollup 1
Windows 2000 Professional, SP4 Required
Windows Server 2003, SP1 Required
Windows Server 2003 R2
Windows Server 2003 x64
Windows Server 2003 Standard/Web, 32-bit and 64-bit
Windows Server 2008
Windows Vista Business
Windows Vista Enterprise
Windows Vista Business (x64)
Windows Vista Enterprise (x64)

Virtual Machine Scanning

Red Hat Enterprise Linux AS 3.0 (Update 5 Required)
Red Hat Enterprise Linux ES 3.0 (Update 5 Required)
Red Hat Enterprise Linux AS 4.0 (Update 2 Required)
Red Hat Enterprise Linux ES 4.0 (Update 2 Required)

Application Scanning and Remediation:

Internet Information Server (IIS)
Windows Media Player, version 7.0 or later
Microsoft SQL Server versions 7.0/2000/2005
Microsoft SQL Server Desktop Edition (MSDE) version 1.0 or later
Exchange 2000 Server and Exchange Server 5.0
Internet Explorer version 4.0 or later
Outlook Express version 4.01 or later
Microsoft Site Server 3.0
ISA Server 2000
Microsoft .NET Framework, version 1.0 or later
Microsoft Data Access Components (MDAC) 2.5 or later
BizTalk Server 2000 or later
SNA Server 4.0
Host Integration Server 2000
WinZip 8.1 or later
Apache 1.3 and 2.0
Firefox 1.0 or later
RealPlayer 10 or later
Adobe Acrobat Reader

En el siguiente link podrán descargarse toda la información sobre el Vmware Update Manager 4 update 1 patch 1.

Saludos

En cuanto a las alertas por eventos sobre la infraestructura, cabe resaltar algunas consideraciones en cuanto al envío por e-mail de estas, ya que existe un punto importante a tener en cuenta sobre la configuracion y se trata de la necesidad de habilitar el relay de smtp desde el equipo donde se encuentra instalado el vCenter. Esto salta a la vista cuando vemos que los únicos campos que pueden ser llenados durante la configuración de envío son dirección de origen de los mails y nombre o ip del servicio smtp.

Para acceder a esta configuracion, ir a Administration -> vCenter Server Settings

Luego seleccionar el SMTP Server y el Sender Account

Luego desde cada alerta configurada se podra seleccionar el destinatario del mail, por ejemplo en la siguiente:

De esta manara, habra que gestionar desde el lado de configuracion del servidor de correo electronico, que la cuenta de origen sobre el SMTP tenga permisos para realizar Relay.

Otro detalle a tener en cuenta es la cantidad de alertas que por default estan configuradas con el evento de envío en Repeat, lo que hace que se envien grandes cantidades de emails cada vez que ocurre algun disparo de alarma, conllevando en ocaciones a situaciones tediosas de borrados de email, lo que a largo plazo suele traer como consecuencia que el receptor comience a tomar la llegada de los mails como algo molesto y deje de prestarles atencion; o lo que es peor, configurar que estos mails no toquen el inbox. Debido a esto es altamente recomendable configurar las alertas en las instancias iniciales de una implementacion (lo que ayuda a conocer los detalles de comportamiento de la plataforma) y en la medida justa (evitando que se convienta en algo molesto)

Espero les sea de utilidad,

Saludos,

Leandro Santoro

Instalando unos nuevos servidores con VMware vSphere ESX 4.0 Update 1 encontramos que luego del primer reboot en la consola del servidor nos apareció el error:

Initialization for vmfs2 failed with -1

Luego de investigar un poco encontramos que estos equipos no estaban siendo configurados con una dirección IP fija y que tampoco estaban comando una dirección del servidor DHCP de manera correcta y en el service console luego de algunos minutos aparecia el error:

ALERT: Init: 1586: Invalid vmkernel id: 0. Distributed vmfs locking may not work.

Intenando iniciar el módulo vmfs2 por medio del comando vmkload_mod -l tampoco iniciaba relacionamos el tema a la falta de configuración IP, hostname y servidores DNS en el equipo ya que los distributed locks son identificados por su correspondiente VMkernel ID el cual se basa en la dirección IP del service console del equipo.

Luego de configurar el service console de forma manual con el comando esxcfg-vswif y de reiniciar el equipo el error no volvió a aparecer y no encontramos más problemas en los servidores.

Más info en While Booting an ESX Server 3.x System, Distributed vmfs Locking Might Not Work.

Espero que les sirva.

Saludos,

Nicolás Solop

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

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

Luego de mucho de lo que se viene cuestionando acerca de la falta de complementos para la plataforma de virtualización de desktops de VMware (View), finalmente el gigante de la virtualización definió en el día de hoy la compra de RTO Software.

Segun el comunicado oficial emitido por el VMware, la adquisición de RTO Software tiene como principal propósito el de complementar la suite de VMware view con herramientas que permitan fortalecer la gestión del desktop, mejorar la performance y optimizar la presentación de las máquinas virtuales a los usuarios.

Tal como indican en el articulo, RTO pasará a ser parte del equipo técnico de VIEW, y sus productos serán discontinuados dado que los mismos serán parte de los futuros releases de VMware View.

Los principales productos que hoy dispone RTO son:

Virtual Profiles – Plataforma dedicada a manejo de profiles de usuarios y eliminación de corrupción de datos y mejoras de performance de login.

PinPoint – Manejo de performance de aplicaciones orientadas a Citrix.

Discover – IT assets management.

TScale – Manejo y optimización de memoria para aplicaciones de terminal server.

Solo nos quedará por esperar para esta futura integración, dado que la semana pasada vmware liberó el update 1 de VMware view 4.

Saludos,

Ing. Diego Quintana

VMware por medio de su sitio de VMWARE PRODUCT LIFE CYCLE SUPPORT hace público el listado de los productos que actualmente están fuera de soporte y de aquellos productos que están cerca de estarlo.

Por eso, para aquellos que hoy tienen productos VMware y necesitan verificar si la version que tienen instalada está por quedarse sin soporte, pasen por aquí y podrán verificarlo de manera sencilla.

Los productos más conocidos que entraron en EOL son:

Por alguna duda sobre otro producto que no vean en el sitio de vmware, no duden en consultarnos!.

Saludos

Diego Quintana

De acuerdo a comentarios de varios asistentes al VMware Partner Exchange 2010 se verían varias novedades interesantes en el próximo release de VMware vSphere como ser compresión de memoria, gestión de recursos de I/O y mejoras en el desempeño de VMotion.

Por defecto en la actual versión de VMware vCenter Server podemos ejecutar únicamente 2 procesos de VMotion en simultáneo y un máximo de 6 realizando modificaciones de parámetros en los archivos de configuración del vCenter Server. En el próximo release del producto podríamos llegar a un total de 8 procesos de VMotion en simultáneo de forma nativa.

VMware DRS (Dynamic Resource Scheduler) nos permite realizar en la actualidad un balanceo de carga de trabajo basado únicamente en la carga de memoria y CPU que nuestras máquinas virtuales aplican sobre nuestros servidores físicos pero se estima que en el nuevo release del VMware vCenter Server podríamos realizar este balanceo incluyendo también variables como I/O por máquina virtual y la definición de límites y prioridades de acceso a disco por medio de la tecnología IO-RM (IO- Resource Management).

Para finalizar con Transparent Memory Compression el Hypervisor (VMware vSphere) realizará compresión de memoria en caliente para incrementar la cantidad de memoria que aparenta estar disponible para una máquina virtual determinada. Esta tecnología será de gran interes en ambientes donde la carga de trabajo presenta grandes consumos de memoria en lugar de ciclos de CPU como es en la mayoría de los casos en los que estuvimos trabajando en Wetcom.

Tendremos que esperar algunos meses (un año?) para conocer si realmente estas tecnologías serán aplicadas ya que versiones de las diferentes licencias de VMware vSphere aplican.

Nicolás Solop.

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

Tags: VMware vCenter, VMware vSphere, virtualizacion