El enfoque técnico y evolutivo de los sistemas de virtualización.
ABSTRACT
La industria informática se encuentra frente al resurgimiento de los sistemas de Virtualización. Éstos aparecieron en la década de los 60 del siglo pasado y evolucionaron junto al resto de la informática durante años. Pero no fue hasta hace pocos años que los sistemas de Virtualización se han metido de lleno en la agenda de desarrolladores, administradores de red y gerentes de IT de pequeñas y medianas empresas. En este artículo se introduce al lector en los aspectos técnicos de la virtualización y se realiza un breve paneo sobre las opciones comerciales y la historia de dichos sistemas. Desde los VM/370 de IBM pasando por VMware y llegando a Intel-VT y AMD-V se han recorrido décadas de avances y nuevas ideas que ya están impactando en la forma de trabajar de muchos de nosotros.
INTRODUCCIÓN
QUÉ ES UNA MÁQUINA VIRTUAL
Una máquina virtual es una ilusión de una máquina real [1]. Se trata de una ilusión creada por un programa o sistema operativo que hace creer a otro sistema operativo que tiene acceso a todo el hardware de un computador para sí mismo.
De la forma que conocemos un sistema operativo, nos referimos en general a que es un componente de software que se utiliza para administrar y aprovechar el hardware del computador. Sobre él, se instalan aplicaciones que nos ayudarán a resolver una problemática específica. Pero aunque ésta es una definición muy acotada y se pueden encontrar otros componentes de software que administran hardware, para el objetivo de este artículo será considerada como suficiente.
Debe aclararse en la definición anterior que un sistema operativo fue creado para ser el único componente de software que administra el hardware. Cuando un usuario o una aplicación requieren acceso a un dispositivo de hardware, deben hacerlo a través del sistema operativo. Si ese no fuera el caso, diferentes componentes de software podrían tratar de utilizar un mismo recurso de hardware a la misma vez y llevaría a resultados indeseables que limitarían el aprovechamiento del hardware o del computador entero.Es así que se puede deducir que el sistema operativo, para cumplir con la administración de los recursos de hardware, debe ser el único administrador permitido. Pero en los sistemas con máquinas virtuales, no sucede de esa forma, sino que debe alternarse de forma ordenada el uso de los recursos, o buscarse alguna forma de encapsulamiento. El soporte para máquinas virtuales creará ilusiones de hardware sobre las cuales se podrá correr otro sistema operativo. De esta forma, los sistemas operativos que llamaremos “guests” o “invitados” tendrán la ilusión de que están administrando un hardware que en realidad es una representación (por eso “virtual”) de un hardware real. El hardware real estará administrado en última instancia por otro sistema operativo, cuya tarea será responder al sistema operativo invitado como si el hardware fuera solo para él.
Pero la complejidad, además del inherentemente técnico a cada arquitectura, está en que un sistema operativo de máquinas virtuales debe tener la capacidad de administrar varios sistemas invitados a la misma vez y responder a cada uno de ellos de forma lo más equitativamente posible.
Pero la industria informática no solo desarrolló sistemas que puedan correr varios sistemas operativos a la misma vez sobre un mismo hardware, sino que se esfuerza por hacer que varios sistemas operativos diferentes convivan de la misma forma. Dietel cita en la carátula del capítulo “Estudio de caso: VM un sistema operativo de máquina virtual” a Robert J. Creasy quien escribiera: Si es posible atribuir convicciones políticas a los sistemas operativos, [entonces el programa de control (CP) de VM] es sin duda el más igualitario. Todos los sistemas operativos son bienvenidos.
VMM O HYPERVISOR
Dos de los términos que deben concerse para continuar con el estudio de la virtualización son VMM (Virtual Machine Monitor, Monitor de Máquina Virtual) e Hypervisor. Ambos, indistintamente, se refieren a una capa de software que corre directamente sobre el hardware (Hypervisor de Tipo 1) o que corre sobre otro sistema operativo (Hypervisor de Tipo 2).
El objetivo de un VMM o Hypervisor es lograr el particionamiento de hardware que requiere la virtualización y realizar la administración de los recursos para que sean compartidos entre los sistemas operativos invitados.
De aquí en más, podrán usarse ambos términos de acuerdo al uso que le da la literatura consultada y manteniendo como modo habitual el de VMM. Sin embargo, podrán encontrarse casos en los que algunos autores mencionan al Hypervisor como un componente de un VMM.
DÓNDE VEMOS MÁQUINAS VIRTUALES HOY EN DÍA
Hoy en día, el concepto de máquina virtual está presente en muchos aspectos informáticos cotidianos, y no solo en grandes empresas que tengan necesidad de correr varios sistemas operativos en un hardware específico, como es el caso de z/VM de IBM [10]. Éste es un sistema de virtualización que puede correr miles de máquinas virtuales con Linux. Sino que el concepto de máquina virtual está presente en la computadora que mucho de nosotros usamos en nuestro trabajo diario.
En cuanto al trabajo de desarrolladores de software, está muy difundido el uso de máquinas virtuales basadas en VMware o Microsoft Virtual PC. De esta forma se pueden mantener sistemas operativos y productos específicos que se reutilizan y sobre los cuales se desarrolla una única solución, evitando que varias soluciones convivan en un mismo entorno y puedan interferirse entre ellas.
En las empresas [6] también se ven sistemas virtualizados, ya que tienen como beneficio mantener en un solo computador físico a varios sistemas antiguos o poco escalables. Estos, que por sus características estarían desperdiciando capacidades físicas para las cuales no fueron creados, pero sin embargo, tener varios de ellos en un solo gran computador, los haría rentables.
ORÍGENES Y DESARROLLO ACTUAL
Entre los sistemas de tiempo compartido de la década de los 60 estaba CP/CMS, el cual se terminaría convirtiendo en el sistema operativo VM de IBM. De CP/CMS existieron 3 versiones CP-40/CMS, CP-67/CMS y CP370/CMS. Éste último fue la base para que en junio de 1970, IBM anunciara el sistema VM/370 [7].IBM continuó con el desarrollo de sus sistemas operativos de VM hasta llegar al actual z/VM, anunciado el 3 de octubre de 2000 y que el 6 de febrero de 2007 conoció a su versión 5.3 [10].
Pero no solo IBM ha participado de la creación de sistemas de máquinas virtuales. Otras empresas como Connectix, VMware y SWsoft, entre otras, han contribuido al desarrollo y distribución de sistemas de máquinas virtuales.Connectix fundada en 1998 produjo varios productos para Mac, un emulador de PlayStation también para Mac y los productos Virtual PC y Virtual Server. Estos dos últimos fueron comprados por Microsoft en 2003 al disolverse Connectix. Virtual PC corría sobre Mac y sobre Windows, permitiendo correr un Windows dentro de una Mac. Microsoft continuó su desarrollo y hoy ofrece Virtual PC para Mac y Windows, y Virtual Server para Windows. La siguiente evolución en esta línea será la integración de las tecnologías de virtualización dentro de Windows Server “Longhorn”, la versión de Windows Server que se espera será lanzada para el año 2008 [15].
VMware es una compañía fundada en 1998 que en 1999 presentó su producto estrella, VMware Workstartion. Según el sitio web de VMware, solo este producto ha ganado 100 premios a mejor producto. Toda la gama de productos de VMware está dedicada a máquinas virtuales con varios enfoques tecnológicos y de negocios diferentes. VMware fue el primer producto de virtualización para procesadores x86 desarrollado por sus fundadores luego de una investigación que realizaran en la Universidad de Stanford [12].
SWsoft, fundada en 1999, es propietaria de Parallels y Virtuozzo, empresas que desarrollan programas de virtualización. También mantiene un projecto “Open Source” de virtualización llamado OpenVZ. [16]
Así como las anteriores, existen otras empresas que ofrecen productos de virtualización, así como también existen varios proyectos de la comunidad “open source”.
COMO SE COMPARTEN RECURSOS ENTRE LOS SISTEMAS OPERATIVOS INVITADOS [13]
Zeichick nos ofrece una excelente y resumida descripción sobre la teoría de cómo se realiza el uso de los recursos compartidos entre los sistemas operativos invitados de un VMM.
Como todos los sistemas operativos, un VMM carga aplicaciones. En el caso de los VMM, las aplicaciones que sobre él corren son otros sistemas operativos. Y el objetivo del VMM es correrlos al mismo tiempo y compartiendo recursos.Se pueden encontrar tres formas de compartir recursos. Algunos recursos se comparten por tiempo, como puede ser el procesador, el cual es utilizado por cada invitado de acuerdo a algún tipo de programación de procesos.
Algunos recursos pueden no ser compartidos, por lo cual se les da el acceso exclusivo a un sistema operativo invitado específico. Para ilustrar el caso, se pude mencionar una tarjeta de red la cual se defina pueda ser utilizada por un único sistema invitado.
Otra forma de compartir o dividir los recursos entre los sistemas invitados, es dividiéndolos de forma virtual en varios recursos. De esta forma, el VMM manipula de forma activa pero transparente el canal de I/O del dispositivo. El caso que ejemplifica también puede ser una tarjeta de red. Cada nueva tarjeta de red virtual que utiliza el hardware real tendrá su propia dirección MAC y por lo tanto, diferente dirección IP. Cada vez que el VMM permita transmitir a un sistema invitado, hará comportarse a la tarjeta real como si fuera la virtual que enmascara.Otro caso son los discos, en el cual el VMM destina una parte del disco para cada sistema invitado. En este caso, redirecciona las llamadas de I/O del sistema invitado a la porción del disco que le corresponde, no permitiendo que otro sistema invitado acceda a un disco que no le pertenece.
TIPOS DE VIRTUALIZACIÓN [4]
Tal cual se presentara en la introducción existen varios enfoques tecnológicos de virtualización. Para este artículo se presentará la propuesta por Abramsom et al de Intel. Los autores identifican 3 tipos distintos de virtualización dependiendo de la posición que ocupa el VMM en la arquitectura de la solución de virtualización.
- VMM alojado en un Sistema Operativo
- Hypervisor de VMM solitario
- VMM híbrido
VMM ALOJADO EN UN SISTEMA OPERATIVO
En este caso el VMM se construye sobre un Sistema Operativo anfitrión. Un kernel del VMM corre en modo privilegiado paralelo al kernel del sistema operativo anfitrión. De acuerdo a una política de programación de procesos, el kernel del sistema operativo y el kernel del VMM comparten el uso del procesador y el VMM se apoya en la existencia de drivers del sistema operativo anfitrión para obtener acceso a los recursos.
Pero a pesar de la facilidad con que puede ser implementado, presenta la desventaja de ser tan confiable, seguro y disponible como el sistema operativo del cual depende. El VMM también es presa de las políticas de programación de procesos del sistema anfitrión, ya que competirá con las aplicaciones que corran sobre este, así como de las necesidades del sistema anfitrión. En caso de que el sistema anfitrión deba ser reiniciado, por ejemplo para aplicar un parche de seguridad, los sistemas invitados también deben ser sacados de línea.
HYPERVISOR DE VMM SOLITARIO
Otra alternativa para un VMM es construir un Hypervisor que no dependa de otro sistema operativo, por lo cual debería tener sus propios controladores de dispositivos y programador de procesos. Con esto, se puede lograr un control total de los recursos de hardware que permita garantizar calidad de servicio para los sistemas invitados.
Otra ventaja es que el camino que realiza una solicitud de I/O de un sistema invitado es mucho más corta, ya que se realiza a través del los controladores del propio Hypervisor y no a través de los del sistema anfitrión. Pero sin embargo, se pueden presentar problemas de implementación, ya que se deben reescribir controladores para cada dispositivo de hardware. También, las funciones avanzadas de un sistema operativo, como los sistemas de administración de energía basados en ACPI deben ser reimplementadas.
VMM HÍBRIDO
Un VMM híbrido busca lograr lo mejor de los 2 mundos; la confiabilidad y seguridad de un sistema de Hypervisor solitario así como las facilidades que ofrece un sistema operativo existente.
En este método, un micro hypervisor controla la CPU y la memoria, mientras que los recursos de I/O son controlados por los controladores de dispositivos de un sistema operativo de servicio que ha sido desprevilegiado. Este sistema operativo desprivilegiado no corre otras aplicaciones y solo trabaja para el VMM, de forma de mejorar la seguridad y confiabilidad del sistema.
Como se decía al principio, un sistema híbrido ofrece lo mejor del VMM alojado y del VMM solitario, sin embargo introduce nuevos retos a resolver. Entre ellos, se incluye un problema de desempeño ocasionado por la sobrecarga de las transiciones de privilegios entre los sistemas invitados y el sistema de servicio. Pero todas las ventajas de un sistema operativo desprivilegiado de servicio solo se logran cuando se agregan nuevos soportes de hardware para controlar el Acceso Directo a Memoria (DMA) a través del hypervisor.
TÉCNICAS DE VIRTUALIZACIÓN DE I/O [4]
Mientras que en la sección anterior se trataba el enfoque de la ubicación del VMM en una arquitectura de virtualización por software, en ésta se presentan diferentes técnicas utilizadas actualmente para virtualizar el acceso a dispositivos de entrada/salida (I/O).
Al momento de virtualizar un dispositivo de I/O debe tenerse en cuenta los tipos de operaciones que deben brindarse por parte del software de virtualización:
- Descubrimiento del dispositivo: un mecanismo para descubrir, consultar y configurar un dispositivo.
- Control del dispositivo: un mecanismo de software para comunicarse con el dispositivo e iniciar una operación de I/O.
- Transferencia de Datos: un mecanismo para que se pueda transferir datos desde y hasta la memoria del sistema.
- Interrupciones de I/O: un mecanismo de hardware para notificar al software de eventos y cambios de estado.
Cada uno de estos mecanismos difiere en cada una de las técnicas de virtualización que se muestran a continuación, con sus consecuentes ventajas y desventajas.
- Emulación
- Paravirtualización
- Asignación directa
EMULACIÓN
La emulación, también conocida como Virtualización Completa, refiere a la implementación de hardware real de forma completa en software. Su gran ventaja es que no requiere modificaciones al sistema invitado, ya que éste correrá como lo haría de forma nativa sobre el hardware para el que fue construido interactuando con el emulador del VMM, tal cual lo haría con hardware real. El sistema invitado no sabría que está corriendo en un ambiente virtualizado.En esta solución, el VMM debe exponer los dispositivos de hardware de manera que puedan ser descubiertos por el sistema invitado, por ejemplo en un espacio de configuración PCI, indicando los dispositivos y los espacios de memoria a través de los cuales se puede interactuar con ellos.
De la misma forma, el VMM debe proveer métodos para capturar lecturas y escrituras para que el sistema invitado crea que está interactuando con hardware real. E igual deben ser tratadas las interrupciones, emulando por software un PIC (Programmable Interrupt Controller).
Todo esto se logra implementando un “dispositivo modelo” en software por parte del VMM, el cual es totalmente independiente del hardware real. Incluso se cuenta con la ventaja que se podría portar el VMM a otro hardware sin afectar el sistema invitado.
PARAVIRTUALIZACIÓN
El hecho de modificar el software dentro del invitado, es una técnica conocida como Paravirtualización. La ventaja de paravirtualizar la I/O es mejorar el desempeño, pero tiene como desventaja que se deben modificar los drivers y otros componentes de software del sistema invitado, lo cual limita la solución si los sistemas operativos invitados son heredados.
El funcionamiento se basa en una nivel de abstracción más alto en el cual el sistema invitado se comunica con una API del VMM para realizar las operaciones de I/O en vez de acceder directamente a un dispositivo de hardware (fuera real o virtual). De esta forma se reduce la interacción entre el VMM y el sistema invitado, resultando en mejor desempeño.
En cuanto a interrupciones, en vez de usar un mecanismo emulado, la paravirtualización utiliza un mecanismo de eventos o callbacks. De esta forma se elimina la comunicación con un PIC y se realiza a través de un pequeño ISR (Interrupt Service Routine) el cual acepta las interrupciones y genera una tarea para cada una de ellas en el contexto correspondiente. De todas formas, este método también tiene la contra de que los mecanismos de manejo de interrupciones del kernel del sistema invitado deben ser modificados.
De la misma forma que la emulación, la paravirtualización soporta la migración de VM a cualquier plataforma que tenga las mismas APIs del VMM requerido por el sistema invitado.
Este enfoque fue tomado por al menos tres de los fabricantes de software de virtualización para lograr capacidad de escalamiento y mejores desempeños de I/O. Tanto Xen como VMware tienen en su oferta la capacidad de correr controladores de I/O paravirtualizados, mientras que Microsoft lo introdujo a partir de Virtual Server 2005 R2.
ASIGNACIÓN DIRECTA
En el caso de la asignación directa, el VMM permite que el sistema operativo invitado acceda directamente al hardware que necesite para las operaciones de I/O. Estos recursos de hardware deben ser propiedad de la VM en cuestión. Como en la emulación, el sistema invitado tiene la posibilidad de interactuar directamente con la interfaz estándar de un dispositivo. Sin embargo, con Asignación Directa, el sistema invitado puede reutilizar sus controladores ya existentes para comunicarse directamente con el dispositivo.
Con asignación directa, se mejora el desempeño con respecto a la emulación, aunque se tiene la contra de que solo se pueden asignar tantos recursos físicos como tenga el hardware, ya que no se comparten entre diferentes máquinas virtuales.
También se pierde en capacidad de migración, ya que para llevar una máquina virtual de una plataforma a otra se requiere que en ambas existan los mismos dispositivos. Más allá de eso, el hardware a ser asignado directamente debe soportar ese método de trabajo y las interrupciones puede que aun sea necesario manejarlas a través del VMM, donde se perdería en la práctica lo que en teoría se gana en desempeño.
VIRTUALIZACIÓN Y HARDWARE
Pero la virtualización no es un tema exclusivo de software, sino que también existen componentes de hardware que ayudan o permiten la virtualización. Las arquitecturas IBM System/370 o Motorola MC68020 ya lo permitían, pero en arquitectura x86 no fue hasta que Intel y AMD lanzaran las tecnologías Intel VT y AMD-V respectivamente, que se comenzó a tener en x86 primitivas nativas de la arquitectura para virtualización.
Deitel comenta que muchas de las operaciones de los sistemas operativos con el tiempo van pasando a la arquitectura, por ejemplo, en forma de microcódigo. Éste es un caso de ese tipo. En las arquitecturas no preparadas para virtualización, los sistemas de máquinas virtuales deben realizar operaciones muy complejas para administrar correctamente la asignación de recursos entre todos los sistemas operativos invitados.
Popek y Goldberg, en 1974, escribieron un artículo donde utilizan técnicas formales para determinar si una determinada arquitectura cumple con las condiciones suficientes para ser virtualizada. En principio debe definirse el concepto de Hypervisor o Virtual Machine Monitor (VMM) que es el componente de software que permite y administra la virtualización. Respecto del VMM, Popek y Goldberg definen que éste debe cumplir con las siguientes 3 propiedades:
- Equivalencia: un programa que funciona debajo del VMM debe exhibir un comportamiento esencialmente idéntico al demostrado al funcionar en una máquina directamente equivalente.
- Control de recursos: el VMM debe tener el control completo de los recursos virtualizados.
- Eficacia: una fracción estadísticamente dominante de las instrucciones de máquina se debe ejecutar sin la intervención del VMM.
Pero para definir si una arquitectura está preparada nativamente para virtualizarse, se detienen en separar el conjunto de instrucciones de la arquitectura (Instruction Set Architecture, ISA) en 3 grupos:
- Instrucciones Privilegiadas: son las que se atrapan si el procesador está en modo del usuario y no si está en modo de sistema.
- Instrucciones sensibles de control: son las que procuran cambiar la configuración de recursos del sistema.
- Instrucciones sensibles del comportamiento: son las que el comportamiento o el resultado depende de la configuración de los recursos (el contenido del registro de relocalización o el modo del procesador).
Con la definición de esos 3 conjuntos de instrucciones, establecen dos teoremas. En el primero indican que un VMM puede ser construido si el conjunto de instrucciones sensibles para esa computadora es un subconjunto de las instrucciones privilegiadas. En el segundo, establecen la virtualización recursiva, indicando que una máquina virtual es virtualizable recursivamente si puede correr una copia del mismo VMM que la creó.
Como ejemplos, se pueden citar las arquitecturas System/370, Motorola MC68000 y x86. En el caso de System/370, todas las instrucciones sensibles de control son privilegiadas, por lo cual cumple con las premisas de virtualización. Motorola MC68000 solo tiene una instrucción sensible no privilegiada. A partir del Motorola MC68010 dicha instrucción se hizo privilegiada. En el caso de x86 contiene 17 instrucciones sensibles no privilegiadas.
VIRTUALIZACIÓN CON SOPORTE EN LA ARQUITECTURA
Intel VT y AMD-V son la respuesta de Intel y AMD al desarrollo de la virtualización en la arquitectura x86. Ambos proponen soluciones de extensiones de la arquitectura x86 de sus procesadores de gama alta para que se acorte la distancia entre el sistema invitado y el hardware real. Aunque en x86, la virtualización ya existe a través de un componente de software, tener recursos a nivel de arquitectura que faciliten la virtualización es la forma de llegar a las tres propiedades definidas por Popek y Goldberg.
AMD
Zeichick (2007) en su artículo “Processor-Based Virtualization” [13][14] explica que la solución de AMD fue repensar la arquitectura x86 y agregar una nueva instrucción llamada VMRUN y un nuevo modo de procesador, el modo “Guest”, además de los que ya tiene dicha arquitectura: modo privilegiado y modo usuario. De esta forma, un VMM corriendo en un equipo con un procesador AMD-V, puede llamar la instrucción VMRUN para cambiar de modo “Host” a modo “Guest” y favorecer un acceso directo al hardware por parte del sistema operativo invitado.
Un procesador AMD que soporte la tecnología AMD-V, inicia y funciona como cualquier otro procesador x86 hasta el momento en que un VMM compatible ejecuta la instrucción VMRUN. A partir de ese momento el procesador se cambia a modo Host, obteniendo las nuevas capacidades de virtualización. De esta manera, se puede definir a nivel de procesador y no de software, las características de las máquinas virtuales, incluyendo cuanto procesador, recursos de I/O y memoria real tendrán asignada.
Una vez que las máquinas virtuales fueron definidas en una estructura de datos llamada VMCB (Virtual Machine Control Block, Bloque de Control de Máquina Virtual), el VMM cambia el sistema a modo Guest, pasando el control al sistema operativo invitado en la máquina virtual. Luego de ello, comienza la carga normal de ese sistema operativo virtualizado, el cual creerá que tiene y controla un conjunto de recursos únicos que en realidad son compartidos.
El procesador con soporte para AMD-V, monitoreará las actividades de cada sistema operativo invitado. Cuando uno de esos sistemas requiera ejecutar una instrucción privilegiada o requiera utilizar un recurso de hardware que tenga asignado por su VMCB, el procesador se cambiará a modo Host y el VMM evaluará el requerimiento del sistema operativo invitado. Allí decidirá qué hacer con él, si permitirlo y en tal caso como manejarlo. Eventualmente podría llegar a ejecutar una interrupción para informar de algo al sistema operativo invitado o hasta podría apagarlo si detectara un riesgo de seguridad, como podría ser que el invitado quisiera ejecutar una instrucción VMRUN por sí mismo.
Ese método es mucho más seguro y eficiente que el utilizado por software, como en Virtual PC o VMware Workstation. Cada vez que el sistema operativo invitado ejecute una instrucción privilegiada o se ejecute una interrupción, el procesador cambiará a modo Host y el VMM tomará control de la situación.
Una segunda instrucción nueva de los AMD-V, entre otras varias que agrega, es VMMCALL. Ésta permite a un sistema operativo invitado saber si está corriendo en un ambiente virtualizado y en caso necesario, pedir más recursos. Algo que solo se puede hacer en tal escenario. Un equipo físico no puede solicitar más que al operador o administrador que le agreguen más recursos cuando esté falto de memoria o el disco se esté quedando lleno, sin embargo, en un ambiente virtualizado, existen otros sistemas operativos invitados que no tienen porque estar utilizando todos los recursos asignados.
INTEL
En cuanto a Intel, maneja dos arquitecturas de procesadores, IA-32 (x86) e Itanium. Para cada una de ellas se desarrolló un enfoque diferente de arquitectura de virtualización. A continuación se tratará la solución VT-x, creada para IA-32.
VT-x agrega dos nuevos modos de operación del procesador, llamados “VMX root operation” y “VMX non-root operation”. VMX root, es un modo diseñado para ser usado por el VMM y su comportamiento es similar al de un procesador IA-32 sin la tecnología VT-x. VMX non-root es un entorno controlado por un VMM y que es usado para soportar máquinas virtuales. Ambas formas soportan los cuatro niveles de privilegio de la arquitectura IA-32, de forma que un sistema operativo invitado puede correr en el modo de privilegio para el que fue creado y el VMM mantiene la flexibilidad de niveles múltiples de privilegio.
La tecnología VT-x define dos nuevas transiciones para pasar del modo root al non-root y viceversa. Éstas son: “VM entry” y “VM exit”. También define una estructura de datos llamada VMCS (Virtual Machine Control Structure, Estructura de Control de Máquina Virtual) la cual se divide en una “guest-state area” y una “host-state area”. Cuando se ejecuta una transición “VM entry”, se carga el estado del procesador desde el área guest-state y cuando se sale, a través de una “VM exit” se guarda el estado del procesador en dicha área y se carga el estado del procesador desde el área “host-state”. El área “guest-state” se utiliza para guardar el estado del procesador virtual de una VM, como puede ser el contenido de los registros. Además, se guardan elementos del estado del procesador que no pueden ser accedidos por software, ya que el VMM no podría verlos. Entre ellos está el estado de interruptibilidad del procesador. De aquí, que los elementos de estado de la VM que puedan ser accedidos por software no serán guardados en dicha área. Estos datos se excluyen principalmente para mejorar el desempeño de ejecución de las instrucciones “VM entry” y “VM exit”.
El diseño de la implementación de la tecnología VT-x permite que el procesador pase de forma directa algunas interrupciones al sistema operativo invitado. De esta forma se ahorran entradas y salidas de la guest-area y se realiza menos carga de procesamiento por parte del VMM.
Al ser un diseño que mantiene los niveles de privilegio de uso del procesador, un sistema operativo invitado no puede saber si está corriendo en un entorno virtualizado.
CONCLUSIÓN
La virtualización puede haber sido una tecnología existente desde los comienzos de la informática moderna que ha sido relegada durante años mientras los precios del hardware eran baratos y las necesidades informáticas no estaban tan distribuidas como ahora.
Cuando se vio la necesidad de la consolidación de servidores para mantener las estructuras informáticas en tamaños administrables, se encontró que una posible solución ya había sido creada y allí renació la idea de la virtualización. Pero hay otros factores que ayudaron a llegar al estado actual: la necesidad de contar con sistemas preparados para una única tarea de uso esporádica, el desarrollo de los procesadores y su barrera de velocidad por llegar al límite físico de lo que se puede fabricar. Y sin duda que cada analista de negocios, cada administrador de redes, cada gerente de IT y cada desarrollador de sistemas de virtualización encontrarán sus razones particulares para aprovechar y desarrollar esta tecnología.
Aun se espera más avance sobre la implementación de estos sistemas. Las tecnologías de AMD e Intel para soportar virtualización desde la arquitectura están en etapas muy tempranas de distribución y solo disponibles en sus procesadores más nuevos de gama alta. Productos de software (VMM) para virtualización compiten en un mercado muy abierto y con una oferta muy amplia. Así como se dio la “guerra de los navegadores” a fines de los años 90 del siglo pasado y que ahora se repite, podría llegar a darse en algún momento una “guerra de virtualizadores” que estandarice la oferta, marque un rumbo tecnológico y el impacto se haga sentir desde los servidores de red en nuestros trabajos y universidades hasta el mismo escritorio de nuestras casa.
BIBLIOGRAFÍA
[1] DEITEL, H. M. 1993. Sistemas Operativos. 2da. ed. Wilmington: Addison Wesley.
[2] White Paper. Server Virtualization on Intel Architecture. [Folleto] INTEL. 2006.
[3] NEIGER, GIL, et al. Intel® Virtualization Technology: Hardware Support for Efficient Processor Virtualization. En: Intel Technology Journal [online] Volume 10, Issue 03. pp. 167-177, 10 ago. 2006. [citado 20 julio 2007]. Disponible en Internet : http://developer.intel.com/technology/itj/2006/v10i3/1-hardware/1-abstract.htm
[4] ABRAMSON, DARREN, et al. Intel® Virtualization Technology for Directed I/O. En: Intel Technology Journal [online] Volume 10, Issue 03. pp. 179-192, 10 ago. 2006. [citado 20 julio 2007]. Disponible en Internet : http://developer.intel.com/technology/itj/2006/v10i3/2-io/1-abstract.htm
[5] DONG, YAOZU, et al. Extending Xen with Intel® Virtualization Technology. En: Intel Technology Journal [online] Volume 10, Issue 03. pp. 193-203, 10 ago. 2006. [citado 20 julio 2007]. Disponible en Internet : http://developer.intel.com/technology/itj/2006/v10i3/3-xen/1-abstract.htm
[6] FABIAN, PATRICK, et al. Virtualization in the Enterprise. En: Intel Technology Journal [online] Volume 10, Issue 03. pp. 227-242, 10 ago. 2006. [citado 20 julio 2007]. Disponible en Internet : http://developer.intel.com/technology/itj/2006/v10i3/6-enterprise/1-abstract.htm
[7] VARIAN, MELINDA.VM and the VM Community: Past, Present, and Future. Disponible en Internet: http://www.princeton.edu/~melinda/25paper.pdf
[8] ADAMS, KEITH; AGESEN, OLE. A Comparison of Software and Hardware Techniques for x86 Virtualization. 2006. [online] [citado 20 junio 2007] Disponible en Internet: http://www.vmware.com/pdf/asplos235_adams.pdf
[9] CREASY, J. R. The Origin of the VM/370 Time-Sharing System. En: Journal of Research and Development. Volume 25, Number 5. pp. 483-490 (1981) [online] [citado 20 junio 2007] Disponible en Internet: http://domino.watson.ibm.com/tchjr/journalindex.nsf/0/d6b9939ef2f3540b85256bfa0067f4d6
[10] IBM. z/VM Overview. [online][citado 20 junio 2007] Disponible en Internet: http://www.vm.ibm.com/overview/
[11] HARDY, NORMAN. Short History of IBM’s Virtual Machines. 2006. [online] [citado 20 junio 2007] Disponible en Internet: http://cap-lore.com/Software/CP.html
[12] VMWARE. About us. [online] [citado 20 junio 2007] Disponible en Internet: http://www.vmware.com/company/home.html
[13] ZEICHICK, ALAN. Processor-Based Virtualization, AMD 64 Style, Part I. 2006. [online] [citado 20 junio 2007] Disponible en Internet: http://developer.amd.com/articles.jsp?id=14&num=1
[14] ZEICHICK, ALAN. Processor-Based Virtualization, AMD 64 Style, Part II. 2006. [online] [citado 20 junio 2007] Disponible en Internet: http://developer.amd.com/articles.jsp?id=14&num=1
[15] MICROSOFT. Windows Server Virtualization Beta to be Available with RTM of Windows Server "Longhorn". 2007. [online] [citado 20 junio 2007]. Disponible en Internet: http://www.microsoft.com/windowsserver2008/bulletins/wsvirtualization_bulletin.mspx
[16] SWSOFT. About SWsoft. 2007. [online] [citado 20 junio 2007]. Disponible en Internet: http://www.swsoft.com/en/company
