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/OComo 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ónAunque 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/ODesde 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únSi 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ículaCon 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.