En el segundo Podcast #2 de Wetcom, los vExperts Nicolás Solop y Diego Quintana debaten sobre los beneficios de migrar desde VMware ESX hacia VMware ESXi.

Conocé cuales son los desafíos técnicos para la migración,  mitos sobre el nuevo hypervisor y todos los pros y contras de hacer el cambio.

Seguí a Nicolás Solop (@nsolop) y a Diego Quintana (@daquintana) en Twitter!.

Hace ya unos meses VMware anunció la actualización de VMware vSphere 4.1 la cual incluye unas cuantas mejoras en cuanto a prestaciones y algunos cambios sobre las existentes. A los pocos días también anunció varias actualizaciones de sus productos complementarios como VMware Site Recovery Manager y VMware View sumándoles la compatibilidad con la nueva versión de su producto central vSphere.

Uno de los puntos claves del primer anuncio es la aceptación formal por parte de VMware de que la versión 4.1 es la última versión en incluir ambas versiones de su Hypervisor ESX y ESXi. Este tema se venia discutiendo hace tiempo de forma informal con empleados de VMware locales y con usuarios de la tecnología en el grupo de Virtualización en Español que creamos en Linkedin.

La principal preocupación de muchos de los usuarios es como vamos a comenzar a trabajar de forma definitiva con esta tecnología y cuales deberían ser los puntos a tener en cuenta a la hora de comenzar con la migración de la tecnología VMware ESX hacia VMware ESXi. Muchos coincidimos en que a la hora de trabajar directamente sobre el cliente de administración de VMware (vSphere Client) prácticamente no existian diferencias entre trabajar sobre uno u otro de los modelos de Hypervisores pero la historia cambiaba si hablabamos de trabajar sobre la línea de comandos provista.

Desde un comienzo la consola de comandos de ESXi en las versiones anteriores a la 4.1 uno debía typear "unsupported" para acceder a la misma lo cual nos daba una idea de donde nos estabamos metiendo pero en la versión 4.1 ya tenemos en la terminal amarilla tan característica de ESXi la opción de habilitar y acceder a la consola de comandos lo cual nos muestra una pequeña evolución.

De todas formas con ganar acceso a la consola no es suficiente ya que no todos los comandos y opciones están implementados en la misma y no tenemos más opción que recurrir al VMware vMA el cual tiene implementado, por medio de API’s propias de VMware, la posibilidad de gestionar la plataforma virtual de VMware desde la linea de comandos ya sean interactivos o por medio de scripts. Sabiendo esto resolveriamos uno de los puntos que nos frenaban para comenzar a trabajar con ESXi pero existen algunos factores más a tener en cuenta que son muy importantes.

Por ejemplo tenemos aplicaciones de terceros que corrian sobre nuestras infraestructuras ESX por ejemplo nuestros agentes de la UPS o bien los agentes de software de monitoreo. Funcionarán sobre ESXi? tendremos las mismas funcionalidades? cómo se deberán implementar?. Estas preguntas en muchos casos no son nuevas pero la mayoría sigue sin respuesta o sin una respuesta oficial por lo que VMware y sus socios tecnológicos deberán realizar un trabajo muy fino de integración y utilización de las API’s provistas por VMware para garantizar que este cambio que con el tiempo tendremos que hacer forzadamente no sea un dolor de cabeza.

Otro de los puntos importantes a tener en cuenta son las funcionalidades similares que tienen ambas versiones del Hypervisor y entender que mucho de lo que se dice del ESXi de VMware son solo mitos.

Para cerrar la idea en muchos menos renglones… esto no va a ser simplemente instalar un ESXi, hacer un VMotion a otro equipo físico, instalar ESXi en el equipo vacio y distribuir la carga.

Nicolás Solop

Seguime en Twitter

vSphere ESX y ESXi 4.1 traen incorporado una nueva característica denominada Memory Compression.  Sin lugar a dudas esta nueva carácterística ayuda a optimizar el uso de la memoria ram de nuestros host basados en ESX, sin embargo hay que aclarar que utilizar memory compression no es ni lo más performante pero tampoco es lo peor, simplemente es un estadío intermendo que tiene el ESX antes de enviar las páginas de memoria al ballooning cuando nuestro host se encuentra sin memoria.

Por defecto, memory comnpression se encuentra activado, es decir que no necesitan configurar nada para que este comienze a funcionar, sin embargo, si por motivos particulaes, desean deshabilitarlo, deben ingresar a:

ESX > SYSTEM CONFIGURATION > ADVANCED SETTINGS > MEM

allí buscaremos el valor

Mem.MemZipEnable

y comprobaremos que el mismo está en 1 (activado), para desactivarlo deberemos colocarlo en 0.

Así mismo, podemos customizar los valores de porcentage de memoria caché que querremos utilizar, para ello elegimos las siguientes opciones:

Mem.MemZipMax.Pct

Por medio de este valor, podemos configurar la cantidad máxima (en porcentage) de caché comprimida de memoria por VM.

Ahora bien, en las graficas de Performance no se encuentra activa la vista de Memory Compression, para poder visualizarla deberán ingresar al menú PERFORMANCE > CUSTOMIZE PERFORMANCE CHART > MEMORY y activar COMPRESION RATE (memdido en KBps).

Con estos tips ya tienen todo lo referido a como habilitar, deshabilitar y visualizar los datos referidos a memory compresión en un ESX, pero es importante tenér en cuenta que todo lo que modifiquen a este nivel, impactar á de manera positiva o negativa en la performance de sus VMs, por lo cual es recomendable que los valores estén por default salvo que el soporte de VMware o un especialista les recomiende lo contrario.

Saludos,

Ing. Diego Quintana vEXPERT 2010 – VCP-VTSP

Por tercera véz consecutiva se realiza el Virtualization Forum Argentina 2010, conocido como el principal evento de virtualización de Latino América.
Conocé junto a Wetcom, Gold Sponsor, los nuevos anuncios en materia de cloud computing, seguridad, disponibilidad y virtualización de desktops, de la mano del mayor proveedor de soluciones de virtualización.

Así mismo, te invitamos a reunirte en el Stand con nuestros vExperts para discutir cada uno de estos lanzamientos y cual será el futuro de la virtualización.

No olvides, registrarte, la cita es el 14 de Octubre de 2010.

En varias ocasiones puede suceder que tengamos que enviar a un syslog externo nuestros logs de ESX o ESXi, el requerimiento generalmente proviene del sector de seguridad informática que es el área responsable de hacer el análisis de los mismos para detectar posibles anomalias o intentos de acceso a nuestro host.

También puede suceder que los necesitemos como metodo de detección de alertas o warnings.  Para todos estos casos en aquí esta la respuesta.

1. Primero hacemos Login en nuetro Servidor ESX o ingresamos a travéz del vCenter.
2. Seleccionamos el servidor ESX
3. a nuestra izquierda seleccionamos el panel Configuration
4. Seleccionamos a nuestra derecha y abajo Advanced Settings
5. En la ventana emergente seleccionamos la opción Syslog
6. En el segundo campo Syslog.Remote.Hostaname debemos completar con el nombre del servidor de syslog
7. Luego debemos especificar el port del servidor remoto
8. Listo, tiempo de verificar si nuestro ESX está reenviando los logs

VIA | Wetcom . Como enviar los logs de vSphre ESX / ESXi a un Syslog Server Externo

Diego Quintana

VCP-vEXPERT

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

.