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

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.

Como es ya es conocido, está liberado al publico google android para pcs, con el objetivo de ser probado por la comunidad de desarrolladores y por los usuarios finales. De esta manera google empieza a avanzar firme en la carrera por fidelidaz al usuario móvil sobre su sistema operativo.

Para instalar android en una maquina virtual en VMware workstation o VMware ESX, podrán armar una configuración básica como la siguiente:

Colocar como sistema operativo ubuntu.

Luego montar la ISO bajada de Aquí.

Cuando inicia el SO, carga la pantalla de bienvenida. El proceso de booteo no demora más de 10 sgs.

Nos alertará de la falta de carga de batería, esto es normal dado que es una emulación de un móvil.

Listo, tenemos acceso al desktop de Android, ahora dado que la placa de red está en modo bridged, deberían navegar sin inconvenientes dado que el sistema operativo detecta la placa  perfectamente.

Probemos como se vé www.wetcom.com.ar en el browser de Android.

Sin estár en caché, el sitio tardó 1 sg en cargar, tiempo más que sorprendente.

Luego si hacemos clic en ESC saldremos al desktop. A la derecha está el acceso al panel de aplicaciones.

Si accedemos al panel de control de android podemos cambiar las configuraciones, tengamos en cuenta que no es un telefono, por lo cual hay funcionalidades que no van a andar.

Bueno, esto es una review de android, simple, para que vean como se puede ejecutar sin inconvenientes sobre VMware, para ver especificaciones propias de Android ya estarán los especialistas en móviles

A divertirse testeando su sitio en android y a los desarrolladores a usar el SDK.

Saludos.

________________________

Ing. Diego Quintana

VCP-VTSP-VSP-VAC