Opinión: Mis razones para preferir VMware.

Tras una buena temporada de ausencia de Be Virtual, debido no a las vacaciones, sino a una serie de cambios profesionales que me han traído de cabeza, me propongo a volver con renovados ánimos (si no, me temo que el maestro Ros se va a enfadar en serio), y empiezo con este post que he titulado "Mis razones para preferir VMware". Las razones aquí expuestas se dividen en dos grandes grupos: Técnicas y no técnicas. Las primeras, por supuesto, son fruto de mi visión del mercado (cuestionable o no) y las segundas, fruto de mi experiencia técnica y mi día a día. (Con esto quiero decir que quien las cuestione, por favor use el mismo tipo de argumentos).

Empecemos.

Madurez de producto: VMware ESX (En cualquiera de sus versiones) es, indiscutiblemente, el producto más maduro en lo que a hipervisores se refiere. A casi diez años de evolución deben prepuonérseles madurez, estabilidad y rendimiento. Creo que esta presunción es aplicable a todos los fabricantes de software en todas sus gamas de producto: Microsoft, con SQL Server o Windows Server, Oracle con su base de datos, etc.

Liderazgo del mercado: Con un 85% de cuota del mercado (la misma que Microsoft en el mercado de servers x86), VMware ha convencido a una inmensa mayoría de las empresas más importantes que han apostado por la virtualización de que usen su producto. El cómo lo haya hecho (Calidad técnica o marketing) no es algo que esté en mi mano evaluar (al igual que tampoco lo está el cómo lo ha conseguido, por ejemplo, Microsoft u Oracle). Simplemente uso el mismo parámetro que usan otros.

Amplio soporte de la comunidad: Al igual que el Cisco IOS, Microsoft Server y demás, Oracle y otros, la comunidad en el caso de VMware, resulta un gran apoyo en lo que a soporte se refiere, tanto en resolución de incidencias como en apoyo a la hora de configurar y gestionar.

Precio: Resulta que, además, ahora incorporar la tecnología insignia de VMware, Virtual Infrastructure, es gratis. Por 0 €/$, hoy podemos utilizar un hypervisor de última generación con características avanzadas, clustered filesystem (Sí, para los que tienen dudas o no han podido/no han querido leerse qué incluye 3i, VMFS también es gratis), y con la capacidad de escalar (eso sí, mediante pago) a las características completas de la suite: DRS, vMotion, HA, etc. Además, y siempre opcionalmente, es posible contratar el soporte completo por un precio realmente asequible (595 US$ en modalidad 24x7 para dos CPU), que resulta inferior que UNA sola consulta de soporte de otros fabricantes. Además, no debemos olvidar que ESX 3i no requiere el pago de una licencia de sistema operativo para funcionar. En determinados entornos (Linux y similares), esto supone un ahorro de unos 600€ (aproximadamente)

Política/naturaleza de compañía: Mientras VMware se esfuerza en que su producto sea cada vez más compatible con los sistemas operativos del mercado (no le queda otro remedio, ya que la propia VMware no fabrica ninguno) , colabora en todos los foros de otros fabricantes (Es miembro del Microsoft Server Virtualization Validation Program - SVVP), e incluso dona a la comunidad tecnologías como VMI (Virtual Machine Interface), o estrena iniciativas como vSafe (a la que ya se han adherido todos los fabricantes de productos de seguridad), otros fabricantes no hacen lo mismo. La impresión que se extrae es clara: VMware colabora (porque no le queda otra) mientras otros no lo hacen (porque el core de su facturación no está en el hypervisor). Así mismo, por la propia naturaleza de la compañía, y por el accionariado que tiene detrás (EMC, Cisco, Intel, etc) se puede inferir que mantendrán su producto a la última, ofreciendo siempre lo mejor que la tecnología pueda dar. En el caso de otras compañías más generalistas, no es la primera vez que vemos como un producto anunciado desaparece en medio de las políticas de empresa: WinFS, OracleFS, Oracle Mail, etc. No es desdeñable el hecho de que VMware no tiene "sardina" a la que arrimar su "ascua", lo que quiere decir que su desarrollo no beneficiará más o menos a cierto sistema operativo, o a cierta solución de seguridad, o a cierto motor de base de datos, por poner ejemplos.

Solución completa e integridad del producto: Mientras VMware ofrece virtualización "extremo a extremo" (al igual que otros fabricantes lo hacen en otros aspectos - Microsoft sin ir más lejos ofrece tanto el Sistema Operativo, como el motor de base de datos, así como las herramientas que los rodean), Hypervisor, clustered file system, HA, gestión de Disaster recovery, gestión de operaciones y ciclo de vida, Virtual Desktop, backup, etc, otras requieren de productos de terceros porque en su catálogo no incorporan las soluciones requeridas. Como ejemplo, el clustered file system. Mientras la necesidad de un clustered file system fué identificada por VMware como fundamental para la Live Migration o la futura Continuous Availability (HA sin disrupción de servicio) (recordemos que VMFS existe desde ESX 1.0 y ya va por su versión 3.2x), otras compañías confían en productos de terceros que no son precisamente baratos (MelioFS, de SANbolic es un claro ejemplo).

Vamos con los técnicos.

Virtualización completa de extremo a extremo: Sin entrar a discutir términos como los diferentes tipos de hypervisor (Tipo 1, Tipo 2... o Tipo 1 y dos cuartos, o Tipo 1.25), ESX es el único hypervisor que gestiona integramente todos los aspectos de la virtualización: Gestion de VM e I/O. Mientras Hyper-V y Xen escogen la opción de dejar el I/O en manos del sistema operativo que se ejecuta en el dominio raíz, ESX gestiona integramente el I/O, independizándose de un sistema operativo que no deja de ser una VM más. Es decir, todo el I/O (red y disco) de las VM virtualizadas depende de una máquina virtual más. No lo digo yo, cito a mi respetado David Cervigón:

"1.- Las arquitecturas de Hyper-V y ESX son diferentes (Xen e Hyper-V tienen la misma aproximación). En hyper-V el hypervisor es delgado, 800Kb, en microkernel. En ESX hablamos de un hypervisor monolítico, donde deben incluirse toda la funcionalidad de I/O a bajo nivel, en particular red y almacenamiento. ESX no necesita más, cierto, pero solamente tiene la funcionalidad limitada que "cabe" en esos aprox 32 MB. De ahi que se restrinja a una HCLlimitada. Hyper-V depende de Windows, cierto, pero en su arquitectura en su arquitectura la particion padre (que no deja de ser una VM) es la encargada de interaccionar con el sistema de red y de almacenamiento."

En un entorno Hyper-V o Xen, todo el I/O depende de un driver que puede o no estar optimizado para la virtualización, y que puede o no ser adecuado para un entorno de múltiples máquinas virtuales. VMware blinda sus drivers y los adapta para el uso por parte de un Hypervisor.

Por otra parte, TODAS las funciones de virtualizacíon están aisladas del resto de las funciones (como las que provee el COS - Console Operating System), lo que supone que el I/O NO es un punto de exposición del Hypervisor.

Virtualización independiente del hardware: ESX usa el método de traslación binaria (es decir, las instrucciones son traducidas por el Hypervisor), mientras Hyper-V y Xen delegan en el hardware (Intel/AMD VT) la gestión de las diferentes VM. Es decir: Sin VT no hay virtualización, lo que, evidentemente, hace que estos Hypervisores sean meros gestores de una capacidad hardware que puede o no variar con las diferentes versiones de las especificaciones de virtualización. Mi conclusión es clara: Virtualiza Intel o AMD, gestiona Xen o Hyper-V. para más info, un post anterior sobre la virtualización asistida por hardware. Así mismo, la traslación binaria permite soslayar muchas (no todas, gracias a Intel y a AMD) de las incompatibilidades entre distintas series de procesadores. El masking de registros nos permite incluir equipos con diferentes series de procesadores en un entorno vMotion. Por otro lado, Hyper-V y Xen recomiendan (lo que en la práctica se convierte en un requerimiento), que los procesadores sean IDENTICOS. Todos sabemos que, incluso para un mismo modelo de servidor, con unos meses de diferencia, es bastante posible encontrarse con diferentes generaciones de procesadores.

Live Migration: La capacidad de movimiento de VM entre un host ya no es una curiosidad técnica. En mi caso, si me privasen de ella, tendría que reorganizar prácticamente todos los procedimientos de explotación de plataforma virtual, e incrementaría drásticamente los downtimes. Evidentemente mi caso no es el de todos, pero estoy seguro que, en algún momento, todos echaríamos en falta esta característica. Hyper-V no la tiene (aunque está anunciada para su versión R2) y Xen presenta ciertos problemas de rendimiento y estabilidad que hacen de su implementación de Live Migration algo no apto para producción (cierto factor de indeterminismo bastante poco ponderable)

Virtualización de I/O: El soporte total de NPIV (N Port ID Virtualization), las capacidades anunciadas por Intel para la virtualización de I/O (VMDq) apoyan el precepto de que deben existir tecnologáis especificas para la virtualización, y que consecuentemente el hardware, los drivers y demás deben diseñarse especificamente para este propósito.

Memory Overcommit: Digan lo que digan, y hablando en plata, el Overcommit mola. Y si no que se lo cuenten al que compra un big node de 16 cores y "solo" 32 Gb de RAM.... Sin él, probablemente se quedará con la mitad de los cores sin usar. Evidentemente el overcommit no se aplica a todas las VM (Oracle bajo linux presenta inconvenientes), pero, como dice el anuncio, para todo lo demás....

Seguridad: ESX es monolítico, es verdad, y en eso consiste, para mí, su ventaja. No depende para nada del exterior, exceptuando los servicios de gestión que provee el COS (Console Operating System). Esta aproximación es similar a las de los Appliances, es decir, un SO personalizado, reforzado y especializado en una sola función... O al menos eso es lo que nos cuentan los fabricantes de appliaces... entre los que se incluye Microsoft con ISA Server o Windows Storage Server. Si vale para lo uno, vale para lo otro.

Herramientas, complementos de terceros: Sin duda, VI3 es la suite de virtualización más apoyada tanto por los fabricantes tradicionales como por nuevas startup: Veritas, Cisco, Intel son sólo un ejemplo de las primeras. VEEAM, vKernel, etc son ejemplo de las segundas.

Rendimiento y capacidad: Digan lo que digan quien lo diga, los ratios de virtualización con ESX son, como mínimo, un 30% superiores. Es decir, podemos ejecutar un 30% más de VM en ESX que sobre cualquier otra plataforma. Así mismo, el rendimiento, en especial en sistemas con múltiples VM, es, por término medio, mayor. Tampoco lo digo yo: Preguntad a San Google bendito.

Para terminar, analicemos ciertas afirmaciones que van corriendo por la blogosfera:

"Siendo Hyper-V de Microsoft, es razonable pensar que Windows funcionará mejor bajo Hyper-V". Bueno, Yo uso Windows Vista, y mi teclado es logitech, como mi ratón. Y no veo que los marca Microsoft vayan mejor. Puestos a seguir esa línea, Oracle no se vendería bajo Windows, desplazado por MS SQL, o Veritas se tendría que haber retirado del mercado, ahora que microsoft saca su producto de backup. Pero puestos a seguir, la realidad me va diciendo que esa afirmación no es del todo correcta: Veritas Cluster supera con mucho a Microsoft Cluster Service, o Forefront habría desplazado a McAfee... MelioFS parece que lo hace sobre NTFS, y así hasta el infinito. El producto estrella de Microsoft es Windows (en toda su familia) y es donde invierte. Es su negocio, y junto con Office, el "gordo" de su facturación. Si requerimos algo especial o con prestaciones adicionales.... recurrimos a software de terceros. ¿porqué con la virtualización debería ser distinto?

"El Hypervisor debe ser parte del sistema operativo": Vaya... es como si me dijesen que la BIOS debe ser parte del Sistema operativo.... o que el RAID5 debe hacerlo el OS... o que el routing de core de nuestra compañia debe ejecutarse en un servidor 2003/2008 con routing & remote Access....Cada uno que evalúe esta afirmación.

"Muchos GRANDES clientes están migrando a Hyper-V/Xen desde VMware": A ver. Migrar es dejar VMware y pasarse a Xen/Hyper-V. Yo que por mi actividad profesional, que incluye dar conferencias sobre temas de infraestructura, lidio con muchas de las grandes compañias de este pais, aún no conozco ningún caso donde se haya sustituído, en sistemas de producción, ESX por Hyper-V/Xen. Sí conozco casos donde los entornos de prueba, desarrollo y test se han virtualizado utilizando Hyper-V y por Xen (Y no siempre por motivos tecnológicos, y a veces por cierta presión). Recientemente un cliente (bastante importante en este país) me ha llamado para decirme que, con 3i gratuíto, iba a eliminar Hyper-V y Xen de sus entornos de desarrollo. Tampoco incluyo dentro de "migrar" la famosa actitud de los clientes de "Sí, hombre, móntalo por ahí y no me des más la barra".... actitud que yo sufrí allá por el 2000 a 2003 cuando empecé con esto de la virtualización.

Ultimo comentario para los que de último se dedican a decir que estoy vendido: Sí, estoy vendido. A la integridad de mis instalaciones, a la satisfacción de mis clientes, a los proyectos cerrados en fecha, a la fiabilidad y, por supuesto, a mi empleador... que no es VMware.

Nota técnica: Virtualización asistida por hardware.

Mucho se habla (y más se hablará) sobre las ventajas e inconvenientes de la Virtualización asistida por Hardware. Los dos contendientes en la Chip Wars, AMD e Intel incorporan en sus chips nuevos juegos de instrucciones que facilitan la virtualización. Por un lado, AMD con Su codename Pacifica, y por otro, Intel con Vanderpool.

Pero antes de hablar sobre estas tecnologías, veamos los tres grandes tipos de virtualización: Emulación, Paravirtualización y traducción binaria.

El método de virtualización con el que creo todos estamos más familiarizados es la emulación. Todos hemos ejecutado el emulador de nintendo, o el de pocket PC, por poner ejemplos. Y todos sabemos cual es su principal problema: La lentitud. El overhead de simular byte a byte un hardware por software hace trabajar a las CPU de manera considerable. El desarrollo de emuladores es una tarea ardua y propensa a errores.

En el otro extremo está la Paravirtualización. La paravirtualización (PV) parte de la base de que el sistema operativo huesped "sabe" perfectamente que está siendo ejecutado en un entorno virtual, y modifica su comportamiento de acuerdo con esto. Los sistemas operativos necesitan ser modificados para adaptarse a un entorno "hardware" virtual, lo que implica que hay una relación directa entre cómo se escribe el kernel del sistema operativo y cómo virtualiza la capa de virtualización. Realmente la Paravirtualización no es virtualización pura, sino más bien una colaboración entre la capa de virtualización y el sistema operativo virtualizado. Esto funciona bastante bien en entornos abiertos, donde el kernel del sistema operativo (como linux o BSD) puede ser modificado para tener en cuenta que "debajo" hay una capa de virtualización, pero en el caso de otros OS'es (como es el caso de Windows), la cosa no está tan clara. En este caso, hablar de rendimiento nativo es realmente relativo, ya que un OS's virtualizado no ejecuta exactamente el mismo código ni opera igual que si corriera en hardware real.

En el medio de estas dos opciones encontramos la, que hasta el momento, parece ser la mejor opción: La traducción binaria. La traducción binaria. La traducción binaria parte de la base de la existencia de un monitor de máquinas virtuales (VMM) que monitoriza a cada segundo las instrucciones que el sistema operativo huesped envía al procesador. Si el VMM detecta una instrucción problemática (que puede afectar al entorno de virtualización, otras VMM o a la estabilidad del hardware hospedador - host), rápidamente la reescribe (muchas veces convirtiendo una sola instrucción en docenas de ellas), y devuelve el resultado al huesped, que interpreta que esa instrucción original ha sido ejecutada. El resto de instrucciones no problemáticas son pasadas directamente al procesador.

Es evidente que reescribir instrucciones no es la manera más rápida de virtualizar, pero sí nos garantiza la ejecución de cualquier OS soportado SIN necesidad de reescribir el kernel del mismo. También abre la puerta a la virtualización de OS's que corren en hardware distinto al de nuestra plataforma base (en este caso, x86, x64, i64)... imaginad AIX corriendo en una VM... o incluso el Cisco IOS... porqué no?

¿porqué es necesario hacer todo esto?... pues básicamente porque la arquitectura x86 no es virtualizable. Entendamos un poco cómo funciona nuestro PC.

Existen, al menos, 4 niveles de privilegio de acceso al procesador, llamados anillos y numerados del 0 al 3, cuya prioridad es inversa a su numeración, aunque en la práctica, sólo se usan el 0 y el 3 (el de mayor y menor prioridad, respectivamente). Los sistemas operativos usan típicamente el anillo 0, mientras que los programas usan, también típicamente, el anillo 3. De hecho, las extensiones de 64 bits de los procesadores x64 sacrifican, en muchos casos, los anilos 1 y 2... No hay demasiada gente que se haya preocupado por ello (¿vosotros lo notáis?)... salvo aquellos que trabajan desarrollando capas de virtualización.

Es evidente que las capas de virtualización (VMware ESX, por ejemplo) se ejecutan en el anillo 0, y para poder mantener constantemente el control del sistema, han de mantener al OS huésped fuera de él. La solución más obvia es, entonces, ejecutarlo en el anillo 1 (por ejemplo). Esto sería una solución gloriosa si no fuera por esa manía de los sistemas operativos de ejecutarse en el anillo 0. En entornos de paravirtualización no hay problema: como el huésped colabora con la capa de virtualización, este puede decidir ejecutarse en anillo 1, por ejemplo, si la capa de virtualización así se lo indica. En la traducción binaria, hay que "obligar" o "engañar" al huesped para que se ejecute en el anillo 1. Esto tampoco parece complicado, salvo porque hay determinadas instrucciones no funcionan o lo hacen de modo extraño si no se ejecutan en el anillo 0 del procesador. La traducción binaria hace eso exactamente: Mentirle al sistema operativo huesped.

La virtualización asistida por hardware entra precisamente en este punto mediante el nuevo modo VMX. Por resumirlo de una manera sencilla (aunque no totalmente exacta), tanto Vanderpool como Pacifica permiten a la capa de virtualización ejecutarse en un "anillo -1", es decir, con mayor prioridad que el 0, de forma que ya no es necesario engañar al sistema operativo. El Virtual Machine Monitor se ejecuta en modo VMX root, mientras las VM se ejecutan en modo VMX. El procesador alterna entre universos mediante los procesos "VM entry" y "VM exit."

Las tecnologías VT permiten movernos (mediante VM entry y VM exit) entre el modo VMX y el VMX root, aislando a nivel de procesador, los universos del Virtual Machine Monitor (VMM) y de la máquina virtual (VM).

¿Maravilloso, No? Pues no... El trabajo de recordar que estaban haciendo el VMM y todas las VM no está implementado a nivel de procesador. El procesador provee mecanismos simples que facilitan al VMM la conservación de estados, pero el trabajo sucio sigue siendo del VMM.

Para quien le interese enterarse en profundidad de qué va todo esto, le recomiendo el siguiente link de donde, y si mi inglés no me ha abandonado, he sacado parte de la información que ofrece este post.

Ahora bien... ¿Vanderpool o Pacífica? Aunque el mecanismo es el mismo, las instrucciones, e incluso el modo de operación, varía. Pacifica parece ser un superset de Vanderpool, ofreciendo más mecanismos en el chip para facilitar la vida de los VMM. Estos comandos extras se agrupan en tres tecnologías propias de AMD, Nested Table Pages, Device Exclusion Vector y el Tagged TLB. Este documento os cuenta más extensamente que hacen estas tecnologías.

Que conste que Pacífica aún no tiene implementadas del todo estas tecnologías, por lo que lo que obtendréis al pagar un AMD con Pacífica es poco más que lo que os dá Vanderpool.

Como resumen, parece ser que Pacífica le pondrá más fácil las cosas a los VMM, mientras que Vanderpool sacrifica funciones en favor de la velocidad.

¿porqué tanto ruido con la virtualización asistida por hardware? Respuesta fácil: es la única manera en que un entorno Paravirtualizado (como Xen o Viridian) pueda ejecutar un sistema operativo sin modificar el kernel. Básicamente el procesador permite a un OS sin modificar instalarse en el anillo 0, dejando el -1 para el VMM. Evidentemente, esto a VMware le hace bastante poca gracia, dado que, en teoría, la traducción binaria ya no haría falta. Digo en teoría porque se me ocurren un par de cositas que la traducción binaria puede solucionar y que me dá a mi que tal y como se llevan Intel y AMD la virtualización asistida no:

• Diferencia entre procesadores: el uso masivo de VT generará una mayor dificultad para el movimiento de VM entre diferentes modelos de procesador. Actualmente VMware "soporta" ligeros cambios de serie (Especialmente en Opterones y Xeones, donde los cambios en los micros suelen estar relacionados con el anillo 0, que se gestiona por Traducción Binaria y no por VT).
• Compatibilidad: La traducción binaria extiende el campo de la virtualización a prácticamente cualquier micro x86 de 32 bits. VT la limita a la incorporación de esta tecnología.
• VT es una tecnología emergente, aún saliendo del horno. Intel ya habla de VT v2, VT v3 y VT v4.... ¿Será la compatibilidad descendente una rémora de rendimiento tal y como lo fueron los 16 bits?
• VT está siendo desarrollada por fabricantes de hardware, no por fabricantes de VMM... y teniendo en cuenta pasadas colaboraciones.... no sé yo que pensar.
• VT limita la virtualización a plataformas x86.... La traducción binaria puede abrir nuevas puertas para la virtualización de otras plataformas.

¿Intereses creados? Todos. A favor: Microsoft el primero, porque si no se olvida de competir con VMware. Xen Enterprise, los segundos porque así pueden ejecutar Windows. Intel y AMD, los terceros, ya que la virtualización les quita "negocio", al menos algo recuperarán con lo que está por venir. En contra: VMware, que ve a la competencia meterse en su nicho privado, que era hasta ahora la ejecución de Windows en una VM.

Mi opinión: Que sobrevivan las dos. Hasta VMware puede sacar partido de VT.

¿Pero es tan realmente importante eso? Yo, personalmente, creo que no. No pienso que lo más importante en un entorno virtualizado sea en qué anillo se ejecute el OS, o la velocidad de ejecución de las máquinas virtuales. Creo que hay cosas más importantes que valorar: Estabilidad, snapshots, movilidad entre hosts, opciones de HA.... se me ocurren mil cosas que pedir antes de mayor o menor velocidad.

¿a vosotros no?

PD. Gura, espero que esto fuera lo que querías, camarada.

Opinión: De dimes y diretes, de powerpoints y de comparar a dios con un gitano.

De último nuestra galaxia se vé convulsa por la guerra en ciernes, de la cual ya sufrimos alguna escaramuza, sobre quien virtualiza mejor, más rápido, y de paso quien la tiene más larga.

Por un lado, Microsoft con su Virtual Server 2005 R2 y su invisible Hypervisor sobre Longhorn (o como quieran llamarlo). Por otro, VMware con su VI3, por otro XenSource 3.x Enterprise... y tras estos, toda una corte de pretendientes buscando su pedazo de tarta en el suculento mercado de la Virtualización... (Virtuozzo, Paralells, VirtualBox, VirtualIron, etc)

Para darte cuenta de que la virtualización es el futuro del utility computing no hace falta trabajar en Gartner ni tener los números directos de los presidentes de las respectivas compañias. No pasará mucho tiempo antes de que los servidores virtuales sobrepasen a los físicos en número, y si no, tiempo al tiempo.

Como armas en estas batallas se emplean términos la mar de originales y especialmente sonoros: Hypervisor, Paravirtualización, Virtualización por Hardware, Hosted virtualization, baremetal.... etc... todo un conjunto de palabros que nadie tiene demasiado claro qué significan.

También, y si no preguntadle a San Google Bendito, patrón de los PowerPoint Users, la red se ha inundado de comparativas, tablas, blogs, comments, sobre qué tecnología es mejor, más rápida o tiene más futuro.

Y encima, a un seguro servidor de Uds., le han liado en esta guerra, por aquello de que uno tiene experiencia, en una especie de "MacroComité de expertos para el análisis y evaluación de soluciones de virtualización corporativa a gran escala", nombre chulo que no implica aumento de sueldo. Desde ese momento, ha habido bombardeo de comparativas, powerpoints, referencias y demás en mi correo.

Definido el escenario, vaya aquí mi opinión. VMware VI3 sería mi elección para los próximos dos años... y ahora os doy mis razones.

La primera es que si VMware me anunciase mañana un sistema operativo de 64 bits para, por ejemplo, motores de base de datos, respondería lo mismo. Mi elección hoy es Microsoft SQL server al menos para los próximos dos años. Sería arriesgado cambiar una opción con más de cinco años en bases de datos por otra que, por mucho que venga de una empresa solvente, está por salir.

Decidirte por una plataforma de virtualización no es fácil. Es un área de contienda relativamente nueva, donde sólo hay una opción establecida: VMware. El resto acaban de llegar... o están llegando (leáse Hypervisor de Microsoft). Lo de ser Beta User en algo de lo que depende la estabilidad de múltiples servidores dista mucho de ser divertido. Aún recuerdo las "travesuras" de VMware ESX 1.0. En su momento, no tuve alternativa (no había otra plataforma de virtualización) y pasaron 4 años hasta que, por fin, puse algo en producción dentro de un ESX. La verdad es que no veo necesidad ninguna de experimentar en producción con Longhorn, Xen, Virtuozzo, etc, cuando tengo ya una plataforma que a mi me parece fiable, potente y estable. Si, probaré en labs, y si algo me gusta de lo que veo, primero lo apuntaré en mi WishList para ESX x.x y le iré dando a lo nuevo algo de vidilla.

Quien pretende utilizar los benchmark como argumento le propongo el siguiente desafío: Poned vuestra base de datos crítica en un P4 overclockeado a 7,8 Ghz (lo han conseguido unos italianos)... ¿a que no se levantan muchas manos? Pues esa es mi postura ante los pretendidos benchmark de que tal tecnología es mejor que tal otra. Mis pruebas me dicen que las VM de ESX son más rápidas que las de la competencia, pero no es algo que me preocupe en demasía: Prefiero los uptime de meses en mis VM, que un winbench (por ejemplo). Yo es que no tengo ningún winbench en producción. Sólo SQLs, file servers, servidores web, etc.

Por el momento, mis comparativas se reducen a Xen contra ESX.... comparar Virtual Server con ESX es francamente injusto para Microsoft. Esperaré a Longhorn para hacerlas.

Cuidado con ser betatester... en producción. Conozco a algún betatester de SQL Server que tuvo que sufrir constantes problemas hasta SQL 2000 SP2. En especial si la virtualización es una necesidad para nosotros. No nos dejemos impresionar por acuerdos como el de Microsoft y Xen (vaya, que recuerdos me trae de otros acuerdos como el de IBM y Microsoft para OS/2), porque no son más que movimientos estratégicos de Microsoft contra su competencia.

Los murmullos no virtualizan. Powerpoint tampoco. Y prometer futuros Service Pack no hace más estable lo que tenemos.

Dos o tres años no son demasiado tiempo en términos de inversión. Podemos estar esos tres años observando al mercado para ver por donde respira. Pero "sufrir" durante tres años un producto nuevo no me parece una experiencia agradable.

Realidades. Con eso trabajamos.

Un saludo.