Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes. Antes de nada quiero desearos un feliz inicio de año 2012 y que lo acabéis mejor que lo empezáis.
Alguna vez te has preguntado: ¿Cuanto dura un vMotion en una VM de 255GB de memoria asignada? es decir el límite de memoria de una VM en un host ESX/ESXi v.4 con hardware v.7 en la placa base de la máquina virtual. Pues con vSphere 5 aparecen VMs de hasta 1GB de RAM, anunciando migraciones de larga duración para máquinas virtuales de gran formato.
vSphere 5 trae una funcionalidad que no aparece entre las mas importantes pero que es muy bien recibida en entornos con grandes máquinas virtuales. Me refiero a la posibilidad de hacer vMotion utilizando varios interfaces de red SIMULTANEAMENTE.
En EMC han realizado un análisis de carga interesante, han comparado un vMotion con diferentes escenarios, con 1 NIC, con 2NICs y con 4 NICs.
La máquina virtual de test no está nada mal, un SQL Server con 60 GB de memoria, mas de 2TB de datos y 10.000 IOPS. Es decir una máquina virtual con alta actividad y tamaño medio/alto.
Los resultados (redondeados a minutos) han sido los siguientes:
vMotion con 1 puerto de vmKernel: 23 minutos.
vMotion con 2 puertos de vmKernel: 8 minutos.
vMotion con 4 puerto de vmKernel: 3 minutos
Para evitar dudas os diré que las pruebas se han hecho con todos los interfaces a 1Gbps y con una MTU de 9000 bytes, o como la conocemos coloquialmente con Jumbo Frame activado en todos los puertos de vmKernel.
¿Cuál es la conclusión?
En todo diseño con máquinas virtuales de tamaño medio o grande, hemos de tener en cuenta el tamaño de las maquinas mas grandes para atender sus necesidades de conectividad y sus necesidades de movilidad, o sea vMotion. La eficiencia obtenida es tan alta con vMotion multi-NIC que merece la pena invertir un poco en interfaces de red.
Con máquinas de gran tamaño ¿Os podéis permitir tardar mas de una hora en poner un host en mantenimiento? o bien que DRS tarde este tiempo en mejorar el balanceo de un cluster ¿impensable verdad?
¿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 aquí estoy como cada martes para hablar contigo sobre un nuevo tema del mundo de la virtualización de sistemas.
En el tema de hoy y como claramente has visto en el encabezado del post te voy a informar sobre un bug que impide realizar vMotion a algunas máquinas creadas con VMware View 5 sobre la plataforma de vSphere 5.0.
Vamos por partes para tenerlo claro, una primera en la que te informo de cuál es el problema y porqué ocurre y otra en la que puedes subsanarlo manualmente de varias maneras.
Error:
Ageneral system error ocurred: Failed to flush checkpoint data!
El error sólo ocurre cuando la versión de nuestro hardware es 8 y las resoluciones de pantalla en nuestros desktops virtuales son muy altas.
Cuando tenemos activado 3D en nuestros desktops el problema se arregla por un sencillo motivo, y es que al activarlo nuestros ESXi5 calculan de manera automática la cantidad de buffer necesario para que vMotion se realiza con total éxito. Si no lo utilizamos, tales cálculos no son tomados y nos dará un error cuando se realice un vMotion de estos escritorios, ya sea de manera manual o automática bajo DRS.
Solución:
Hay varias (3 en concreto) que se me ocurran a bote pronto:
1- Editaremos el fichero config, localizado en /etc/vmware en nuestros ESXi 5 y le añadiremos la siguiente línea:
Migrate.baseCptCacheSize= “16777216”
Con esto se añade en cada fichero vmx de las Vms de nuestro entorno la opción de asegurarse un buffer lo suficientemente grande como para poder realizar el vMotion en caso de necesitarlo para tal fin. Se le asocian 16 MB en lugar de los 8 MB que vienen por defecto.
2- Otra opción es habilitar como ya he indicado en el apartado de error, el activar 3D para que nos asegure el buffer necesario para la consecución de vMotion.
3- Otra es ir a la kb de VMware en la que te mostrará otras posibles soluciones para mitigar el error como bajar la resolución a 1280X1024 o inferior, no actualizar las VMs a Hardware 8.
Bueno hasta aquí por hoy. Espero que te haya gustado y puedas sacar provecho del post si te has encontrado o lo vas a hacer con este problema, y te emplazo hasta la semana que viene para poder seguir hablando contigo sobre un nuevo tema de la virtualización de sistemas.
¿Crees que este videopost le puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Muchas gracias por tu apoyo.
Hola amigos, soy Florián Murillo. Hoy estoy nostálgico, me he puesto a recordar la historia de VMware y la evolución de Elastic Sky X, hace tanto tiempo que lo nombramos por sus siglas (ESX) que nos hemos olvidado de su nombre ¿verdad?
¿Cuales son, según mi opinión, las mejores características de cada versión de ESX?
En 2001 nació la versión 1 y para mi, la mejor característica que tuvo fue nacer, y aportar una forma diferente y atrevida de entender el concepto de las TI en las empresas (entornos x86). ¿Cómo sería el mundo de las TI hoy si no hubiera aparecido ESX v.1?¿Estaríamos hablando de cloud ahora? ¿Habría energía eléctrica en los DataCenters para alimentar a todos los servidores? y… ¿Donde alojaríamos tantos servidores?
En 2003 se lanza la versión 2 y como grandes novedades, vMotion y VirtualCenter. Aún era un producto para expertos en Linux, se hacían mas tareas con CLI que con VirtualCenter, pero había nacido con VirtualCenter la Gestión de las Infraestructuras Virtuales. VMware empezaba a mejorar, tímidamente, los negocio, con su producto.
El año 2006 nace la versión 3 y se produce un antes y un después en esta tecnología. Como gran novedad aportó VMware HA, aún recuerdo ese año evangelizando a clientes reunidos en hoteles, un mes si y otro también hablándoles de vMotion y VMware HA, era increíble como les explicabas lo que hacia el producto y no se inmutaban, en el momento que te conectabas a un CPD en producción y se lo enseñaban en vivo y en directo, no les cabían los ojos en las órbitas ¿tan mal me explico?. Era fascinante saber que hacías una presentación y triunfabas, gracias VMware.
El año 2009 se presenta en sociedad la versión 4, aquí discrepo de VMware acerca de cual es la gran mejora de esta versión (ellos dicen que es VMware FT) para mi es Storage vMotion, nos proporciona escalabilidad y disponibilidad y para mi, en segunda posición: La visión de VMware para abrir su producto con APIs de todo tipo. Algunas de ellas son la vNetwork Appliance API, la Pluggable Storage Architecture o la vStorage API for Data Protection.
Con estas incorporaciones, poco visibles a priori, se garantiza la evolución el producto, son soluciones propias o de otros fabricante. Las APIs permiten liberar la creatividad sin el freno de las limitaciones tecnológicas. La prueba de ello es que gracias a estas APIs han seguido deslumbrando en la versión 4.1 con Storage I/O Control, Network I/O Control o VAAI.
¿Cuál crees tu que son las mejores aportaciones de cada nueva versión?
¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.
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.
El wizard de la migración en caliente, VMware VMotion, valida los requerimientos del servidor origen y servidor destino así como los requerimientos de la maquina virtual que quieres migrar.
Una máquina virtual no puede ser migrada en caliente cuando:
La MV tiene una conexión activa a un virtual switch de uso interno.
La MV tiene una conexión activa a un CD o disquete.
La MV tiene configurada una afinidad a una CPU.
La MV forma parte de un clúster Microsoft.
El wizard de migración en caliente, VMware VMotion, produce un warning cuando:
La MV tiene una conexión a un virtual switch de uso interno pero no está conectado.
La MV tiene una conexión a un CD o disquete pero no está conectado.
La MV tiene uno o más snapshots.
El servidor VMware vSphere ESX/ESXi no ha recibido un guest OS heartbeat (probablemente las VMware tools no han sido instaladas o configuradas adecuadamente).
El wizard de migración en caliente, VMware VMotion, muestra un mensaje de error si la máquina virtual no puede ser migrada desde el servidor origen al servidor destino. Sin embargo, con un mensaje de error de tipo warning, la máquina virtual puede ser migrada con VMotion sin problemas.
Asimismo, los servidores involucrados en la migración, servidor origen y servidor destino, deben cumplir los siguientes requerimientos:
Visibilidad de todas las LUNs (FC, iSCSI, NAS) usadas por la MV.
Una red Gigabyte Ethernet dedicada al tráfico VMotion. (En una red 10/100 también funciona pero va muchoooo mas lento. No ostante, VMware solo soporta una red Gigabyte para el trafico VMotion.
Acceso a la misma red Ethernet física.
El nombre de los virtual switch debe ser igual en ambos Servidores ESX (incluyendo mayúsculas y minúsculas). En VMware vSphere ESX/ESXi versión 4 update1, si los virtual switches no son nombrados iguales, el wizard de migración en caliente VMotion produce un warning pero la migración puede continuar.
CPUs compatibles o similares (misma familia CPU). VMotion también funciona, si el servidor origen tiene Hyperthreading activado pero no el servidor destino
Seguro que se me escapan algunos requerimientos de VMotion, con lo que si no ves aquí todos, o crees que falta alguno, por favor déjame tu comentario.
Apunto estamos de terminar el año y VMware vSphere sigue sorprendiéndome gratamente. A estas alturas, no te voy a dar “la chapa” con lo que es VMware VMotion – al menos no lo pretendo -, pues estoy convencido que sabes lo que VMware VMotion es capaz de hacer, pero si me permites, me gustaría compartir contigo algo que he descubierto recientemente durante la implementación de VMware vSphere 4.0 en uno de mis clientes.
Como sabrás – y si no lo sabes, mas vale te lo vayas aprendiendo para el examen de certificación de VMware VCP 4 -, hay dos requerimientos fundamentales – entre otros muchos mas – para poder hacer migraciones con VMware: Primero, los dos servidores vSphere ESX/ESXi 4.0 involucrados en la migración, tienen que estar conectados vía red Ethernet Gigabit. Segundo, las maquinas virtuales deben tener acceso a las mismas sub-redes en los host vSphere ESX/ESXi origen y destino. Hasta aquí todos estamos de acuerdo.
Bien, más cosas. VMware VMotion te permite mover una máquina virtual desde un servidor ESX/ESXi a otro. Hay dos tipos de migración con VMotion: cold y hot migration. Una migración en frío (cold migration), mueve una máquina virtual apagada y permite re-alocar el disco virtual de la maquina virtual en otro datastore. Las migraciones en frío pueden incluso ejecutarse entre CPUs de distinto fabricante, es decir, entre Intel y AMD por ejemplo.
Una migración en caliente (hot migration) con VMware VMotion, mueve la máquina virtual de un servidor ESX/ESXi a otro pero no mueve el disco virtual de la máquina virtual (.vmdk).
Lección 1: Las migraciones en caliente pueden fallar, y fallan, cuando activamos el soporte VMI Paravirtualizacion en la maquina virtual del host ESX origen y el host destino no tiene soporte para VMI Paravirtualizacion.
Lección 2: Asimismo, pude comprobar en las instalaciones de mi cliente que: una migración con High Prioriy (Reserve CPU for Optimal VMotion performace) reserva recursos en el host destino, por tanto la migración puede que no se ejecute si el host destino no tiene recursos suficientes – como fue el caso.
Una migración con Low Priority (Perform with available CPU resources) no reserva recursos en el host destino, por tanto las migraciones con low priority siempre se ejecutan con éxito, aunque es mas probable que el proceso de migración con VMotion tarde mas tiempo.
Durante la actualización de mi laboratorio a la nueva y última versión, VMware, vSphere 4.0 , he descubierto un error durante la migración de una de mis maquinas virtuales con VMotion , el cual todavía me ha dejado “temblando”.
Rápidamente me he puesto a buscar por la red para confirmar si el problema que yo estaba teniendo durante la actualización, era un problema general o algo especifico a mi entorno – después de todo es la primera migración de VMware 3.5 a vShpere 4.0 que hago!!.
Cuál ha sido mi sorpresa cuando he encontrado dos artículos en la base de datos de conocimiento de VMware, los cuales describen el problema y como solucionarlo.
Al parecer este problema solo se les ha parecido a algunos usuarios de VMotion después de actualizar a vSphere. Lamentablemente yo he sido uno de ellos.
Si tienes algún problema con VMotion después de una actualización a vSphere 4.0, asegúrate de leer estos dos artículos:
NetworkWorld ha informado sobre una interesante noticia que aún no ha sido confirmada: el 19 de agosto Microsoft reducirá el numero de licencias para llevar a cabo la migración de máquinas virtuales.
En la actualidad cualquier cliente que quiera migrar un Windows de un host físico a otro (por ejemplo, a través de la tecnología VMotion de VMware) tiene que tener dos licencias del sistema operativo, una para cada servidor ESX.
De hecho, la política actual dice que un cliente tiene que esperar 90 días antes de migrar sus licencias de un servidor físico a otro.
Parece ser que después de las queja de los clientes, Microsoft tal vez sustitulla el licenciado a una licencia por maquina virtual en lugar de una licencia por servidor host.
Descubre y domina la nueva versión de VMware vSphere™ 5 y aprovéchate de hasta un
20% de descuento al comprarlo online.
Regístrate y
recibe un capitulo de nuestro nuevo libro totalmente gratuito
Nuevo Site Recovery Manager 4 en español Consigue una copia gratuita del eBook
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….”.
