La tecnología de virtualización esta generando profundos cambios, tanto en el mercado de servidores como en los esquemas de licenciamiento de software propietario y también Open Source. VMWare y XenSource, los padres de la criatura, están metiendo cada vez más sus narices en el núcleo de Linux mientras los defensores del software libre ponen el grito en el cielo y Microsoft se ve obligada a "legalizar" la ejecución de Windows en entornos virtuales. Las instancias virtuales de un sistema operativo pueden brindar un mejor desempeño si sus kernels son modificados para comunicarse con el hipervisor sobre el cual se ejecutan. El ejemplo más común de hipervisor es el de Xen, pero el concepto se origina en los sistemas operativos de los mainframes IBM de finales de los años setenta y ha sido utilizado por un largo tiempo. La paravirtualización fue introducida por primera vez en la arquitectura x86 por Xen, debido a que proporciona una mejora de rendimiento sustancial en comparación con la técnica de "reescritura binaria" utilizada por VMware. Esta técnica consiste en interceptar y reemplazar, en tiempo de ejecución, instrucciones críticas no virtualizables. Microsoft VirtualPC es otro software que trabaja de esta forma. La paravirtualización también tiene sus puntos flojos: requiere la modificación del sistema operativo anfitrión para que el diálogo con el hipervisor sea posible. Sin embargo, los beneficios en el rendimiento han llevado a los vendors de sistemas operativos basados en la arquitectura x86 a adoptar esta tecnología en las próximas versiones de sus sistemas. La paravirtualización al estilo Xen obliga a los vendors a incluir un hipervisor en el sistema operativo, cosa que obviamente no es del agrado de VMware. En el caso de Linux y Solaris esto se logra mediante la inclusión del hipervisor de Xen. En el caso de Microsoft, la versión "enlightened" de Longhorn Server OS (Microsoft llama enlightenment a la paravirtualización) poseerá un Windows Hypervisor que será muy similar al hipervisor de Xen. El contraataque de VMWare Mientras XenSource se encargaba religiosamente de ir actualizando el código fuente de los núcleos de kernel.org con la API Xen hypercall, VMware presentó un nuevo concepto en el simposio linux OLS 2005: había nacido VMI (Virtual Machine Interface). VMI es una interfaz de más bajo nivel que Xen hypercall. Es más adecuada para un hipervisor de reescritura binaria como el de VMware y merece ser considerada seriamente porque incluye una nueva y curiosa funcionalidad: el mismo kernel puede ejecutarse en forma nativa y virtualizada. El problema de VMI es que su código es propietario y eso tiene a la comunidad de software libre con los pelos de punta. Aún así, todos coinciden en que tener una interfaz única para múltiples hipervisores es mejor que tener muchas. Así que en la edición 2006 del simposio OLS, XenSource comenzó a trabajar en conjunto con VMware para crear una interfaz común capaz de hablar tanto con VMI como con Xen hypercall. A partir de ahí se ha producido un esfuerzo muy positivo entre empresas como IBM, HP, Red Hat y Novell y numerosos desarrolladores de kernel.org para lograr el objetivo. paravirt_ops Es así como el kernel 2.6.20 incluye paravirt_ops: la flamante interfaz común que permitirá la ejecución tanto de VMware como de Xen. A su vez, se espera que la implementación de VMware llegue en la versión 2.6.21 y la de Xen en la 2.6.22, debido a que XenSource planea incluir algunas características extra en su módulo. Una vez que el trabajo esté completo, los kernels de las distribuciones Linux poseerán el poder de la virtualización en sus propias entrañas, lo que facilitará el proceso de desarrollo de las mismas. Por otra parte (y gracias a la buena relación existente entre XenSource y Microsoft), es razonable esperar que en el futuro los kernels de Linux puedan ejecutar también el Windows Hypervisor. Entonces... ¿todos contentos? No es tan fácil... Seguir leyendo artículo completo
Leer más en www.tomcomputers.com.ar (Fuente original)