sábado, 11 de octubre de 2008

Microsoft, el eterno malo de la película

En los últimos días se ha abierto una pequeña discusión en el blog del amigo J.L. Medina acerca de Hyper-V y ESX. Uno de los temas que se critican en la arquitectura de Hyper-V es la dependencia de los drivers I/O de terceros en la Root Partition.

Virtualización I/O

Como comente, los drivers I/O que utiliza VMware no están escritos desde cero por VMware, están basados en los drivers que los fabricantes programan para Linux. Estos drivers al ser open-source, son adaptados y modificados por VMware para ejecutarse como módulos dentro del vmkernel, de ahí que la HCL sea mas reducida. Estos drivers los podéis descargar y veréis que no tienen mucha diferencia con el driver original del fabricante.

La diferencia de arquitectura es que VMware incluye los drivers I/O dentro de su hypervisor y Hyper-V, al igual que Xen, depende de los drivers cargados en un sistema operativo en la Root Partition o Dom0. En mi humilde opinión, la estabilidad y eficiencia de un driver puede ser la misma en una capa que en la otra, y ambas capas tienen acceso privilegiado al dispositivo. Porque se critica esta arquitectura?

Porque todos los hypervisors modernos, véase Xen, Hyper-V o KVM, están utilizando esta arquitectura? Están todos equivocados? Creo que la función de un hypervisor, entre otras, es de gestionar el scheduling de I/O entre las maquinas virtuales, no la de ser un sistema operativo completo. Veis normal que el hypervisor incluya también el driver de LVM o de TCP/IP como hace el vmkernel? Siguiendo ese razonamiento el hypervisor debería acabar convirtiéndose en un sistema operativo, con la complejidad que eso conlleva. Pienso que teniendo sistemas operativos robustos no veo la necesidad de crear uno nuevo.

Me inclino más a pensar que la diferencia de arquitecturas radica en que VMware nunca ha querido depender del kernel de Linux porque no lo controla. Seguramente si VMware tuviera un sistema operativo propio o si hubieran podido modificar el kernel a su antojo, sin tener que publicar los cambios, la arquitectura podría haber sido totalmente distinta. En este sentido, Microsoft controla el sistema operativo y el hypervisor, y ahí pueden hacer lo que quieran sin tener que dar explicaciones a nadie. A VMware le interesa ir metiendo todo lo que pueda dentro del hypervisor y quitarse la dependencia de GNU/Linux, y poco a poco parece que lo irá haciendo.

Por favor señores, cuando critiquemos algo hagámoslo con argumentos sólidos. Me sorprende que la ultima comparativa oficial de VMware para defender VMware ESX respecto a Hyper-V se base en los clicks de ratón que hacen falta para instalarlo y configurar iSCSI. Porque si algo hemos aprendido en los últimos años es que en facilidad de manejo y experiencia de usuario final a Microsoft no le supera nadie.

Hyper-V en producción

Aunque no son equiparables al número de instalaciones de VMware, si que hay instalaciones de Hyper-V en producción . Pero centrémonos en la que todos conocemos: MSDN y TechNet.
  • MSDN sirve más de 3 millones de páginas por día.
  • TechNet sirve más de un millón de páginas por día.
Podéis consultar el ranking Alexa de páginas mas visitadas y pocas empresas españolas encontrareis que lleguen a esas cifras. Significa esto que Hyper-V es valido para cualquier empresa española? Creo que la respuesta correcta es que depende de las necesidades. Yo personalmente recomiendo VMware, pero eso no quiere decir que Hyper-V no sea valido para cierto tipo de proyectos.

Que la solución mas completa a día de hoy es la de VMware es evidente, pero que Microsoft lo esta haciendo bien también lo es.

Alguien tiene datos que yo no conozca sobre el mal rendimiento I/O de Xen o Hyper-V por utilizar esta arquitectura respecto a VMware?

Mejoras en la virtualización I/O

Desde luego el I/O no ha sido el punto fuerte de VMware ni de ningún hypervisor en estos años. Actualmente han conseguido reducir la penalización en CPU prácticamente a cero, pero no ocurre lo mismo con la virtualizacion I/O. VMware lleva desde el año 2006 hablando de “Passthrough I/O”, ahora rebautizado bajo el nombre de VMDirectPath.

En breve, gracias a VMDirectPath y a la virtualización asistada por hardware tendremos la posibilidad de que las maquinas virtuales se salten el VMM y accedan directamente a los dispositivos físicos consiguiendo mejoras sustanciales en el campo de la virtualizacion I/O. Pero a que coste?
  • Comprar servidores nuevos con procesadores Intel VT-d o AMD IOMMU.
  • Dispositivos I/O que soporten SR-IOV y NICs que soporten múltiples colas VMDq.
  • Imposibilidad de hacer VMotion.
  • Imposibilidad de Suspender/Resumir las maquinas virtuales.
  • Imposibilidad de compartir el mismo dispositivo físico con varias maquinas virtuales.
  • Instalación en el GuestOS de drivers especiales para reconocer el dispositivo físico.
Estamos volviendo hacia atrás o me lo parece a mi? Vendrán los vApps/Virtual Appliances con miles de drivers para soportar cualquier dispositivo fisico? Es de suponer, que todas estas limitaciones se iran salvando con el tiempo.

Sentido común

Si nos guiamos por el sentido común en temas de arquitectuara, a mí ahora se me viene a la cabeza el tema de los 32-bit del vmkernel de VMware. Recordemos que el hypervisor de VMware esta formado por dos capas diferenciables: el vmkernel y VMM. El vmkernel, a día de hoy, es de 32-bit y es el encargado de gestionar I/O, memoria y CPU así como de cargar los drivers para interactuar con el Hardware que comentabamos anteriormente. Por otro lado, el monitor VMM que se instancia a cada VM puede ser de 32-bit o de 64-bit. Gracias a esta separación entre vmkernel de 32-bit y VMM de 64-bit, y con la ayuda de VT-x ,VMware ESX puede ejecutar GuestOS de 64-bit.

Es la mejor solución desde el punto de vista técnico? Creo que no, pero brillante desde luego que si lo es. De este modo, VMware se ha evitado la presión de tener que migrar a 64-bit el vmkernel y la SC durante mucho tiempo para poder ejecutar maquinas virtuales de 64-bit. Ahora con ESX4, ya han hecho el esfuerzo de migrar todo a 64-bit.

Yo nunca he criticado esta solución aunque el mercado, sobre todo Citrix, si lo ha hecho sin ninguna razón.

Microsoft, el eterno malo de la película

Con lo que no estoy de acuerdo es en criticar todo lo que hace un fabricante. Microsoft tiene productos muy buenos y otros no tan buenos. Microsoft tiene gente brillante, al igual que la tiene VMware.

Estamos acostumbrados a ver como Microsoft siempre llega tarde con sus productos, pero cuando llega sabe posicionarlos muy bien. Solo hay que ver como ha posicionado Windows Server, SQL Server, Exchange o Internet Explorer en un mercado ya liderado con soluciones fantásticas. Que lo ha hecho con una política y un marketing agresivo? Correcto, eso nadie lo duda. Pero y que empresario no haría lo mismo por su empresa?

Microsoft, con su solución de virtualización, ha llegado el ultimo y se le pueden echar en falta cosas como LiveMigration, Cluster Filesystem, soporte para mas GuestOS, etc.. cosas que nadie duda tendrá con el tiempo y que VMware tampoco tuvo en su primera versión.

Recordemos que el VMFS v1 de ESX 1.5 no era un cluster-filesystem y no podía ser compartido entre varios hosts, no había VMotion, no había vCenter, la arquitectura I/O de dispositivos compartidos entre SC y VMKernel, etc…

Esta claro, y eso no lo discute nadie, que a día de hoy VMware tiene una posición inmejorable. Pero no olvidemos que otros fabricantes han estado en la misma posición. No olvidemos empresas como Sun Microsystems, Novell, IBM, Netscape, Citrix y otras muchas que se quedaron en el camino. Todas ellas tenían una posición inmejorable en el mercado con sus productos respecto a los equivalentes de Microsoft.

4 comentarios:

J. L. Medina dijo...

a la pregunta de "¿Porque todos los hypervisors modernos, véase Xen, Hyper-V o KVM, están utilizando esta arquitectura? Están todos equivocados?"

No, no están equivocados. Es que dependen de Intel/AMD VT.

Al igual que mi sentido común me dice que no ponga el VMFS en un target iSCSI virtualizado si espero rendimiento, el mismo me dice que no confíe en una VM, por muy DOM0 que sea.

Respecto a:

"Comprar servidores nuevos con procesadores Intel VT-d o AMD IOMMU."

Bueno, eso también tuviste que hacerlo para pasarte a Xen y derivados. Sin VT no eras nadie. ¿Quieres IOMMU? pues a cambiar el Hard.


Dispositivos I/O que soporten SR-IOV y NICs que soporten múltiples colas VMDq.

Vamos... evidente. ¿Quieres una nueva prestación? Actualiza.

Imposibilidad de hacer VMotion.

Eso está por ver.

Imposibilidad de Suspender/Resumir las maquinas virtuales.

Eso está por ver.

Imposibilidad de compartir el mismo dispositivo físico con varias maquinas virtuales.

También está por ver.

Instalación en el GuestOS de drivers especiales para reconocer el dispositivo físico.

Vamos, también una novedad ¿O es que el vmxnet no hacía eso?

Que Microsoft innove me parece estupendo. Que se lance sobre los que no estamos de acuerdo criticando nuestras elecciones (sin tener producto, a los últimos meses del 2007 me remito) sí que no.

Respecto a MSDN virtualizado... no dejan de ser web servers. Penoso espectáculo daríamos los que nos dedicásemos a esto si a esta altura no pudiésemos virtualizar web servers de producción.

Alberto Gonzalez dijo...

J.L., Intel VT no tiene nada que ver con la arquitectura I/O que comentamos.

Intel VT, a día de hoy, solo ayuda al hypervisor en la virtualización de CPU.

VMware también depende de Intel VT para virtualizar 64-bits y cada vez dependerá más de esta tecnología, véase EVC, VMDirectPath, etc.. Significa esto que la traslación binaria y demás genialidades de VMware pasaran a mejor vida? Yo pienso que con el tiempo si y esto ayudara a simplificar y descargar al hypervisor de trabajo innecesario que puede realizar el hardware.

Vuelvo a lanzar la pregunta: ¿Porque todos los hypervisors modernos, véase Xen, Hyper-V o KVM, están utilizando esta arquitectura de depender de drivers I/O que se ejecutan en un dominio privilegiado y no en el hypervisor?

Sobre las limitaciones de VMDirectPath no las digo yo, las dice VMware:

http://www.youtube.com/watch?v=WhMkmTqBbUA

Que con el tiempo buscaran alternativas? Seguro. Pero creo que lo que vamos a ver en breve es lo que comento.

vmxnet es un driver paravirtualizado que es independiente del hardware en el que se ejecute la maquina virtual, no ocurre lo mismo con los drivers necesarios para utilizar VMDirectPath.

Lo que yo quería decir, es que si me descargo una vApp/Virtual Appliance, por ejemplo que hace las funciones de servidor de fax, tendrá que traer los drivers para reconocer cada uno de los dispositivos físico PCI/FAX que existan en el mercado. Ya no es un solo driver paravirtualizado, es uno para cada dispositivo físico de cada fabricante.

J. L. Medina dijo...

"J.L., Intel VT no tiene nada que ver con la arquitectura I/O que comentamos.<"

Disiento. Precisamente por no poder virtualizar sin VT (lo que convierte al hypervisor en algo extremadamente dependiente del procesador, el DOM0 ha de encargarse del I/O. No hay otro sitio donde ponerlo.

"VMware también depende de Intel VT para virtualizar 64-bits"

Evidentemente... te recuerdo que la arquitectura EMT64 no es 64 bits pura (como lo es Itanium). En AMD no necesitas AMD/V para ejecutar 64bits.... son 64 bits puros. Quejas, a Intel.

"vmxnet es un driver paravirtualizado que es independiente del hardware en el que se ejecute la maquina virtual, no ocurre lo mismo con los drivers necesarios para utilizar VMDirectPath."

Tecnicismos aparte, es un driver especial para usar una característica especial. ¿Cuál es la diferencia?

"Lo que yo quería decir, es que si me descargo una vApp/Virtual Appliance, por ejemplo que hace las funciones de servidor de fax, tendrá que traer los drivers para reconocer cada uno de los dispositivos físico PCI/FAX que existan en el mercado. Ya no es un solo driver paravirtualizado, es uno para cada dispositivo físico de cada fabricante."

Respecto a la traslación binaria... Intenta mover una VM corriendo bajo Xen entre un Opteron serie D y un serie E... verás cómo la echas en falta.

Vamos a ver.... ¿de qué estamos hablando? ¿De nuestro servidor que virtualiza cuatro cosas en casa o de datacenters y tendencias? El hardware se especializa para adaptarse a los requerimientos de los entornos de virtualización. Nuevos requerimientos, nuevas soluciones. IBM cambió su hardware cuando comenzó a particionar... y sigue haciéndolo en sus máquinas particionables. Le guste o no le guste a algunos, la virtualización con mayúsculas (la de verdad, no la de ratios 1:4, porque esa no ahorra costes, eso es una prueba de concepto), requiere de soluciones específicas, al igual que en comunicaciones, y dependiendo del tipo de tráfico, hay switches wiring-closet y switches core. Las tecnologías de uno y otro (y a veces hasta los requerimientos de cableado) no son los mismos. En virtualización pasará lo mismo: Productos low, med y high end. Si vas a high end, tendrás que invertir en nuevas tecnologías. VMDq, IOMMU y algunas más son tecnologías propietaras de cada uno de sus fabricantes: El camino es exigir estándares y no el descartar nuevas tecnologías porque no nos sean cómodas. Y como siempre digo, nuevas tecnologías, nuevos problemas. Para eso nos pagan.

PD: Respecto a lo que diga VMware, suelo hacerle casi tan poco caso como a lo que dice Microsoft (reconozco que al marqueting de MS le tengo alergia). El futuro hablará, y me temo que irá por la especialización. Al igual que hace no tantos años los routers eran máquinas Solaris con un par de demonios y hoy en día son máquinas especializadas, la virtualización irá por el mismo camino... porque los clientes así lo requieren. Y al igual que hay routers de low-end (Zyxel, etc), Mid y High (Cisco, juniper, etc), habrá hypervisores Low end, mid y High... y que cada uno ponga el fabricante que quiera dentro de cada características.

Un saludo.

Alberto Gonzalez dijo...

Xen depende de VT para virtualizar Windows, Xen siempre ha podido virtualizar sistemas operativos paravirtualizados sin depender de VT. La gestión de dispositivos I/O la podían haber incluido en el hypervisor perfectamente, sigo sin ver porque dices que esto no es posible?

Al igual que podían haber metido LVM, NFS client, TCP/IP. Pero para que duplicar y mantener otra vez una versión especifica de estos módulos para Xen si este trabajo ya lo hace bien el sistema operativo del dom0?

No estoy de acuerdo en lo que comentas de AMD. La de AMD tampoco es una arquitectura "pura" de 64 bits, AMD64 es una arquitectura basada en la extensión del conjunto de instrucciones x86 para manejar direcciones de 64 bits, lo que conocemos como arquitectura x86-64. Exactamente lo mismo que Intel EM64T.

El problema de virtualizar 64-bits radicaba en un mecanismo de protección de segmentos de memoria que fue eliminado hace tiempo de los procesadores x86 porque los sistemas operativos no lo utilizaban.

Esta característica fue añadida de nuevo a los Opteron apartir de la Rev E, de ahí que puedan virtualizar 64-bits sin AMD-V. Pero al final necesitas una funcionalidad del procesador que antes no era necesaria, llámala como quieras Intel X o AMD Y.

Respecto a migrar una maquina virtual entre AMD Opteron Rev D y Rev E es un mal ejemplo porque VMware nunca ha soportado este tipo de migraciones tampoco (KB1992), de ahí que hayan trabajado junto a los fabricantes de procesadores para desarrollar FlexMigration/Extended Migration. Xen a día de hoy también soporta esta tecnología.

Lo que esta claro es que hoy en día el negocio ya no esta en los hypervisors, sino en todo el entorno y funcionalidades que lo rodean. El hypervisor debe ser como el kernel del sistema operativo en el que cada fabricante tiene una arquitectura, unos algoritmos de gestión de procesos, I/O , etc. Pero alguien piensa que el éxito de Apple MacOS se debe a su arquitectura basada en Mach/BSD o que el éxito de Windows Server radica en su kernel?