Estado del arte
En lo que respecta a sistemas de virtualización de software libre, podemos decir que en la actualidad son dos los principales proyectos que más atención reciben por parte de la comunidad.
Xen apareció como proyecto de investigación en la universidad de Cambridge y vio la luz al público en 2003 cuando fue fundada XenSource por parte de Ian Pratt, compañía que maneja el desarrollo de la versión de código abierto de Xen y comercializa las versiones empresariales. En 2007 la empresa XenSource fue adquirida por Citrix Systems lo cual levantó muchas suspicacias y temores respecto al futuro del proyecto de código abierto, actualmente su desarrollo lo dirige la Xen advisory board (Xen AB) en la que se pueden encontrar miembros de Citrix, IBM, Intel, HP, Novell, Red Hat, Sun Microsystems y Oracle con lo cual podríamos decir que usa el paradigma de desarrollo “Open Monarchy”.
Por otra parte, KVM apareció en febrero del 2007 con el kernel Linux 2.6.20, su principal programador es Avi Kivity y recibe apoyo económico de la start up Qumranet (en la actualidad parte de Red Hat) y la podemos identificar más con el paradigma de desarrollo “Consensus-based development” o desarrollo basado en consenso, de hecho si nos fijamos en la web de KVM hay una lista de cosas por hacer que cualquier colaborador puede abordar, además de contar con una comunidad más saludable que la concerniente a Xen.
En la actualidad hay varias empresas con un creciente interés por la virtualización, con la compra de Sun Microsystems por parte de Oracle esta compañía adquiere Virtualbox además de las tecnologías de virtualización usadas en Solaris (los llamados “containers”), contando anteriormente con Oracle VM (basado en Xen). Además con la creación del estándar OVF (Open Virtual Machine Format) en septiembre de 2008 por parte de empresas como Dell, HP, IBM, Microsoft, VMware y XenSource denota que la virtualización puede y debe jugar un papel importante en el desarrollo de los entornos de servidores en un futuro no muy lejano, y por la parte que toca al software libre ya hay soporte OVF en Virtualbox y Xen. Además, siguen apareciendo proyectos muy ligados a la virtualización como los routers o switches virtuales para entornos de red virtualizados, Managers o herramientas de administración de sistemas virtuales.
Software de Virtualización
Una vez aclarados los métodos usados para conseguir la virtualización de un sistema, expondremos las peculiaridades de los diferentes proyectos mencionados como ejemplos.
Bochs y QEMU
Bochs es un emulador x86 destinado a ser portable y capaz de ejecutarse en plataformas x86, PPC, Alpha, SPARC y MIPS. Lo que lo hace especial es el hecho de que simula todo el hardware incluídos los periféricos, pudiendo ser configurado como un antiguo 80386 o sus sucesores (486, Pentium, Pentium Pro...) emulando incluso instrucciones avanzadas como MMX y 3DNow.
QEMU aprovecha parte del desarrollo de Bochs, aportando dos modos de uso. El primero emula el sistema completo, siendo capaz de emular plataformas x86, x86-64, ARM, SPARC, PPC y MIPS con una velocidad de ejecución razonable usando traducción de código dinámica. El segundo modo de uso, llamado “User Mode Emulation” y solamente disponible bajo Linux, nos permite ejecutar un binario destinado a una arquitectura diferente de la que usa la máquina anfitrión (por ejemplo, ejecutando un binario compilado para SPARC en una máquina X86).
VServer
VServer es un parche para el kernel Linux basado en particiones, mediante las cuales se crean servidores virtuales privados aislados ejecutándose simultáneamente en una máquina anfitriona y compartiendo sus recursos. Para asegurarse de que son servidores independientes, se separan los procesos de cada máquina virtual y solo los procesos pertenecientes a cada máquina son visibles entre sí. Dicho comportamiento se obtiene modificando el sistema operativo anfitrión añadiendo una etiqueta de contexto a la ID de cada proceso. Para asegurarse de que cada usuario se limita al uso de su máquina virtual VServer usa una versión modificada del comando chroot, denegando el acceso a directorios pertenecientes a contextos (máquinas virtuales) diferentes.
El hecho de necesitar un parche del kernel limita la portabilidad de VServer, además de no permitir la instalación de sistemas operativos diferentes al anfitrión, aunque aporta la ventaja de tener un rendimiento muy parecido al que tendría la ejecución de código directamente en la máquina anfitriona sin el uso de instrucciones especiales por parte de la CPU ni necesidad de hardware específico.
OpenVZ
Es una solución bastante parecida a VServer, pero con algunas diferencias notables que son dignas de mención especial. OpenVZ se trata de un kernel modificado que soporta espacios de usuario aislados con un conjunto de herramientas para su mantenimiento y manejo tales como vzctl o vzlist. Además incluye un sistema de monitorización de dos niveles, manejando primero las prioridades entre las máquinas virtuales y después las prioridades entre los procesos de cada máquina virtual. OpenVZ permite también controlar la distribución de recursos de la máquina anfitriona mediante “beancounters” y la creación de Checkpoints para migrar una máquina virtual a otro sistema anfitrión como si fuera una fotografía instantánea, congelando el estado de un sistema virtual y guardándolo en un archivo que podremos mover a otro anfitrión y ejecutarlo en el mismo estado en el cual lo congelamos en el anterior anfitrión.
UML
User-mode Linux permite a un sistema Linux ejecutar otro sistema Linux dentro del espacio de usuario, existiendo cada sistema huésped en un proceso del sistema anfitrión y permitiendo ejecutar varios kernels Linux con su correspondiente espacio de usuario dentro del contexto de un solo kernel Linux.
A partir de la rama 2.6 del kernel el código de UML está incorporado en el mismo pero debe ser activado y recompilado para poder usarlo. Hemos de tener en cuenta que al ejecutarse un kernel en un espacio dedicado a aplicaciones, se hace necesario recompilar el kernel para su uso.
Xen
Mediante cambios en el sistema operativo se consigue que el hipervisor y el sistema operativo colaboren en la virtualización, obteniendo resultados muy cercanos a la ejecución nativa de código dentro de un sistema virtualizado.
Teniendo en cuenta que solamente los sistemas modificados especialmente para Xen se pueden correr bajo el mismo, Xen parte con la desventaja de que sistemas privativos necesitan ser portados y modificados por sus creadores.
Xen crea un domain0 (dominio) al iniciar la maquina anfitriona, el cual accede a un interfaz de control y ejecuta el software encargado del manejo de la capa de aplicaciones. Además este dominio principal permite iniciar y apagar otros dominios donde los sistemas huéspedes se ejecutan.
Para implementar la virtualización Xen usa diferentes herramientas. Ofrece dos tipos diferentes de planificadores de tareas, uno que reparte proporcionalmente el tiempo de CPU y otro llamado “Atropos” que es un planificador en tiempo real, el cual es capaz de repartir eficientemente los tiempos de CPU entre los distintos dominios en base a sus necesidades puntuales. En cuanto a la memoria, Xen reserva una parte fija de la memoria del anfitrión para su uso en el huésped elegida en su creación y modificable sin necesidad de apagar o reiniciar el dominio. Respecto a la red, cada dominio tiene una o más interfaces de red y la comunicación entre interfaces se realiza mediante dos buffers token ring.
Con el uso de VT-x o AMD-V (Pacifica) es posible el uso de sistemas huésped sin modificar, lo cual supuso un gran avance para el proyecto con respecto al soporte de sistemas privativos. Entre los sistemas soportados por Xen podemos encontrar Linux, Minix, Plan9, NetBSD, FreeBSD, OpenSolaris, NetWare, GNU/Hurd y OZONE.
Linux KVM (Kernel Virtual Machine)
Incluido en el kernel desde su versión 2.6.20, se trata de una solución de virtualización completa para Linux en hardware x86 con hardware que incluya instrucciones de virtualización (VT-x y AMD-V). Se compone de un módulo principal que provee las capacidades de virtualización, un módulo específico dependiendo de si se usa un procesador Intel o AMD y una versión modificada de QEMU, aunque el equipo de desarrollo trabaja para no depender de QEMU.
Soporta un buen número de sistemas huésped (actualizado a menudo en la web del proyecto), migración de huéspedes al vuelo para sistemas en ejecución o parados, huéspedes Linux, Unix y Windows en 32 y 64 bits (dependiendo del hardware anfitrión) y uso de multiprocesador en anfitrión y huéspedes (hasta 16 CPUs).
A día de hoy es el proyecto que más revuelo y atención ha causado en la comunidad y mantiene una sana rivalidad con el proyecto Xen, aunque debemos apuntar que nos encontramos ante dos proyectos que usan métodos de virtualización distintos. Actualmente KVM tiene planeado el uso de Paravirtualización para determinados puntos del software como paravirtualización a nivel de red o del bloque de entrada/salida, además de trabajar en versiones para plataforma PPC, IA64 y un proyecto para ejecutar kernels huésped de Xen (proyecto Xenner).
Virtualbox
Otro de los grandes contendientes en el panorama de la virtualización Open Source, su trasfondo proviene de la empresa alemana Innotek GmbH que pasó a manos de Sun Microsystems en febrero de 2008. Una parte de la comunidad más purista lo deja de lado por ser software con licencias duales. La parte primordial de código está licenciada bajo GPL mientras que ciertos componentes de uso más específico en entornos de producción (control remoto de máquinas virtuales mediante servidor RDP, controladoras virtuales USB y acceso USB mediante RDP) tienen licencias propietarias que restringen su uso.
En cuanto a características, podemos remarcar el soporte experimental de aceleración 3D en sistemas huésped Linux o Windows, una API pública en lo que respecta a la configuración y control de ejecución de las máquinas virtuales, soporte OVF y iSCSI.
En este caso se trata de una solución de virtualización completa x86 capaz de usar instrucciones específicas de virtualización hardware (VT-x y AMD-V) y dar soporte con optimizaciones para los sistemas operativos más usados en entornos de servidor, Windows, Unix y Solaris, además de implementar ciertas optimizaciones para OS/2.
A la hora de ejecutar código, VirtualBox trata por todos los medios de ejecutar código de forma nativa, en caso de no poder hacerlo usa un motor de recompilado basado en QEMU. Además usa un método de desensamblado y parcheo de código de manera que un mismo programa solo necesita ser recompilado una sola vez, ganando agilidad a la hora de subsiguientes ejecuciones y consiguiendo rendimientos muy cercanos a soluciones de software privativo como VMware.
La virtualización en entornos de Software Libre por
Francisco García Pacheco está licenciada bajo
Creative Commons Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España License.