Como cada miércoles estoy aquí con vosotros para ver temas nuevos del ecosistema de VMware. Soy Jose Mª Gris y hoy no hablaremos de cosas extrañas ni cosas que nos han desaparecido.

Hoy hablaremos sobre la activación del EVC Mode, funcionalidad que nos permite crear una “baseline” para que nuestros procesadores, aunque no sean iguales entre ellos, puedan ejecutar vMotion. Eso si, tendremos EVC para AMD y EVC para Intel. Las churras con las churras y las merinas con las merinas. Ya sabéis aquello de “las que entran por las que salen … “

Bien, ya hemos decidido activar nuestro EVC en el cluster de producción, lo activamos, seleccionamos la baseline y entonces nos damos cuenta que para poder activar la funcionalidad, el cluster tiene que estar parado. Y claro, no sería tan fácil, porque cuando decimos que vamos a parar “un momentito” pues “va a ser que no”, porque “show must go on….”.

Vale. Pues vamos a montarnos nosotros solos la fiesta. En estos casos lo que hago es definir un segundo cluster, pasar toda la producción del ESX2 al ESX1, parando todo lo no crítico. Cuando tengo ESX2 libre lo pongo en maintenance mode y lo paso de Cluster.

Posteriormente voy haciendo vMotion de las VM en producción entre ESX1 y ESX2, dando continuidad al servicio. Una vez tengo el primer cluster y ESX1 libre de carga, lo paro y activo EVC. Si señor! De parrafada y sin equivocarme!

Posteriormente no tengo más que devolver las VM de producción a ESX1 y devolver en su momento ESX2 a su cluster de procedencia. Podemos borrar el cluster temporal que hemos montado y todo vuelve a su lugar, pero con el EVC en marcha para que podamos entrar un nuevo ESX con un procesador “algo” distinto.

Take care.

Hola que tal, soy Jose Maria Gris y de nuevo vengo aquí a comentaros algo sobre este mundillo de VMware.

Hoy hablamos de una situación un poco rara que ocurre cuando migramos de VMware vSphere 4.x a 4.1 un entorno con cierto numero de VMs y lo hacemos con Update Manager para que actualice las VMwaretools.

Sencillamente, cuando has acabado y se están actualizando las mencionadas vmwaretools, pues nos aparece los distintos hosts en alertas y con un mensaje digno de Microsoft.

“Unable to apply DRS resource settings on host xxxx en xxxxx. Another task is already in progress. This can significantly reduce the efecctiveness of DRS.”

Y ahora, ¿Qué ha pasado? Que yo sepa he hecho todo correctamente…. ¿Qué es esa segunda tarea que dice que está trabajando?

No fear. Sencillamente, si recordamos VMware DRS no es más que la automatización de vMotion y que las VMs con Snapshots no pueden hacer vMotion!. Y como casi todas tienen Snapshots, pues el aparato nos dice que no puede hacer DRS porque tiene un monton de VMs que tienen Snapshots.

Ya sabeis que en estos casos podemos dar caducidad a los Snapshots, por lo que podemos esperar a que se retiren, o podemos ir sacándolos uno por uno…..

Saludos, hasta la semana que viene.

En un post publicado el 22 de noviembre de este mismo año, publique una entrada sobre las políticas de anti-afinidad de un clúster VMware DRS

Permiteme recordate la importancia de VMware Distributed Resource Scheduler (DRS).

Básicamente VMware DRS balancea dinámicamente las máquinas virtuales de un servidor VMware ESX/ESXi a otro servidor o servidores VMware ESX/ESXi para mejorar el tiempo de respuesta de las aplicaciones que las máquinas virtuales contienen.

Cuando un virtual máquina experimenta un aumento de la carga, VMware DRS automáticamente asigna recursos adicionales mediante la redistribución de otras máquinas virtuales entre los servidores físicos.

Sin embargo, VMware DRS no sabe qué servicios dichas máquinas virtuales se están ejecutando con lo que se hace necesario configurar policías de afinidad y anti-afinidad en un clúster VMware DRS.

¿ Te imaginas un clúster VMware DRS donde aplicaciones multi-tier se están ejecutando en diferentes servidores VMware ESX/ESXi y que este se caiga ?

En este episodio número #49 te enseñare a crear políticas de afinidad para tus aplicaciones multi-tier.

De esto modo, VMware DRS se asegurara automáticamente de ejecutar las máquinas virtuales del backend y frontend en un mismo servidor VMware ESX/ESXi y mejor así las latencias de red de estas máquinas virtuales, de modo que la comunicación de red entre dichas máquinas virtuales se “quedan” en un mismo servidor VMware ESX/ESXi.

Hola amigos, soy Florián Murillo, a veces me pregunto si todos los host del cluster tienen la misma versión y si todas las VM tienen la misma versión de la placa base.

Recordar que la versión de la placa base virtual define que dispositivos podemos entregar a la VM y que propiedades tiene la blaca base, por ejemplo la ampliación de discos VMDK en caliente o el añadir RAM y vCPUs en caliente.

En un entorno pequeño lo sabemos de memoria, tardamos un segundo en contestar, pero en un entorno mediano o grande no podemos responder tan rápidamente con total garantía.

Actualmente es motivo de problema, intentar añadir un host v.4.0 en un switch distribuido creado en la versión v.4.1, además las auditorías de seguridad dependen de la versión del host (VI3 o vSphere 4), por tanto ya no es una información “curiosa” tener esta información, sino una necesidad para evitar problema y cumplir normativas de seguridad, o sea, disminuir el riesgo del negocio ante problemas de seguridad.

Por tanto, he creado un script que os ayudará a conocer el estado de vuestros sistemas, espero que os ayude:

get-datacenter | get-cluster | %{
$cname = $_.name

get-cluster -Name $cname | get-vm | %{get-view $_.id} | %{
write-output ($_.name + ” ” + $_.config.version)
}
}

La leyenda del script es:

vmx-04 : Hardware Virtual versión 4
vmx-07 : Hardware Virtual versión 7

Hasta la semana próxima amigos, que disfrutéis de un gran fin de semana.

Hola a todos, soy Florián Murillo y ha llegado el momento de empezar a desgranar las mejoras de vSphere 4.1, que no son pocas, hoy hablaremos de las reglas de afinidad.

Hasta ahora (vSphere 4.0) el cluster DRS tenía reglas de afinidad y anti-afinidad basadas en VM, es decir “la VM1 debe ejecutarse en el mismo anfitrion que la VM2”, lo que podemos llamar “Reglas de afinidad VM-VM”.

Con vSphere 4.1, el cluster DRS define “Reglas de afinidad VM-Anfitrión”, es decir, “El Grupo1 de VMs se ejecuta en el Grupo1 de Anfitriones”, yo puedo agrupar los anfitriones por bladeCenter, rack, edificio, ciudad o lo que me plazca.

Además tengo 2 tipos de reglas, tanto en el caso de afinidad como de anti-afinidad, son las reglas “must” y las reglas “should”.

En un cluster DRS y HA, una regla “should” puede ser incumplida por HA ante la caída total del Grupo de anfitriones donde está aplicada, y una regla “must” será respetada por HA ante la perdida de dichos anfitriones.

Para configurar las nuevas reglas de afinidad hay que realizar 2 tareas:

1. Crear los grupos de VMs y de anfitriones
2. Crear la regla (should o must) de afinidad o anti-afinidad.

Al entrar en el “Edit settings” del cluster tenemos la opción “DRS Groups Manager” para crear los grupos y “Rules” para crear las reglas.

En la imagen siguiente veréis que desde “DRS Groups Manager” he creado dos grupos de VMs, llamados GrupoUNO y GrupoDOS y dos grupos de anfitriones, llamados AnfitrionesUNO y AnfitrionesDOS.

Es curioso que a estas alturas de la tecnología no podamos cambiar el nombre del grupo tras grabarlo.

Al entrar en la opción “Rules” tenemos las opciones clásicas de “Keep VM Together” y “Separate VM” (ahora soporta más de dos VM), además de la nueva modalidad “Virtual Machines to Hosts”

Como habéis visto en la pantalla anterior, solo podemos especificar un grupo, no una VM.

Cuando el cluster es DRS + HA, las reglas actúan de la siguiente manera:

“Must run on hosts in group”: Si un anfitrión del grupo falla, las VM se levantarán en otro anfitrion del grupo. Si todos los anfitriones del grupo caen, por ejemplo un BladeCenter, NO se levantan las VMs en otros anfitriones del cluster pero externos al grupo.

“Should run on hosts in group”: Si un anfitrión del grupo falla, las VM se levantarán en otro anfitrion del grupo. Si todos los anfitriones del grupo caen, SI se levantan las VMs en otros anfitriones del cluster pero externos al grupo.

“Must Not run on hosts in group”: Si un anfitrión falla, las VM se levantarán en otro anfitrion que no pertenezca al grupo. Si todos los anfitriones ajenos al grupo caen, NO se levantan las VMs.

“Should Not run on hosts in group”: Si un anfitrión falla, las VM se levantarán en otro anfitrion que no pertenezca al grupo. Si todos los anfitriones ajenos al grupo caen, SI se levantan las VMs en un anfitrión del grupo.

En resumen, disponemos de mas granularidad, muy interesante en entornos medianos y grandes.

Acabo de publicar un nuevo vídeo en el programa de formación VMware online sobre Storage VMotion.

El vídeo dura unos 30 minutos y es realmente interesante si quieres familiarizarte con la funcionalidad de Storage VMotion.

En el vídeo también muestro como configurar VMWare ESX 3.5 para conectar una LUN iSCSI con openfiler, SAN/NAS appliance.

Para terminar nuestro como configurar un Cluster DRS y HA con VMware ESX 3.5.

En este link podrás acceder a este modulo 6 de este tutorial de VMware ESX 3.5 así como  a todos los módulos anteriores.

Espero que disfrutes.

VMware acaba de publicar un nuevo y muy interesante whitepaper de 19 páginas sobre su tecnología DRS (Distributed Resource Scheduler ).

Para demostrar el valor de esta tecnología, VMware ha medido el rendimiento de varias maquinas virtuales durante la distribución de estas a través de los algoritmos de DRS.

El documento contiene muchos consejos útiles para mejorar la eficiencia de DRS.

Puedes bajarte el documento aquí.

VMware acaba de publicar un nuevo y muy interesante whitepaper de 19 páginas sobre su tecnología DRS (Distributed Resource Scheduler ).

Para demostrar el valor de esta tecnología, VMware ha medido el rendimiento de varias maquinas virtuales durante la distribución de estas a través de los algoritmos de DRS.

El documento contiene muchos consejos útiles para mejorar la eficiencia de DRS.

Puedes bajarte el documento aquí.