Sin lugar a dudas, uno de los mayores y más sonados cambios en VMware vSphere 5 se ha dado en el modelo de licenciamiento, con la inclusión de un nuevo concepto llamado vRAM Pool.

En resumen, para lo que antes necesitábamos 2 licencias de vSphere, ahora es posible que necesitemos 4 ó mas, dependiendo del entorno y cliente. Voy a explicarlo con un ejemplo muy claro.

Con VMware vSphere™ 4.x

• Dell R710 con 2 sockets y 192G de memoria = 2 Licencias de vSphere Enterprise Plus
• Dell R710 con 4 sockets y 256G de memoria = 4 Licencias de vSphere Enterprise Plus

Con VMware vSphere™ 5.x

• Dell R710 con 2 sockets y 192G de memoria = 4 Licencias de vSphere Enterprise Plus
• Dell R710 con 4 sockets y 256G de memoria = 6 Licencias de vSphere Enterprise Plus

Puedes ver el documento oficial de VMware que explica el nuevo formato de licencias de VMware vSphere™ 5.0 en este enlace:http://www.vmware.com/files/pdf/vsphere_pricing.pdf

Adicionalmente a las licencias requeridas y necesarias para arrancar tus máquinas virtuales, también necesitarás licencias adicionales siempre que sobrepases el número de 16 cores o más por procesador o socket.

Por esta razón, VMware ha puesto a disposición de los clientes en general una herramienta gratuita llamada VMware Licensing Advisor, la cual te dará más información relativa al impacto que tendrá en tu entorno particular la actualización a la versión vSphere™ 5.

Por consiguiente, ahora si dedicas más memoria vRAM a tus máquinas virtuales de la que has licenciado, sencillamente tus máquinas virtuales no arrancarán. Para la versión Essential y Essential plus esta comprobación es obligatoria, es decir, si has licenciado un pool de vRAM de 32GB y tienes ya esta cantidad de memoria configurada y usada en tus máquinas virtuales, al arrancar una máquina virtual que necesite usar 1GB adicional no lo hará.

Sin embargo, con las licencias a partir de la Essential Plus, si sobrepasas la configuración de la memoria en tu pool vRAM, recibirás un warning avisándote de que estas usando más memoria de la que has licenciado y que requieres comprar más licencias. No obstante, tu máquina virtual arrancará.

Supongo que la buena notica es que VMware vSphere™ ESXi 5 (como todas las versiones anteriores) permite usar el producto durante 60 días (Evaluation Mode) con toda su funcionalidad incluida.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola de nuevo. Soy Miguel ángel Alonso y aquí estoy de nuevo contigo para contarte algo nuevo sobre el apasionante mundo de la virtualización de sistemas.

En el tema de hoy voy a hablarte de una nueva funcionalidad a nivel de Red que no es otra que la tarjeta e1000e, la cual soporta adaptadores Pci-Express y será por defecto la tarjeta de los nuevos Windows 8. Esta tarjeta es una emulación de las Intel 82574L Gigabit Ethernet, y sólo está disponible en vsphere 5 con hardware 8.

El tema de hoy viene dado para explicarte como habilitarla, ya que de por si no viene activada y no puede hacerse a nivel de GUI.

Lo primero que deberemos es descargarnos el siguiente script desde esta página: http://communities.vmware.com/docs/DOC-12417

Cuando elegimos de manera normal una tarjeta de red para nuestra VM veremos algo como te muestro en la foto de la cabecera de este post.

Pero si ejecutamos el script que hemos descargado podremos ver algo como esto en nuestra consola del vMA:

Y finalmente podremos tener acceso a la nueva tarjeta de red una vez la hemos activado con el correspondiente script:

Por fin podremos disfrutar de esta nueva tarjeta que nos ofrece vSphere 5 en nuestros entornos y poder sacar todo el beneficio que esta nos pueda dar.Bueno, me despido de vosotros esperando haberos podido contar algo de vuestro interés. Hasta el próximo martes y un saludo.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola, soy Miguel Ángel Alonso y de nuevo estoy con vosotros como cada martes del mes para contaros algo nuevo del maravilloso mundo de la virtualización de sistemas.

En el día de hoy vamos a habla sobre el nuevo VMware WorkStation 8 que nos llega dentro de muy poco y que, aunque se encuentra todavía en fase BETA, nos promete nuevas funcionalidades de un gran interés.

Antes de comenzar a mostraros unos Screenshots donde podremos ver los avances más destacados, os voy a dar los requerimientos mínimos para la instalación de esta maravillosa herramienta:

• 1.3GHz de CPU como mínimo o superior
• Procesadores compatibles Intel ( Pentium 4, Pentium M – con PAE -, Core, Core 2, Core i3, Core i5, y Core i7 )
• Procesadores compatibles AMD ( Athlon, Athlon MP, Athlon XP, Athlon 64, Athlon X2, Duron, Opteron, Turion X2, Turion 64, Sempron, Phenom, and Phenom II )
• Los sistemas multiprocesadores también están soportados
• Soporte para 64 Bits

A continuación, te adjunto algunos screenshots de algunas de las nuevas funcionalidades y características mas relevante de VMware Workstation 8:

Cabe reseñar de manera superlativa, el botón de Remote Connections, el cual antes de introducir el login y la password, nos proporcionará acceso a nuestro entorno de vCenter.

Aquí, podemos ver un claro ejemplo de cómo podríamos tener acceso a las VMs de nuestro entorno vSphere. Desde aquí podremos encender, apagar, clonar y hacer Snapshots de estas máquinas virtuales.

Sobre la pestaña Edit>Preferences>, en la opción Shares VMs, podremos compartir nuestras máquinas locales para poder hacer todas las pruebas de laboratorio y testeo necesarias entre nuestro entorno local y nuestro entorno de producción.

También, habrá que tener en cuenta que tanto las VMware Tools como el Hardware serán compatibles con la versión 8 y anteriores, a la vez que cabe destacar que en las limitaciones de memoria se han duplicado en cada Guest soportando hasta los 64 GB de RAM en cada uno.

En las opciones de la VM y bajo dicha opción MANAGE podemos destacar:

1. Change Hardware Compatibility (Como su nombre bien indica)
2. Clone para clonar nuestras VMs
3. Upload para subir nuestras VMs de nuestro Sistema local al de producción
4. Share para compartir nuestras VMs entre nuestros diferentes escenarios de VMware

Otra opción a destacar desde el menú POWER de nuestra VM y creo que es muy interesante, es el de poder tener la opción de arrancar nuestra VM mostrándonos la BIOS directamente.

Otra nueva característica, aunque en VMware Fusion o Paralles para MAC OSX ya existía es UNITY MODE en el que podrás ver un programa o el contenido de una carpeta de un Sistema Linux o Windows como si se estuviese ejecutando en modo local.

Aquí os dejo una muestra del escritorio de un Fedora 14 dentro de mi escritorio Windows como si se estuviese ejecutando de forma nativa.

Bueno, hasta aquí por hoy. Espero haberte contado algo de tu interés y te emplazo hasta el próximo martes donde volveremos a hablar de un nuevo tema sobre la virtualización de sistemas.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

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 de nuevo. Soy Miguel Ángel Alonso, y aquí estoy como cada martes para hablar un poquito más del maravilloso mundo de la virtualización.

Hoy vamos a hablar de una característica maravillosa pero muy poco conocida de VMware vSphere, llamada: DVFS (de las siglas en Ingles Dynamic Voltage and Frequency Scaling).

Para tener una vista clara de esta característica, la vamos dividir en 3 secciones muy claras.

1. Para qué sirve y como activarla
2. Requerimientos
3. Limitaciones

1. Para qué sirve y cómo activarla

Esta característica permite a los Hosts cambiar la frecuencia y los voltajes de la CPUs basándose en la demanda de la carga de trabajo de estos.

Consigue que los procesadores puedan llegar a consumir menor energía y por consiguiente menor temperatura de trabajo.

Se activa mediante una interface que permite operar sobre los estados de rendimiento de una Cpu (P-State).

Los P-States son definidos para fijar la frecuencia y voltaje que operan a en las Cpus. Los procesadores pueden operar en niveles diferentes de P-States:

• Pmin= P-State de menor nivel
• Pmax0 P-state de mayor nivel

Los P-States, son controlados desde la ROM del sistema o desde algún Sistema Operativo.

En VMware vSphere, los P-States son controlados por el Vmkernel, el cual optimiza la demanda de frecuencia de cada CPU.

2. Requerimientos

Las CPUs deben soportar y tener activadas las siguientes características:

- Enhanced SpeedStep para procesadores Intel

- Enhanced PowerNow para procesadores AMD

- Todas la versiones de vSphere soportan esta característica

- En la pestaña Configuration/Advanced Settings/Power/ Power.cpu = Dynamic.. Por defecto está en estado de Static, en el cual el Vmkernel es capaz de leer todos los P-states pero no realiza cambio alguno en las CPUs.

Recuerda que esta optimización de la frecuencia de las CPUs jamás afecta en el rendimiento.

3. Limitaciones

No hay manera de poder monitorizar los P-States en vSphere.

Debo de decir, que en esta última versión de vSphere 4.1 Update 1, no encuentro la política que activa dicha característica en (Advanced Settings) por lo cual indagaré un poco por ahí para saber cómo se activa o donde se encuentra dicha política.

Bueno, hasta aquí por hoy. Me despido de vosotros, esperando haber podido contar algo interesante y te emplazo hasta la semana que viene, con un nuevo capítulo sobre la virtualización.

Ya esta disponible online el sexto episodio en nuestro Web TV show de virtualización en español, un nuevo programa de televisión web que es audaz, innovador y dedicado en exclusiva a los profesionales de la virtualización de sistemas y el cloud computing en español.

Esta semana tenemos una gran leccion del Ministerio de Defensa Español, hablaremos del anuncio hecho publico por VMware sobre el lanzamiento gratuito de la versión SuSe Linux Enterprise para VMware, contestaremos a una gran pregunta de un usuario relacionada con los procesadores Intel y AMD en virtualización y descubriremos una utilidad increíble que te ayudara a mover máquinas virtuales desde tu cloud privada a una cloud publica.

¿Y tú qué opinas con relación a la pregunta lanzada en el episodio de hoy? ¿Crees que aun AMD tiene una ventaja competitiva con respecto a los procesadores de Intel en virtualización? Deja tu comentario en virtualizacion.TV o charlemos sobre ello en twitter.

Hola amigos, soy Florián Murillo y vuelvo al ataque con temas de networking, hoy hablaré de como mejorar el rendimiento de nuestros interfaces de red de 10Gb utilizando Virtual Machine Device Queues (VMDq) de Intel.

El ratio de consolidación en los sistemas actuales, me refiero al número de VM que “corren” en un servidor físico, está aumentando considerablemente, según mis estimaciones, se ha multiplicado por 4 en los últimos 4 años, esto lleva parejo una consolidación del tráfico de red y tenemos la tentación de pensar que con ampliar los interfaces de red lo arreglamos, pasando de 1Gb a 10Gb, pero hemos de pensar que la mejora de rendimiento no es lineal con el aumento de ancho de banda, ya que el vmkernel ha de procesar y clasificar mucho mas tráfico, consumiendo CPU, convirtiendose en un cuello de botella y esto ocurre para el tráfico saliente y el tráfico entrante.

VMDq es una tecnología que permite realizar la clasificación del tráfico en el interfaz de red, creando colas de entrada/salida y especializando estas colas en VM especificas, descargando al VMkernel, evitando cuellos de botella y aumentando la velocidad de transmisión.

En pruebas de laboratorio con controladoras de red Intel 82598 de 10Gb, Intel midió, en un escenario concreto, velocidades de transmisión de 4.0Gbps sin VMDq y 9.2Gbps con VMDq, o sea a mas del doble, y todavía mejoro un poco (9.5Gbps) utilizando jumbo frames en el escenario final.

He visto pruebas parecidas con controladoras de red de Neterion.

La implementación de VMDq en VMware se llama NetQueue, y está disponible desde VI 3.5 U1. En vSphere v4 está activada por defecto, por lo que solo hemos de configurar el interfaz de red para soportar NetQueue y a disfrutar de sus beneficios.

¿Como verifico que NetQueue está activado en mi ESX?

Comprueba que en Configuration > Software > Advanced > VMkernel tengas VMkernel.Boot.netNetQueueEnabled activo, si no es así lo activas y reinicias el ESX.

Lo que estamos haciendo, en realidad, es cambiar el archivo /etc/vmware/esx.conf añadiendo la linea /vmkernel/netNetqueueEnabled = “TRUE”

¿Como configuro mi interfaz de red para soportar NetQueue?

El comando siguiente es para una Intel 82598 de un solo puerto, los parámetros pueden cambiar de nombre de un interfaz de red a otro.

esxcfg-module -s “InterruptType=2 VMDQ=16″ ixgbe

Donde InterruptType activa MSI-X, es una exigencia de NetQueue, permite a la controladora ethernet enviar datos a multiples cores aprovechando las interrupciones.

El parámetro VMDQ especifica el número de pares de colas de entrada y salida que tendremos, estas colas se asignaran automáticamente a las VM para aumentar la eficiencia. El número de colas depende de la interfaz ethernet, cuantas mas tenga, mejor.

Tras el comando esxcfg-module, hemos de reiniciar el ESX y ya está configurado NetQueue.

VMware vSphere tiene una manera muy “peculiar” de balancear el uso de ciclos de CPU física en un servidor VMware ESX/ESXi y pensé, a raíz de una discusión muy interesante iniciada por un usuario en los foros de VMware, que también te interesaría saber, mi querido lector, lo siguiente:

El VMware VMkernel dinámicamente “migra” las máquinas virtuales de CPU cada 20 milisegundos.

Para máquinas virtuales con múltiples CPU virtuales (vCPUs), el VMkernel intentara por todos los medios no poner más de un ciclo de ejecución de una misma máquina virtual en un mismo core. Sin embargo, con la tecnología hyperthreading habilitada, el scheduler del VMkernel tiene más CPUs que verificar.

El uso de la tecnología hyperthreading, permite convertir un core físico en dos – uno físico y otro lógico -, aunque esta tecnología no garantiza el doble de potencia para las máquinas virtuales, es decir, el escaldo no es lineal. Intel estima una mejora en el rendimiento de un 20%, aunque hay excepciones.

Hyperthreading suele estar deshabilitado en la BIOS del servidor físico. Mas cosas, las tareas del Service Console siempre son ejecutadas en la CPU con el ID número 0. El VMkernel nunca migrara ninguna tarea relacionada con el Service Console a otro core diferente.

Recuerda que en vSphere, una máquina virtual puede tener hasta un máximo de 8 vCPUs y ahora, el número de vCPUs puede ser impar. Aunque la máquina virtual puede usar tanto los cores físicos como los lógicos, el scheduler en VMkernel siempre intentara usar los cores físicos versus los lógicos, y siempre que hyperthreading este activado, obviamente.

Moraleja: un servidor vSphere con hyperthrering activado tendrá la capacidad de ejecutar mas threads simultáneos en paralelo (cpu fisica y cpu logica), por consiguiente, la teoría dice que el rendimiento de la infraestructura virtual seria mayor.

En el evento por excelencia de la Virtualización, el VMworld, que este año tuvo lugar en la famosa ciudad de las Vegas, pudimos ver por primera vez y en exclusiva la funcionalidad Flex Migration de Intel.

Para ponértelo de una forma muy sencilla, a partir del nuevo chip Intel Xeon Series 7400 (Dunnington) que Intel acaba de sacar esta semana, nos aseguraran que podamos hacer una migración en caliente con VMware VMotion hacia cualquier otro procesador Intel de nueva generación.

También he podido comprobar que es posible migrar en caliente con VMware VMotion una maquina virtual desde el nuevo chip de  Intel Xeon Series 7400 hacia  chips de dos generaciones anteriores Intel Series 5300 , pero eso sí, con la opción EVC (Enhanced VMotion Compatibility) activada en VMware ESX.

Ahora solo queda esperar  que hagan VMotion compatible el chip de Intel con el chip de AMD para poder desplegar granjas de virtualización sin preocuparnos de compatibilidad VMotion de VMware

Jake Smith de Intel Corporation y Dave Martin de Vmware Inc nos cuentan en este vídeo como las dos compañías han trabajado en conjunto para traer al público esta nueva funcionalidad

httpv://www.youtube.com/watch?v=9fKKI3rs544