MONOGRAFIA: MAQUINAS VIRTUALES

Transcripción

1 MONOGRAFIA: MAQUINAS VIRTUALES Grupo nº: 8 Fecha: 28/11/2006 Integrantes: Franco Pelegrini (frapell@gmail.com) Matias Cordoba (cormatias@gmail.com) Rodrigo Carreras (rcarreras86@gmail.com)

2 Índice 1. Historia 2. Introducción de máquinas virtuales 3. Tipos de máquinas virtuales 4. VM Para emular hardware especifico. 5. VM Para correr distintos SO 6. VM Para Software 7. Formas en las que se integran las máquinas virtuales. 8. Virtualización 9. Máquina Virtual Java. 1. Proceso de ejecución 10. Máquina Virtual QEMU 1. Emulación completa de una computadora 2. Emulación de "modo de usuario" 3. Host CPU 4. Módulo de aceleración para Qemu 5. Ejemplos de funcionamiento de Qemu 6. Qemu monitor 7. Traducción Dinámica 8. Alocación de registro 9. Optimización de código condicional 10. Optimización de estado de CPU 11. Cache de traducción 12. Código automoficante e invalidación de código traducido 13. Soporte de Excepciones 14. Emulación de la MMU 15. Interrupciones del Hardware 16. Detalles específicos de la emulación de usuario 17. Señales de Linux 18. Autovirtualización

3 19. Ventajas de Qemu 20. Desventajas de Qemu 11. Máquina virtual VmWare 1. Funcionamiento 2. Hardware emulado 3. Detalles 4. Vmware ESX server 5. Vmware GSX server 6. Vmware Workstation 7. Ventajas 8. Desventajas 12. Máquina Virtual Xen 1. Administración de memoria 2. Administración de la CPU 3. Dispositivos de Entrada/Salida. 4. Llamadas al sistema y tiempo 5. Dispositivo de almacenamiento 6. Migración de Máquinas Virtuales 7. Como funciona Xen? 8. Pruebas de rendimiento 13. Comparativas entre máquinas virtuales 14. Malware 15. Conclusión 16. Bibliografía

4 HISTORIA La historia de las computadoras data de varias décadas atrás. Para ser preciso, su historia se divide en etapas que dan comienzo desde 1955 hasta la actualidad. La evolución de todos los elementos relacionados con las computadoras actuales no es lo que nos ocupa, sino que nos referiremos a la forma en que evolucionaron los sistemas capaces de correr maquinas virtuales (VM). La necesidad de la existencia de VM da comienzo por la necesidad de obtener un sistema operativo que fuese capaz de soportar múltiples usuarios corriendo sobre él (timesharing 1 ), es decir que fuese capaz de ejecutar los procesos que éstos necesitaban correr. Durante este período surgieron varios Sistemas operativos (SO) que trataron de solucionar esta necesidad. IBM desarrolló un SO llamado OS/360. En un comienzo no estaba capacitado para soportar time sharing, pero tras surgir esta necesidad se le incorporó esta función. A pesar de los intentos de IBM por dotar al 360 con ésta funcionalidad, lograron obtener un sistema que era muy pesado, e inconsistente. Para solucionarlo se propuso un nuevo sistema (en 1972 que aun esta presente en la actualidad) llamado VM/370 (1). Éste marcó un punto muy importante en la historia, ya que para poder proporcionar un sistema de tiempo compartido, se basó en una serie de conceptos que no se habían tenido en cuenta hasta la fecha. Éstos fueron: Multiprogramación: varios procesos corriendo en simultáneo. Un máquina extendida con interfaz más conveniente que el mero hardware. VM/370 es la esencia de éstas dos funciones. Éste simulaba varias máquinas compartidas y cada una de ellas brindaba a cada usuario una copia exacta del hardware de la máquina (cuando en realidad se contaba con un solo hardware y este se repartía entre todas las VM). Tenía un corazón, llamado monitor del sistema, que era el encargado de simular las mútiples maquinas. Uno de los inconvenientes de este SO es que solo corre en arquitecturas IBM/370, hecho que no significaba una gran limitación durante su surgimiento. Con el tiempo las VM han evolucionado mucho, siempre teniendo el mismo concepto, es decir un sistema que brinda una abstracción a otros entes (SO, procesos de usuarios, etc). En la actualidad nos encontramos con VM que son capaces de correr aplicaciones independientes hasta un conjunto de sistemas operativos, siendo esto un hecho que proporciona independencia en los distintos sistemas. INTRODUCCIÓN A LAS MAQUINAS VIRTUALES Inicialmente se utilizaba el término Hardware Virtual Machine, que surgía de un sistema (VM/370 por ejemplo) que emulaba múltiples máquinas con su hardware particular, siendo que en la realidad estaban corriendo sobre un sólo hardware que podía ser más limitado de lo que las VM ofrecían. Actualmente nos podemos referir como Virtual Machine ya que éstas han evolucionado de tal formal que no es preciso modificar el hardware para correrlas, sino que son capaces de trabajar en otras capas del sistema. Se hará una descripción de las capas sobre las que trabajan más adelante en este trabajo. La pregunta es: Qué es una máquina virtual y qué es lo que hacen?, para responder ésto, depende del enfoque que se le haya querido dar en el momento de su desarrollo. Sin embargo la tarea que tiene asignada es la de proporcionar una capa de abstracción a un entre (Proceso, programa, sistema operativo, etc) determinado, con el fin de que éste crea que está corriendo sobre un sistema que cuenta con ciertas características. Dicho de otro modo es crear un entorno virtual entre la plataforma de la computadora y el usuario final, permitiendo que éste ejecute un software determinado. Más adelante se puede consultar un apartado particular que habla de los distintos enfoques que poseen las VM. Aquí podemos establecer 3 grupos en los cuales englobar las VM: 1. VM que emulan hardware: como en el caso de la 370 de IBM. Máquinas que simulan una copia del 1 timesharing: esta referido a la multiprogramación, es decir la posibilidad de ejecutar múltiples procesos al mismo tiempo, o dar la sensación de que esto esta ocurriendo.

5 Hardware sobre el que están corriendo. 2. VM que permiten correr SO: dentro de éstas podemos mencionar aquellas que son capaces de soportar distintos sistemas operativos. 3. VM que permiten correr correr lenguajes de programación compilados. Es decir los programas se compilan para ejecutarse sobre una maquina determinada, que generalmente funciona en varios SO. De esta forma se evita tener que compilar el software cada uno de los SO. Las VM brindan beneficiós varios que dependen del tipo de máquina que se está ejecutando, dentro de éstos podemos mencionar: Permite aprovechar al máximo las capacidades del harware sobre el que corren. Ésto es posible ya que al tener varias máquinas ejecutandose sobre una misma los recursos se ven obligados a mantenerse en un uso casi constante. Un ejemplo de esto es un hardware especifico que brinda intel 2, que es capaz de correr VmWare (un tipo de VM), en donde se puede reducir 100 sevidores a un total de 10, logrando aprobechar al maximo las capacidades del hardware. Seguridad. Son capases de correr sobre un hardware determinado, pero abstraer totalmente al usuario de este, es decir que le brinda una interfaz para que este trabaje, pero no permite que dañe ni altere la parte física de la máquina. Por ello son un elemento interesante al momento de hacer distintas pruebas que pueden perjudicar el sistema determinado. Estabilidad. Correr sobre una VM una aplicación puede no ser mas estable que hacerlo sobre un SO. Pero a pesar de esto brinda estabilidad en el SO que corre la VM, ya que en caso de que el programa cause algun error, lo unico que se vera afectado sera la VM. Multiple Plataforma. Si estamos hablando de lengujes compilados, solo debemos compilar un programa para correr sobre una VM y esta se encargara de permitir que se ejecute en multiples SO. Un caso de esto es el de JAVA. Este lenguaje proporciona una máquina vitual que corre sobre LINUX, WINDOWS, MAC, etc. Luego un programa de java se ejecutara en todos ellos sin que halla necesidad de recompilarlo. Podemos estar ejecuntando dos o mas SO al mismo tiempo sobre una misma máquina Estas son algunas de las ventajas de utilizar VM, y otras surgiran de la combinación de las mismas. Pueden existir infinitas funciones que se pueden hacer con estas y dependeran de la capacidad de aprobecharla que tenga cada usuario en particular. TIPOS DE MAQUINAS VIRTUALES Como ya se mostro en lo anterior mencionado existen distintos tipos de máquinas virtuales. A pesar de esto todas comparten un mismo concepto que es la de brindar una abstracción al ente.. que los utiliza. A continuación se mostrara los distintos tipos de VM que existen a si como ejemplos puntuales de como funcionan estas. VM Para emular hardware especifico. Un ejemplo de esta es la VM/370 de IBM. Se basan en un harware especifico que posee memoria, procesador, espacio de almacenamiento, dispositivos de E/S etc. Sobre este hardware se corre la máquina virtual que se encarga de dividir este de modo que pueda brindar a los usuarios finales una copia exacta de este. Para ello existe un corazón del sistema que se encarga de simular esto. Sistema operativo X Sistema operativo X Sistema operativo X Máquina vitual Hardware La Cantidad de sistemas operativos que se pueden correr en la capa mas alta depende de la máquina 2 Puede verse esto en el articulo:

6 virtual que se este corriendo. En el caso de las VM/370 se podían ejecutar como máximo 370. Para que éstas puedan usarse es necesario que el hardware cumpla ciertos requerimientos, es decir que no puede correrse sobre cualquier arquitectura de computadora. Actualmente las VM son capaces de emular el hardware que el usuario solicite. Para esto hay que tener en cuenta que no debe superar con creces al Hardware físico ya que de lo contrario no se podrá satisfacer las necesidades. La capa sobre la que corren este tipo de VM es la segunda, siendo la primera el hardware físico. Un proyecto que esta en continuo desarrollo es VMware. Es interesante mencionarlo ya que proporciona una innovación grande en relación con VM/370. Esta radica en que permite ajustar a las necesidades del usuario el hardware que el usuario precisa, a la vez que puede correr sobre distintas arquitecturas de hardware. Más adelante se hará un apartado especial para VMware. Este tipo de VM se encarga simular la capa mas baja, es decir la del Hardware (de aquí que la tarea que tenga encargada es la de recrear varias copias del hardware original. VM Para correr distintos SO Antes de continuar debemos aclarar que las VM no tienen que pertenecer solo a uno de estos grupos, por citar un caso ya mencionado VMware es capaz de emular un tipo de hardware específico a la vez que permite correr distintos sistemas operativos. Con esto queremos mostrar los grupos de funcionalidades que poseen las VM de modo de poder describirlas. Actualmente existen muchos sistemas capaces de llevar a cabo esta funcionalidad. Dentro de ellos podemos mencionar VMware, QEMU, Xen, Botch, Virtual PC, etc. Entre ellos difieren en la forma en la que logran obtener el mismo objetivo. Algunas trabajan con el Sistema operativo host 3 y sobre el hardware (como VMware) otras trabajan sobre una capa superior a la del sistema operativo como es el caso de QEMU. Sin embargo todos buscan lograr correr un SO completo (que varía dependiendo de la VM que se esté corriendo). No hablaremos aquí del modo en que cada VM lleva a cabo su tarea, ésto se aclarará mas adelante en éste informe. Si bien cada uno posee una forma particular de llevar a cabo su tarea, una característica común que poseen es la de crear una nueva "capa en el sistema". Esta capa se ubicará entre el sistema operativo host (y el hardware de ser necesario) y los múltiples sistemas operativos que querramos correr. Por lo cual cuando corramos un SO X en la VM este creerá que se está ejecutando directamente sobre el Hardware 4. VM Para Software Este tipo de máquinas virtuales, al igual que las del apartado anterior, crean una capa entre el sistema operativo host y el programa que desea correr el usuario. Éstas envían instrucciones al SO Host y éste se encarga de hacer las llamadas necesarias al hardware (crea una capa de abstracción entre el software y el SO Host), por lo que la VM no trabaja directamente con éste. Un ejemplo de este tipo de VM es la Java Virtual Machine. La ventaja de éstas es que un programador desarrolla un software que sea capaz de ejecutarse en una VM específica y lo compila para ésta. Luego el programa funcionará en todos los SO que sea capaz de correr la VM. De ésta forma se ahorra mucho tiempo de desarrollo y se establece un estándar de programación en los distintos SO. La Capa que se encarga de recrear éste tipo de VM es la del SO, es decir el programa que corre sobre éste envía las llamadas al sistema 5 a la VM como si lo hiciera con el SO. Luego éste la interpreta y hace la llamada correspodiente. 3 Es el Sistema Operativo sobre el que corre la maquina virtual. Puede ser Windows, Linux, Mac, BSD, etc. Este dependerá de la VM que se este corriendo. 4 No tiene que creer que esta corriendo exactamente con las capacidades del hardware real, la Vm puede hacer que crea que es un hardware distinto, por ejemplo limitando la cantidad de memoria. 5 Llama al sistema o System call. Es un mecanismo por medio del cual un programa de usuario utiliza una serie de procedimientos del SO que hacen diversas tareas, por ejemplo manejo de memoria, E/S, etc.

7 FORMAS EN LAS QUE SE INTEGRAN LAS MAQUINAS VIRTUALES. Cada tipo de máquina virtual posee una forma diferente de funcionar, dependiendo en la capa en la que trabaje. Para llevar a cabo su tarea se vale de distintas técnicas que tiene sus ventajas y desventajas. Muchas de ellas sacrifican velocidad y rendimiento del hardware (ya que al abstraer capas conlleva a un menor tiempo de respuesta) y obtienen un menor compromiso con el hardware físico, mientras que otras prefieren todo lo contrario. Un término utilizado en el ámbito de la VM es la virtualización. Una Máquina virtual es también llamada Servidor de Virtualización. A continuación se hablará de los distintos medios que se valen las VM para poder hacer éstas tareas. VIRTUALIZACION Virtualización es la creación de una versión virtual (en contra de la versión real) de algo, como un sistema operativo, un servidor, un dispositivo de almacenamiento o recursos de la red. La virtualización del sistema operativo es el uso de software para permitir que un mismo sistema maneje varias imágenes de los sistemas operativos a la misma vez. La tecnología se inició en los mainframes hace décadas, permitiéndoles a los administradores la mejor utilización del poder de cómputo. Para ser concretos, consiste en montar un sistema operativo virtual, o los que nuestra máquina sea capaz de manejar, en base a un sistema operativo "anfitrión" o Host. De éste modo podemos cargar diversos sistemas, incluso totalmente diferentes, sobre un mismo hardware y de forma que estén aislados los unos de los otros y también que aprovechen el hardware disponible en el Host como su conexión de Red, sus puertos USB, sus unidades de almacenamiento, etc. Esta técnica es utilizada por muchas VM para poder llevar a cabo su objetivo (Xen, VmWare, QEMU, etc). La técnica de virtualización fue utilizada aproximadamente 4 décadas atrás en las grandes Mainframes que existían. Esta técnica se utilizaba para poder optimizar la utilización de los recursos. Actualmente ésta técnica es utilizada para el mismo motivo, así como también en otros ámbitos, como en la seguridad. Empresas como Intel o AMD se encuentran en el diseño de procesadores que sean capaz de soportar la virtualización. Esta tecnología amplía la capacidad de dichos procesadores con la capacidad de aislar la ejecución de los sistemas operativos virtuales cargados en el sistema. Este aislamiento de procesos favorece notablemente al rendimiento y a la estabilidad de los diferentes sistemas operativos cargados en el sistema anfitrión. Cada uno funciona como una partición dentro del procesador lo que favorece el funcionamiento de los SO aumentando la seguridad y el buen funcionamiento del mismo. Dentro de la virtualización se desprenden distintos tipos, que se especializan en un aspecto en particular, dentro de los que podemos mencionar: Emulación, También llamada virtualización completa con recompilación dinámica. Consiste en una simulación completa del hardware. Se puede correr un software de forma independiente como si estuviera ejecutándose con un procesador independiente. Es una técnica muy utilizada para brindar compatibilidad de software y/o hardware. Por ejemplo es utilizado para simular consolas de videojuegos que tienen un hardware que difiere totalmente con el de una computadora. Programas que utilizan esta técnica son muchos, un ejemplo que posee una explicación más amplia en éste informe es QEMU. Virtualización Nativa o Virtualización Completa. Ésta técnica consiste en simular un hardware específico. Las VM que se encargan de esto corren de manera independiente los distintos SO que corren sobre ésta. Existe un único procesador que es compartido entre todas las VM. Es decir, no se simula como en la Emulación la existencia de otro procesador diferente al que existe físicamente. Ejemplo de este sistema es Vmware o Xen (con soporte del microprocesador). Paravirtualización. Ésta técnica requiere de ayuda especial de hardware (microprocesador) o bien que el sistema operativo sobre el que se corra esté parchado para poder ejecutarse. La VM que utiliza esta técnica se ejecuta en una capa inferior a la del SO host, y desde aquí se encarga de realizar las sucesivas administraciones. Se hace un apartado especial para Xen (que utiliza esta técnica) en donde se amplía la información a cerca de ésta.

8 Cada técnica es una forma de virtualización de que cada tipo de VM utiliza para satisfacer sus propósitos. MAQUINA VIRTUAL JAVA Es una máquina virtual desarrollada por Sun Microsistem. Esta se encarga de interpretar y ejecutar un código binario de java. Este es generado por un compilador especifico para dicho fin. En un comienzo este era solo propiedad de la empresa antes mencionada, en la actualidad existen diversos compiladores que llevan a cabo esa función. Es por ello que se ha establecido un estándar de desarrollo de java. Existe un libro que especifica el estándar de la máquina virtual de java (JVM), este es denominado el Libro Azul. Una frase extraída de el dice: We intend that this specification should sufficiently document the Java Virtual Machine to make possible compatible clean room implementations. Sun provides tests which verify the proper operation of implementations of the Java Virtual Machine. Donde su traducción es: Pretendemos que esta especificación documente suficientemente la Máquina Virtual de Java para hacer posibles implementaciones compatibles de entornos de confianza. Sun ofrece mecanismos para verificar una correcta operación de las implementaciones de la Máquina Virtual de Java. Este tipo de máquina virtual es un claro ejemplo de un tipo de VM que es usada para correr programas. Para poder llevar a cabo esta tarea es preciso que se realicen una serie de pasos que se describirán a continuación. Es preciso llevar a cabo inicialmente un proceso de compilación. En este periodo se convierte el código fuente a código que pueda interpretar el compilador. En el caso de java se transforma en un bytcode. Los proyectos se separan en clases, en donde se encuentran los diversos procedimientos, funciones, etc. Estas pueden ser empaquetadas en un solo objeto con exención.jar, el cual es usado directamente por el compilador. Para poder ejecutar las instrucciones Java, inicialmente llevaba a cabo un método llamado Interpretación. Este consiste en leer instrucción por instrucción e ir emulándolas según el sistema operativo sobre el cual se estaba corriendo. En la actualidad se lleva a cabo un proceso llamado compilación JIT (Just In Time, o al momento ). Esta se aplica sobre el bytecode generado tras la primera compilación al inicio de la aplicación, y da como resultado una ejecución mucho más eficiente, aunque con la penalización en tiempo que conlleva esta segunda compilación. Proceso de Ejecución Antes de ejecutar un bytcode de java, la JVM lleva a cabo un proceso de verificación. Esto se hace antes de ejecutar cualquier instrucción contenido en el objeto.jar. Aquí se verifican cosas como que no se accedan a direcciones de memoria incorrectas, ahorrando trabajos al SO por ejemplo. JVM puede emplear instrucciones que ejecuten comandos diversos. Este tipo de comandos aseguran de que existan compatibilidad entre todos los SO. Llevar a cabo esta tarea es uno de los factores mas difíciles a la hora de desarrollar la JVM. El grupo de instrucciones que pueden usarse son: Carga y almacenamiento Aritméticas Conversión de tipos Creación de objetos y su manipulación Gestión de la pila (push / pop, meter / sacar) Saltos Llamada a métodos y salida de estos Generación de excepciones Uno de los factores para los cuales fue desarrollado java fue para poder ejecutar comandos o llevar a cabo tareas de forma remota. Es decir que un usuario que se encuentra en su navegador web

9 puede ejecutar código proveniente de un servidor remoto. Este Código puede ser malicioso. Por ellos la JVM proporciona un entorno seguro que no deja que se dañe el SO. En casos de tener que ejecutar acciones que lo comprometan, se avisa al usuario quien puede permitir su ejecución. Un aspecto interesante de la JVM es su gran potencial. No es preciso que el bytcode que ejecute halla sido escrito en JAVA (el lenguaje), si no que puede ser también en C, ADA o COBOL. Solo es preciso tener un compilador que interprete el lenguaje y lo convierta en un bytecode de JVM. Esto proporciona una libertad de desarrollo para los distintos programadores. MAQUINA VIRTUAL QEMU Qemu es un programa libre que proporciona una veloz emulación de procesador, permitiendo al usuario simular una computadora completa dentro de otra, fue escrito por Fabrice Bellard, un programador frances que además de ser el creador de Qemu, es el fundador de FFmpeg, un pequeño compilador de C "Tiny C" entre otros, y además, el descubridor de la formula más rápida que se conoce para calcular cifras del número PI. Qemu es una máquina virtual capaz de emular múltiples arquitecturas, y la alta velocidad de emulación la logra gracias a una técnica llamada "Traducción dinámica", la cual es una combinación de otras dos, la "compilacion a bytecode" y la "compilación dinámica", donde básicamente el programa se compila a bytecode primero, que es un lenguaje intermedio antes del lenguaje de máquina, pudiendo de esta manera ser portado a cualquier arquitectura. Es aquí cuando una máquina virtual lo interpreta y lo ejecuta. Qemu puede ser instalado bajo Linux, Windows, FreeBSD y MacOSX, pero la versión para Windows todavía se encuentra en estado "Alfa" de desarrollo. Posee dos modos de operación: 1) Emulación completa de una computadora 2) Emulación de "modo de usuario" Emulación completa de una computadora: En este modo, Qemu emula una computadora completa incluyendo Procesador y periféricos. Las arquitecturas que Qemu es capaz de emular en su totalidad son: X86 X86_64 ARM SPARC PowerPC MIPS Las Arquitecturas que se encuentran en desarrollo de poder ser emuladas son: SPARC64 PowerPC64 m68k SH 4 Así mismo, los periféricos que Qemu emula son: i440fx host PCI bridge and PIIX3 PCI to ISA bridge Tarjeta de video Cirrus CLGD 5446 PCI VGA o tarjeta standard VGA con extensiones VESA Bochs

10 (nivel de hardware, incluyendo todos los modos no standard) Teclado y Mouse PS/2 2 interfaces PCI IDE con soporte de disco rígido y CD ROM Disquetera Adaptador de red NE2000 PCI Puerto Serial Tarjeta de sonido Creative SoundBlaster 16 Tarjeta de sonido ENSONIQ AudioPCI ES1370 Chip compatible con Yamaha YM3812 Adlib(OPL2) Controladora PCI para USB UHCI y HUB USB virtual Qemu posee también la capacidad de simular un sistema que posea hasta 255 procesadores Emulación de "modo de usuario": En este modo, Qemu permite ejecutar procesos de Linux compilados para una determinada arquitectura, en otra. Esto se realiza por motivos de diferencias entre arquitecturas de 32 bits o de 64 y por el "endianness" Las arquitecturas que Qemu es capaz de emular en este modo son: X86 ARM SPARC PowerPC MIPS Las arquitecturas que están en desarrollo para ser emuladas son: SPARC64 m68k SH 4 Las arquitecturas no soportadas son: X86_64 PowerPC64 HOST CPU's Las Arquitecturas donde corre Qemu son: X86 X86_64 PowerPC Las arquitecturas donde Qemu se encuentra en un estado de "testing" son: Alpha Sparc32 ARM S390

11 Las arquitecturas donde Qemu se encuentra en estado de "desarrollo" son: Sparc64 ia64 m68k Módulo de aceleración para Qemu Existe un módulo para el kernel de Linux que eleva la velocidad de emulación de i386 en máquinas con i386, en donde la velocidad de ejecución es prácticamente nativa. El módulo es llamado Kqemu, escrito por el mismo autor de Qemu, solo que el otro es libre pero no posee el código abierto. La alta velocidad de emulación la logra gracias a que ejecuta el código en "modo usuario" y en "modo virtual 8086" directamente en el procesador donde esta corriendo Qemu, y usando la emulación de procesador y periféricos solo para el código en "modo kernel" y en "modo real". Además Kqemu posee un modo de "Virtualización completa", en la cual no solo se ejecuta el código de "modo usuario" en la CPU host, sino que se ejecuta también el código de "modo kernel", aumentando aún más la velocidad. Existe otro modulo de aceleración llamado QVM86, pero al parecer está abandonado. Ejemplos de funcionamiento de Qemu: qemu img create f qcow imagen.img 3G Esto crea una imagen en el disco llamada "image.img" con qcow como tipo de imagen, la cual permite ir agrandando el archivo a medida que se va escribiendo en él hasta un tamaño máximo de 3 GB qemu hda imagen.img cdrom /dev/hdc boot d m 128 soundhw sb16 localtime Esto inicia la maquina virtual, especificando que la unidad hda sera la imagen creada anteriormente, el cdrom es el dispositivo /dev/hdc, que inicie desde el cdrom, con una memoria ram de 128 MB se emula una placa de sonido "Sound Blaster 16" y se especifica la hora local Qemu monitor: La máquina virtual Qemu posee un monitor que funciona en tiempo real. Este monitor es accedido con la combinación de teclas "Ctrl+Alt+2" y se puede hacer todo tipo de consultas, desde la versión actual de Qemu, hasta saber los valores de los registros del micro emulado Traducción Dinámica: Qemu es un traductor dinámico. Cuando encuentra un pedazo de código, lo convierte al set de instrucciones de la máquina host. Por lo general, los traductores dinámicos son muy complicados, y grandes consumidores de CPU. Qemu utiliza algunos trucos que lo hacen portátil relativamente fácil y simple, al mismo tiempo que logra buena performance La idea es dividir todas las instrucciones x86 en instrucciones más simples. Cada instrucción está implementada por un trozo de código en C. Luego una utilidad de compilación toma el correspondiente archivo objeto para realizar un generador dinámico de código, quien concatena las instrucciones simples, para armar una función. Una idea clave para obtener una performance óptima es que se puedan pasar parámetros constantes a las operaciones simples. Para ese propósito, realocaciones de archivos ELF son generados con gcc para cada parámetro constante. Luego la utilidad de compilación puede ubicar las realocaciones y generar el código C apropiado cuando se esté construyendo el código dinámico. De ésta manera, Qemu no es más complicado de portar que un linkeador dinámico. Para aún mayor velocidad, las variables de registros estáticos de gcc son usadas para mantener el estado

12 de la CPU virtual. Alocación de registro Desde que Qemu usa simples instrucciones fijas, no puede hacerse una alocación de registros eficiente. De todas formas, dado que los CPU's RISC poseen muchos registros, la mayor parte del estado de la CPU virtual puede ser puesto en registros sin hacer una complicada alocación. Optimización de código condicional Un punto crítico para obtener buena performance es una buena emulación de los códigos condicionales de la CPU (registros EFLAGS en x86). Qemu utiliza una evaluación de código condicional perezosa: En lugar de computar el código condicional luego de cada instrucción x86, solamente guarda un operando (llamado CC_SRC), el resultado (llamado CC_DST) y el tipo de operación (llamado CC_OP). Cuando se puede demostrar que los códigos condicionales no van a necesitarse en las próximas instrucciones, estas no se computan. Optimización de estado de CPU La CPU x86 posee muchos estados internos, los cuales cambian la forma en la que se evalúan las instrucciones. Para obtener una buena velocidad, la fase de traducción considera que alguna información de los estados del CPU x86 virtual no pueden cambiar en él. Por ejemplo, si los segmentos SS, DS y ES poseen una base cero, entonces el traductor ni siquiera genera una suma para la base del segmento. Cache de traducción Una caché de 16 MB almacena las traducciones usadas más recientemente. Una unidad de traducción contiene solo un único bloque básico (un bloque de instrucciones x86 terminadas por un salto o por un cambio de estado en la CPU virtual, que el traductor no puede deducir estáticamente) Código automodicante e invalidación de código traducido el Código automodificante es un desafío especial en la emulación de x86, dado a que, cuando el código es modificado, la aplicación no envía ninguna señal a la instrucción de invalidación de caché. Cuando el código traducido es generado para un bloque básico, la página correspondiente del host, está protegida contra escritura (con la llamada al sistema mprotect()). Entonces, si un proceso de escritura es realizado a la página, Linux envía un fallo de segmentación. Qemu entonces, invalida todo el código traducido en la página y permite la escritura a la página. La invalidación correcta del código traducido es realizada eficientemente manteniendo una lista ligada de todos los bloques traducidos contenidos en una pagina dada. Otras listas ligadas son también mantenidas para deshacer la encadenación de bloques. Qemu también invalida páginas de código traducido cuando detecta que se modifican los mapeos de memoria con mmap() o munmap(). Cuando se utiliza un MMU por software, la invalidación de código es más eficiente: si una si una página de código dada es invalidada demasiado seguido por permisos de escritura, entonces se construye un bitmap que representa todo el código dentro de la página. Todo almacenamiento dentro de esa página chequea el bitmap para ver si el código realmente necesita ser invalidado. Evita invalidar el código cuando solamente se han modificado datos en la página. Soporte de Excepciones Cuando se encuentran excepciones tales como divisiones por cero, se utiliza longjmp(). los manipuladores de las señales SIGSEGV (fallo de segmentación) y SIGBUS (Error de BUS) del host son

13 usados para obtener accesos a memoria inválidos. El estado exacto de la CPU puede ser devuelto debido a que todos los registros de x86 son almacenados en registros fijos del host. El program counter simulado es encontrado volviendo a traducir el bloque básico correspondiente y buscando donde el program counter del host estaba en el momento de la excepción. El CPU virtual no puede devolver los registros EFLAGS exactos porque en algunos casos no son computados dado a las optimizaciones del código condicional. No es una gran preocupación porque el código emulado puede ser recomenzado en cualquier caso. Emulación de la MMU Para la emulación de la MMU, Qemu utiliza la llamada al sistema mmap(). Funciona mientras el Sistema Operativo emulado no use una zona reservada por el sistema operativo host (como la zona sobre 0xc en un Linux x86). Para poder tener la capacidad de ejecutar cualquier sistema operativo, Qemu también soporta MMU por software. En ese modo, la traducción de la MMU de direcciones virtuales a físicas son hechas en cada acceso a memoria. Qemu usa un cache de traducciones de memoria para acelerar la traducción. Interrupciones del Hardware De manera de ser más rápido, Qemu no controla cada bloque básico por si alguna interrupción de hardware se encuentra pendiente, sino que el usuario debe llamar, asíncronamente, una función específica, para anunciar que hay una interrupción pendiente. Ésta función resetea el encadenamiento del bloque básico que está actualmente en ejecución.. Se asegura que la ejecución va a retornar pronto en el bucle principal del emulador de la CPU. Luego el bucle principal puede comprobar si la interrupción está pendiente y manejarla. Detalles específicos de la emulación de usuario Traducciones de las llamadas al sistema de Linux Qemu incluye un traductor genérico de llamadas al sistema para Linux. Eso significa que los parámetros de las llamadas al sistema pueden ser convertidos para arreglar los temas de "endianness" y de 32/64 bits. Las llamadas al sistema para manejar entrada salida son convertidas por medio de un sistema genérico descriptivo de tipo. Qemu soporta CPU's host que poseen páginas más grandes que 4KB. Almacena todos los mapeos que hacen los procesos y trata de emular la llamada al sistema mmap() en los casos donde la llamada mmap() en el host fallaría por una mala alineación de página. Señales de Linux Las señales normales y de tiempo real son encoladas junto con su información (siginfo_t) como se hace en el kernel de Linux. Luego un pedido de interrupción es realizado a la CPU virtual. Cuando es interrumpida, una señal encolada es manejada generando un marco de pila en la CPU virtual como el kernel de Linux hace. La llamada al sistema sigreturn() es emulada para retornar del manejador de señales virtuales. Algunas señales (como SIGALRM) vienen directamente del host. Otras señales son sintetizadas desde las excepciones de la CPU virtual como SIGFPE cuando se realiza una división por cero. La máscara de la señal bloqueada es manejada por el kernel del host Linux de manera que la mayoría de las señales de llamadas a sistema puedan ser redirigidas directamente al kernel del host Linux. Solo sigaction() y sigreturn() necesitan ser completamente emuladas. Hilos y llamada al sistema clone()

14 la llamada al sistema de Linux, clone(), es usada por lo general, para crear hilos. Qemu usa la llamada al sistema clone() del host de manera tal que se creen hilos en el host por cada uno emulado. Una CPU virtual es creada por cada hilo. Las operaciones atómicas de la CPU x86 virtual son emuladas con bloqueos globales de manera que su semántica es preservada. Actualmente hay algunos problemas de bloqueo en Qemu. Particularmente, el vaciado traducido de cacho no esta protegido contra reentrada Autovirtualización Qemu fue concebido de manera que el pueda emularse a si mismo. A pesar de no ser muy útil, es un test importante para demostrar el poder del emulador. Conseguir autovirtualización no es fácil dado que puede haber muchos conflictos de espacios de direccionamiento. Qemu resuelve este problema siendo un objeto compartido ELF ejecutable como el intérprete ELF "ld linux.so". De esa manera puede ser realocado en el momento de carga Ventajas de Qemu Capacidad de emular Arquitecturas x86, AMD64, MIPS, SPARC, ARM, SH 4 y Power PC Alta velocidad Ciertas aplicaciones se ejecutan a una velocidad muy cercana a la nativa Implementa formato de imagen de disco Copy On Write, lo que permite declarar una imagen del tamaño que sea, pero que solo va a ser del tamaño de lo que realmente se use Implementa el uso de imágenes. Se puede mantener una imagen del sistema emulado para recuperarlo si hubo algún problema soporta la ejecución de binarios de Linux para otras arquitecturas. Puede guardar y recuperar el estado de una máquina Emulación de tarjetas de Red virtuales Soporte para SMP (capaz de emular un sistema con hasta 255 CPU's) El sistema operativo emulado no tiene que ser modificado ni "parcheado" Mayor velocidad cuando se utiliza Kqemu Las herramientas de linea de comandos permiten un control total de Qemu sin necesidad de tener que ejecutar X11 Control remoto de la máquina emulada vía servidor VND integrado Dado que no requiere ejecución en "modo kernel" es muy seguro de utilizar Desventajas de Qemu Soporte incompleto para Microsoft Windows y otro sistema operativo como Host Soporte incompleto para arquitecturas poco usadas No posee soporte de SSE ni MMX todavía No posee llamadas al sistema para IPC Solamente posee soporte para las librerías gráficas SDL y Cocoa a pesar que existe un parche para GGI

15 MAQUINA VIRTUAL VMWARE Stanford ha sido la cuna de empresas técnicas y científicas tan importantes como Hewlett Packard, Cisco System, Yahoo, Google y VMware entre otras. VMware es un sistema de virtualización por software. Un sistema virtual por software es un programa que simula un sistema físico con características de hardware determinadas. Cuando se ejecuta el programa, proporciona un ambiente de ejecución similar a todos los efectos a un ordenador físico. VMware emula completamente una PC con una plataforma hardware determinada. El hardware emulado no tiene nada que ver con el equipo que hace de anfitrión, ya que el sistema invitado solo ve los componentes virtuales. VMware funciona en WIndows y Linux y proximamente en MAC O2. La empresa VMware brinda a sus usuario infinidad de productos para optimizar la virtualizacion de hardware o la simulación de sistemas operativos por software. Debido a la finalidad de esta monografía solo mostraremos los productos VMware workstation, VMware ESX server y GSX server Funcionamiento En caso de Workstation y GSX server el funcionamiento es el siguiente: Aplicación >SO >Hardware >VMware >SO Host >Hardware Este diagrama indica de derecha a izquierda las capas en las que se implanta VMware. En la primera encontraremos al hardware subyacente. En la segunda es donde se diferencian Workstation y GSX server de ESX server. Ya que en esta se necesita un sistema operativo base en donde ejecutar la máquina virtual (Esto afecta el rendimiento y desempeño de las máquinas virtuales). En la tercera encontramos a la máquina virtual propiamente dicha la que emula un hardware completamente virtual, que se encuentra en la cuarta capa. Siguiendo el diagrama encontramos el sistema operativo virtual que puede ser mas de uno. Luego se encuentran las aplicaciones que están virtualmente ejecutándose sobre el sistema operativo antes mencionado. A diferencia de la versión ESX server que funciona más o menos de la siguiente manera. Aplicación > OS > Hardware > VMware > hardware físico. En este caso encontramos la maquina virtual en la segunda capa, desde aquí se emula el hardware, y luego en la siguiente capa se aloja el sistema operativo virtual. Esta forma de ubicar la maquina virtual en la segunda capa implica que dicho software haga las funciones de un sistema operativo. Lo que optimiza considerablemente la virtualización. Esta maquina virtual cuenta con estrategias de paginación y segmentación para hacer un mejor uso de los recursos de memoria. VM1 VM2 VM3 VMWare > virtualización > Hardware emulado Hardware físico

16 Hardware emulado Procesador Intel Pentium o posterior AMD Athlon o posterior (Dependiendo de la CPU original) Soporte experimental para las procesadores AMD64 y IA 32e RAM Hasta 3.6 GBytes dependiendo de la memoria física Unidades IDE Hasta 4 unidades IDE Discos físicos y virtuales (máx. 128 GBytes) Unidades CD/DVD ROM Unidades SCSI Hasta 7 Unidades Discos físicos y virtuales (máx. 256 GBytes) Soporte de SCSI genérico Soporte para escáneres, CD/DVD ROM, unidades de cinta, etc. Controlador de entrada salida LSI LOGIC LSI53C1030 Ultra320 Anfitrión compatible con el adaptador de bus Mylex (BusLogic) BT958 (solamente sobre Windows XP con controladores de dispositivo adicionales) Medios extraíbles Unidades CD ROM/CD R/CD RW (físicas o imágenes ISO) Unidades DVD ROM Un máximo de 2 unidades de 1.44 Mbytes (físicas o como imágenes) Hardware gráfico VGA y SVGA con BIOS VESA Puertos Hasta un máximo de 4 puertos serie (COM) Hasta 2 puertos paralelos bidireccionales (LPT) Dos controladores USB 1.1 UHCI Teclado compatible Ratón PS/2 Dispositivos de red Un máximo de tres adaptadores de red virtuales (Ethernet) Tarjeta de sonido compatible con AMD Pcnet PCI II Compatible con Sound Blaster Audio PCI (sin soporte para MIDI ni para joystick) BIOS Soporte para la versión 6 VESA BIOS de PhoenixBIOS 4.0 con DMI v2.2/ SMBIOS Detalles Para que la emulación pueda ejecutar cualquier aplicación con una velocidad aceptable, es necesario que hardware sea bastante rápido. VMware recomienda un Pentium II AMD equivalente, 256 MBytes de RAM,

17 un adaptador gráfico de 16 bit y por lo menos 20 Mbytes de espacio libre en el disco duro para el software VMware. Por supuesto que habrá que añadir espacio en disco, para que esté disponible al sistema operativo invitado, y una tarjeta de red, suponiendo que el hardware virtual necesite acceder a la red. Vmware ESX server Es un producto para servidores. Constituye una capa de visualización de recursos montada directamente sobre el hardware, sin la necesidad de un sistema operativo base. Ya que ESX server es un sistema operativo en si. La función principal es la de virtualizar y gestionar los recursos entre las múltiples máquinas virtuales montadas sobre la capa Vmware. Arquitectura: Diseñada para el funcionamiento en producción de múltiples maquinas virtuales de forma independientes. Virtualización: Proporciona a cada máquina virtual una máquina física idealizada, totalmente aislada de otras máquinas virtuales. Gestión de recursos: reaprovecha recursos de una máquina virtual a otra mediante la multiprogramación. Características: Particionanado en máquinas virtuales, encapsulado, aislamiento de fallos y gestión dinámica de recursos. Vmware GSX server Es un software de virtualización en entornos comerciales críticos. Simplifica las estructuras informáticas mediante la partición y aislamiento de servidores en máquinas virtuales seguras y transportables. VMware GSX Server permite que estos servidores de máquinas virtuales se puedan administrar de forma remota y estandarizar sobre una plataforma segura y uniforme. Transforma los ordenadores físicos en un conjunto de máquinas virtuales. Los sistemas operativos y las aplicaciones se aislan en distintas máquinas virtuales. Los recursos del sistema se utilizan en cualquier máquina virtual, dependiendo de las necesidades que se tengan, de tal forma que se consiga una gestión de capacidad y un control sobre las infraestructuras tecnológicas (hardware).se puede utilizar para implantar la conciliación entre servidores o para mejorar el soporte técnico de software. Con VMware GSX Server hace que la alta disponibilidad sea económica y escalable, protegiendo las aplicaciones críticas y los datos en un máximo de 64 máquinas virtuales aisladas y seguras sobre una única plataforma de hardware. Vmware Workstation Es un potente sofware para visualización de Escritorios (desktop). Ejecuta múltiples sistemas operativos como, Microsoft Windows, Linux y Novell NetWare, de forma simultánea en máquinas virtuales. VMware Workstation proporciona más opciones, mayor flexibilidad y una funcionalidad más potente que cualquier otro software de virtualización que haya en el mercado. Desde su lanzamiento en 1999, VMware Workstation ha revolucionado la forma en que se desarrollan tanto el software como las infraestructuras tecnológicas y se ha convertido en un estándar de facto para los profesionales de las tecnologías y los desarrolladores. Lo podemos utilizar para desarrollo, prueba e instalación de software. Se pueden crear aplicaciones críticas basadas en Linux o Microsoft y desarrollar y realizar pruebas sobre aplicaciones múltiples en diferentes sistemas operativos simultáneamente y, además, archivar entornos de pruebas y restablecerlos rápidamente. Asegurar ce de la compatibilidad de las aplicaciones y la migración de sistemas operativos. Se puede dar soporte a aplicaciones existentes al mismo tiempo que se realiza la migración a un sistema operativo nuevo

18 de una forma segura, a la vez que se pueden realizar pruebas sobre este nuevo sistema operativo antes de la instalación. Permite experimentar con las nuevas aplicaciones o herramientas y, además, distribuir e instalar software para demos y aplicaciones complejas en cualquier PC. Mejorar el soporte técnico de software. Con VMware Workstation se pueden resolver problemas rápidamente y proporcionar un servicio al cliente de calidad. A diferencia de los emuladores de API(del inglés Application Programming Interfase Interfaz de Programación de Aplicaciones) como WINE, VMware workstation emula un ordenador completo como un programa de software. El denominado sistema operativo invitado funciona dentro de la emulación VMware sin que pueda distinguir este entorno de la PC de verdad. Ventajas Se pueden ejecutar múltiples sistemas operativos al mismo tiempo en una misma máquina física. Total utilización de los recursos de cada servidor. Aislamiento de fallos y alta seguridad a nivel de hardware. Rendimiento controlado de los recursos de CPU, RAM, Disco, y network. Todo el conjunto bajo VM se encapsula: Memoria, disco, imágenes, dispositivo E/S. El conjunto VM se puede salvar a un fichero ( Check pointing, Suspend / Resume ). Se pueden transferir los VMs como ficheros, a esa misma velocidad. Flexibilidad y facilidad en los cambios. Pruebas en entornos idénticos a los de producción sin ningún problema de ejecución. Rápida recuperación y disponibilidad. Aumento de la Seguridad. Soporta nuevas y viejas aplicaciones, Sistemas Operativos y herramientas de gestión. Soporte para sistemas operativos de 64 bits. Soporte para las últimas distribuciones Linux, Windows, Solaris, BSD. Mejora capacidades wireles en distribuciones Linux. Desventajas Las máquinas solo disponen de driver estándar. No soporta aceleración gráfica. Algunos productos no soportan la virtualización El software de virtualización no esta certificado para todos los servidores Rendimiento en acceso a disco Gasta memoria RAM física, no se usa swap.

19 MAQUINA VIRTUAL XEN Xen es una Máquina Virtual desarrollada por la universidad de Cambridge en EEUU que corre sobre arquitecturas x86. Se encuentra bajo la licencia de GNU General Public Licence. Fue el resultada de XXX años de trabajo. El objetivo del equipo era desarrollar una VM que fuera capaz de correr múltiples Sistemas Operativos teniendo el menor desperdicio de recursos posibles, es decir que se pudiera lograr un desarrollo similar al de un SO corriendo de forma nativa. Dicho objetivo fue conseguido, llegándose a lograr perdidas de rendimiento verdaderamente bajas, siendo incluso, el desempeño de Xen, superior en otros ámbitos. Para poder llevar a cabo esto, el equipo de desarrollo, utilizó una técnica llamada Paravitualización. Esta Se describirá mas adelante. Pero lo que es importante tener presente, es que, para que Xen pueda funcionar precisa que el SO host posea un port para este, o bien este corriendo bajo un microprocesador que soporte la técnica mencionada (Linea Pacífica en caso de AMD y Vanderbool en INTEL). Los sistemas operativos que tienen ports desarrollados son Linux, Mac OS, BSD y Windows XP. En el ultimo por cuestiones legales no es posible lanzar el port al público 6. Xen es capaz de correr 100 máquinas al mismo tiempo (siempre y cuando el hardware sobre el que se ejecute soporte esto), brindando una independencia de entre estas muy efectiva. De esta forma cada sistema operativo que corre sobre una VM diferente no se percata sobre la existencia de los otros SO. Lograr una ejecución casi nativa es una tarea que requiere trabajar con mucho cuidado al momento de implementar diferentes aspectos como son: 1. Administración de memoria 2. Administración de la CPU 3. Administración de los dispositivos de E/S (discos duros, grabadoras/lectoras, Interrupciones, etc.) Para ver de que forma logra esto Xen, analizaremos de forma independiente los apartados recién mencionados. Administración de memoria. Este es un aspecto muy importante ya que es uno de los puntos que marcarán lo óptimo o no de la ejecución de las VM. Esto se debe a que si no se administra bien la memoria, el SO se vera obligado a realizar muchos intercambios con el disco duro. La administración es dejada al sistema operativo host, este se encarga de resolver los pedidos de alocación y liberación de memoria. Para poder mantener la independencias sobre las diversas VM que estén corriendo, Xen debe realizar alguna modificaciones en dicha administración. Lo primero que hace es reservar un espacio de 64 MB al tope de la memoria. Esta memoria es dedicada al trabajo de Xen, y solo puede ser accedida por este. Esto se debe a la necesidad de contar en todo momento con un espacio para almacenar sus datos (que sea rápido 7 ). El SO host se encarga de colocar los permisos necesarios para que solo Xen pueda utilizarla. Otro aspecto en el que se involucra Xen es en los permisos de la memoria. Los SO modernos administran la memoria a través de segmentos, estos tiene diversos permisos que determinan que proceso puede acceder a estos. Por cuestiones de eficiencia un segmento puede ser compartido con con varios procesos (ya que 6 Microsoft asume que no pueden garantizar el correcto funcionamiento de la VM de Xen al tener que parchar su Kernel (el de Windows), por este motivo recomiendan la utilización de Virtual PC, una Máquina virtual adquirida por estos. 7 por esto es que se quiere evitar reservar memoria en el disco duro, ya que este representa una amenaza al tiempo de respuesta, lo que deriva en un tiempo de respuesta menor.

20 es mas eficiente tener una copia de los datos que varias de este). Para evitar problemas con accesos indebidos de segmentos, Xen revisa los permisos con los que se administran los recursos. Debe tener especial cuidado cuando se actualizan las tablas de memoria, para que no quede inconsistente. Esto se debe a que el SO host en conjunto con las actualizaciones que lleva a cabo Xen pueden afectar la integridad de las páginas. Un ultimo elemento que tiene en cuenta Xen, es que todos los segmentos de memoria que sean resultado de las allocaciones de las VM que corren sobre este, deben poder ser accedidos por el. Xen da la ilusión a cada VM que tiene un segmento de memoria contiguo para su utilización, es decir que posee un bloque de X tamaño para utilizar. Sin embargo en la realidad la memoria que les brinda puede estar distribuida en segmentos separados. De esta forma se logra optimizar los espacios de memoria que son otorgados. Administración de la CPU Con el tiempo los microprocesadores han evolucionado en su arquitectura. Estos tiene un varios modos en los que determinan la prioridad de la ejecución. Este es un aspecto muy importante en la paravirtualización. Hacemos aquí una división en los tipos de microprocesadores: 1. Los que poseen dos niveles de prioridad. Existe un nivel de mayor prioridad (el cero). En este se ejecuta el SO, dejando el otro para las instrucciones de las aplicaciones que corren sobre este. 2. Los que poseen 5 niveles de prioridad. La arquitectura x86 se basa en un sistema de anillos, siendo el anillo cero el de mayor prioridad, y el 4 el de menor. Dejando el primero para el SO y el ultimo para el software del usuario. 3. Procesadores de la Linea Pacífica y Vanderbool de AMD e Intel. Estos cuentan con una tecnología que brindan un nivel de ejecución nuevo, que es el que mayor nivel de prioridad posee. Este es usado para la paravirtualización. En todos los casos es posible correr Xen, pero involucran distintas modificaciones a nivel software. Para los dos primeros casos es necesario que exista un Port del SO host, esto se debe a que es necesario desplazarlo una nivel de prioridad, ya que Xen necesita ejecutarse en el mas bajo. En el primer caso el SO es desplazado al segundo nivel en conjunto con los programas del usuario. Este debe ser protegido (espacios de memoria, prioridades, etc). Para el segundo caso el SO es movido al anillo 1, mientras que Xen se instala en el anillo 0. El tercer caso son microprocesadores que no demandan realizar un port del SO host. Ya se encuentran preparados para que el SO corra en la capa numero 1 y las máquinas virtuales preparadas para paravirtualización en la numero 0. Xen precisa instalarse en la capa de prioridad mas baja ya que necesita tener todos los privilegios para poder realizar operaciones como administrar ciertas Llamadas al sistema. De esta forma las puede manejar de forma mas eficiente, es decir sincronizarlas con las múltiples VM. Antes de continuar, se mostrara una tabla comparativa en la que se ilustra el costo de portar un SO x para utilizar Xen. El costo esta mostrado en lineas de código que son necesarias implementar. SO Linux Windows XP Arquitectura independiente Red 484