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

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

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

En el día de hoy se reporto un warning en el sitio oficial de vmware donde se comunica que no se actualicen a ESX 4.0 U2 a aquellos clientes que tienen VMWare VIEW 4.0 usando como protocolo PCoIP.
Si bien vmware ya está trabajando directamente en encontrar la falla, se recomienda no actualizar hasta no encontrar el motivo y la forma de resolver el issue.

Les dejo el link a la KB de vmware http://bit.ly/aWaxB9

Saludos
Ing. Diego Quintana

vExpert 2010- VCP 410/310 – VAC -VTSP

La mayoría de profesionales de IT que han pasado por la virtualización han dudado en algún momento si virtualizar o no un servidor/ servicio.

Hoy me  encontré con el caso en el que me consultaron si les recomendaba separar en dos servidores un servicio dirigido a Microsoft Project Server. Para aquellos que no conocen, Microsoft Project Server requiere de un servidor de base de datos y otro para la gestión de la aplicación en si misma, y la duda existía si realmente convenía o no separar en dos máquinas virtuales (una para la base de datos y la otra para el framework) de manera de asegurar una adecuada performance.

Para dar una respuesta concreta tenemos que detenernos en el siguiente punto, cada maquina virtual que coloquemos requiere una licencia de sistema operativo, y por más obvio que esto parezca, si por el mero hecho de evitarnos un problema de performance empezamos a crear maquinas virtuales, seguramente nos veamos peor que en un criadero de conejos, duplicando la cantidad de trabajo que tendremos que hacer día a día (parches de seguridad, etc) como hasí también estamos haciendo incurrir en un gasto de licencia adicional innecesario a la compañía.

Recordemos que cuando se virtualiza es excelente momento para consolidar servidores y aplicaciones, de esta manera, si la empresa ya tiene servidores de base de datos potentes u osciosos, creo que la mejor alternativa es calcular la demanda de cpu, memoria, disco y red  que tendrá esa base de datos, y subirla al motor existente.

De esa manera obtendremos el beneficio de que el administrador de bases de datos realice las tareas de mantenimiento correspondientes (backup, shrink, etc).

Si la base de datos es poco demandante, con  más razón valdrá la pena consolidarla, o caso contrario pueden utilizar el mismo servidor de project para ambos caso y así ahorrar una licencia.

Si el servidor demandará muchimos recursos, en ese caso será una buena decición ponerle un motor dedicado con un calculo de memoria, cpu, disco y red acertado para tal fin.

Conclución: No nos olvidemos que somos responsables de IT y del diseño de la infraesctructura, donde  diseñar no se trata de hacer que todo funcione bien solamente, sinó que se debe hacerlo haciendo uso responsable de los recursos tanto económicos como físicos del datacenter.

—-

Autor.

Ing. Diego Quintana  

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

El pasado primero de Febrero de 2010, nuestros amigos de xtravirt (empresa dedicada a virtualización) publicó de forma gratuita su plugin de microsoft remote desktop (RDP) para vmware vsphere client.

Por más trivial que parezca, el plugin es sumamente útil para aquellos administradores que día a día utilizan más de 50 o 100 máquinas virtuales y tienen que tomar control remoto de ellas para administrarlas.

El principal motivo para utilizar este plugin es justamente que acceder por el modo consola en VMware no es una de las mejores practicas sugeridas por VMware dado que  consume una importante cantidad de recursos en las másquinas virtuales y en el service console del ESX, ni hablar si hay varios administradores conectados y olvidan las sesiones de consola abiertas.

Por otro lado nos agiliza las tareas del día a día evitando tener que abrir dos o tres aplicaciones para gestionar nuestros servidores.

Sin lugar creo que será una tendencia creciente la de incorporar pequeños plugins que nos facilitaran un poco la existencia.