stringtranslate.com

Hipervisor

Un hipervisor , también conocido como monitor de máquina virtual ( VMM ) o virtualizador , es un tipo de software , firmware o hardware de computadora que crea y ejecuta máquinas virtuales . Una computadora en la que un hipervisor ejecuta una o más máquinas virtuales se denomina máquina host , y cada máquina virtual se denomina máquina invitada . El hipervisor presenta a los sistemas operativos invitados una plataforma operativa virtual y administra la ejecución de los sistemas operativos invitados. A diferencia de un emulador , el invitado ejecuta la mayoría de las instrucciones en el hardware nativo. [1] Varias instancias de una variedad de sistemas operativos pueden compartir los recursos de hardware virtualizados: por ejemplo, las instancias de Linux , Windows y macOS pueden ejecutarse en una sola máquina física x86 . Esto contrasta con la virtualización a nivel de sistema operativo , donde todas las instancias (generalmente llamadas contenedores ) deben compartir un solo núcleo, aunque los sistemas operativos invitados pueden diferir en el espacio de usuario , como diferentes distribuciones de Linux con el mismo núcleo.

El término hipervisor es una variante de supervisor , un término tradicional para el núcleo de un sistema operativo : el hipervisor es el supervisor de los supervisores, [2] con hyper- usado como una variante más fuerte de super- . [a] El término data de alrededor de 1970; [3] IBM lo acuñó para el software que ejecutaba OS/360 y el emulador 7090 simultáneamente en el 360/65 [4] y luego lo usó para el manejador DIAG de CP-67. En el sistema CP/CMS (1967) anterior , se usó el término Programa de control en su lugar.

Algunas publicaciones, especialmente en contextos de microkernel , hacen una distinción entre hipervisor y monitor de máquina virtual (VMM). Allí, ambos componentes forman la pila de virtualización general de un determinado sistema. Hipervisor se refiere a la funcionalidad del espacio del kernel y VMM a la funcionalidad del espacio del usuario . Específicamente en estos contextos, un hipervisor es un microkernel que implementa una infraestructura de virtualización que debe ejecutarse en el espacio del kernel por razones técnicas, como Intel VMX . Los microkernels que implementan mecanismos de virtualización también se conocen como microhipervisor . [5] [6] Aplicando esta terminología a Linux , KVM es un hipervisor y QEMU o Cloud Hypervisor son VMM que utilizan KVM como hipervisor. [7]

Clasificación

Hipervisores de tipo 1 y tipo 2

En su tesis de 1973, "Principios arquitectónicos para sistemas informáticos virtuales", Robert P. Goldberg clasificó dos tipos de hipervisor: [1]

Hipervisores de tipo 1, nativos o de hardware real
Estos hipervisores se ejecutan directamente en el hardware del host para controlar el hardware y administrar los sistemas operativos invitados. Por este motivo, a veces se los llama hipervisores de hardware . Los primeros hipervisores, que IBM desarrolló en la década de 1960, eran hipervisores nativos. [8] Estos incluían el software de prueba SIMMON y el sistema operativo CP/CMS , el predecesor de la familia VM de sistemas operativos de máquinas virtuales de IBM . Algunos ejemplos de hipervisores de tipo 1 incluyen Hyper-V , Xen y VMware ESXi .
Hipervisores de tipo 2 o alojados
Estos hipervisores se ejecutan en un sistema operativo (SO) convencional, al igual que otros programas informáticos. Un monitor de máquina virtual se ejecuta como un proceso en el host, como VirtualBox . Los hipervisores de tipo 2 abstraen los sistemas operativos invitados del sistema operativo host, creando de manera efectiva un sistema aislado con el que el host puede interactuar. Algunos ejemplos de hipervisores de tipo 2 son VirtualBox y VMware Workstation .

La distinción entre estos dos tipos no siempre es clara. Por ejemplo, KVM y bhyve son módulos del núcleo [9] que convierten efectivamente el sistema operativo host en un hipervisor de tipo 1. [10]

Orígenes del mainframe

Los primeros hipervisores que ofrecían virtualización completa fueron la herramienta de prueba SIMMON y el sistema de investigación IBM CP-40 , que comenzó a utilizarse en producción en enero de 1967 y se convirtió en la primera versión del sistema operativo IBM CP/CMS . CP-40 se ejecutaba en un S/360-40 modificado en el Centro Científico de Cambridge para admitir la traducción dinámica de direcciones , una característica que permitía la virtualización. Antes de este momento, el hardware de las computadoras solo se había virtualizado en la medida en que permitía que varias aplicaciones de usuario se ejecutaran simultáneamente, como en CTSS e IBM M44/44X . Con CP-40, el estado del supervisor del hardware también se virtualizó, lo que permitió que varios sistemas operativos se ejecutaran simultáneamente en contextos de máquinas virtuales separados.

Los programadores pronto implementaron CP-40 (como CP-67 ) para el IBM System/360-67 , el primer sistema informático de producción capaz de virtualización completa. IBM envió esta máquina en 1966; incluía hardware de tabla de traducción de páginas para memoria virtual y otras técnicas que permitían una virtualización completa de todas las tareas del núcleo, incluyendo la E/S y el manejo de interrupciones. (Tenga en cuenta que el sistema operativo "oficial", el malogrado TSS/360 , no empleaba virtualización completa). Tanto CP-40 como CP-67 comenzaron a usarse en producción en 1967. CP/CMS estuvo disponible para los clientes de IBM desde 1968 hasta principios de la década de 1970, en forma de código fuente sin soporte.

CP/CMS formó parte del intento de IBM de construir sistemas robustos de tiempo compartido para sus computadoras mainframe . Al ejecutar varios sistemas operativos simultáneamente, el hipervisor aumentó la robustez y la estabilidad del sistema: incluso si un sistema operativo fallaba, los demás continuaban funcionando sin interrupción. De hecho, esto incluso permitió que se implementaran y depuraran versiones beta o experimentales de sistemas operativos (o incluso de nuevo hardware [11] ), sin poner en peligro el sistema de producción principal estable y sin requerir costosos sistemas de desarrollo adicionales.

IBM anunció su serie System/370 en 1970 sin la característica de memoria virtual necesaria para la virtualización, pero la agregó en el anuncio de Función avanzada de agosto de 1972. La virtualización se ha incluido en todos los sistemas sucesores, de modo que todos los mainframes IBM actuales, incluida la línea zSeries , mantienen la compatibilidad con la línea IBM S/360 de la década de 1960. El anuncio de 1972 también incluyó VM/370 , una reimplementación de CP/CMS para el S/370. A diferencia de CP/CMS , IBM proporcionó soporte para esta versión (aunque todavía se distribuyó en forma de código fuente para varias versiones). VM significa Virtual Machine (máquina virtual ) , lo que enfatiza que todas, no solo algunas, de las interfaces de hardware están virtualizadas. Tanto VM como CP/CMS disfrutaron de una aceptación temprana y un desarrollo rápido por parte de universidades, usuarios corporativos y proveedores de tiempo compartido , así como dentro de IBM. Los usuarios desempeñaron un papel activo en el desarrollo continuo, anticipándose a las tendencias observadas en los proyectos de código abierto modernos . Sin embargo, en una serie de disputas y amargas batallas [ cita requerida ] , el tiempo compartido perdió ante el procesamiento por lotes debido a las luchas políticas internas de IBM, y VM siguió siendo el "otro" sistema operativo de mainframe de IBM durante décadas, perdiendo ante MVS . Disfrutó de un resurgimiento de popularidad y apoyo a partir de 2000 como el producto z/VM , por ejemplo como la plataforma para Linux en IBM Z.

Como se mencionó anteriormente, el programa de control de la máquina virtual incluye un controlador de llamadas de hipervisor que intercepta las instrucciones DIAG ("Diagnosticar", código de operación x'83') utilizadas dentro de una máquina virtual. Esto proporciona una ejecución no virtualizada de acceso al sistema de archivos y otras operaciones de manera rápida (DIAG es una instrucción privilegiada dependiente del modelo, no se utiliza en la programación normal y, por lo tanto, no está virtualizada. Por lo tanto, está disponible para su uso como una señal para el sistema operativo "host"). Cuando se implementó por primera vez en la versión 3.1 de CP/CMS , este uso de DIAG proporcionó una interfaz de sistema operativo que era análoga a la instrucción de llamada de supervisor (SVC) de System/360 , pero que no requería alterar o extender la virtualización de SVC del sistema.

En 1985, IBM introdujo el hipervisor PR/SM para gestionar particiones lógicas (LPAR).

Compatibilidad con sistemas operativos

Varios factores llevaron a un resurgimiento alrededor de 2005 en el uso de la tecnología de virtualización entre Unix , Linux y otros sistemas operativos similares a Unix : [12]

Los principales proveedores de Unix, incluidos HP , IBM , SGI y Sun Microsystems , han estado vendiendo hardware virtualizado desde antes de 2000. Estos han sido generalmente sistemas grandes y costosos (en el rango de varios millones de dólares en el extremo superior), aunque la virtualización también ha estado disponible en algunos sistemas de gama baja y media, como servidores IBM pSeries , máquinas de la serie HP Superdome y servidores Sun / Oracle T-series CoolThreads.

Aunque Solaris siempre ha sido el único sistema operativo de dominio invitado oficialmente soportado por Sun/Oracle en su hipervisor Logical Domains , a finales de 2006 , Linux (Ubuntu y Gentoo) y FreeBSD han sido portados para ejecutarse sobre el hipervisor (y todos pueden ejecutarse simultáneamente en el mismo procesador, como sistemas operativos invitados independientes completamente virtualizados). Wind River "Carrier Grade Linux" también se ejecuta en el hipervisor de Sun. [13] La virtualización completa en procesadores SPARC resultó sencilla: desde su inicio a mediados de la década de 1980, Sun mantuvo deliberadamente la arquitectura SPARC limpia de artefactos que habrían impedido la virtualización. (Compare con la virtualización en procesadores x86 a continuación.) [14]

HPE ofrece máquinas virtuales HP Integrity (Integrity VM) para alojar varios sistemas operativos en sus sistemas Integrity con Itanium . Itanium puede ejecutar HP-UX , Linux, Windows y OpenVMS , y estos entornos también son compatibles como servidores virtuales en la plataforma Integrity VM de HP. El sistema operativo HP-UX aloja la capa de hipervisor Integrity VM que permite aprovechar muchas características importantes de HP-UX y proporciona una diferenciación importante entre esta plataforma y otras plataformas de productos básicos, como intercambio en caliente de procesadores, intercambio en caliente de memoria y actualizaciones dinámicas del núcleo sin reiniciar el sistema. Si bien aprovecha en gran medida HP-UX, el hipervisor Integrity VM es realmente un híbrido que se ejecuta en hardware mientras los invitados se ejecutan. Se desaconseja enfáticamente ejecutar aplicaciones HP-UX normales en un host Integrity VM, [¿ por quién? ] porque Integrity VM implementa su propia gestión de memoria, programación y políticas de E/S que están optimizadas para máquinas virtuales y no son tan efectivas para aplicaciones normales. HPE también proporciona particionamiento más rígido de sus sistemas Integrity y HP9000 mediante tecnología VPAR y nPar , la primera ofrece particionamiento de recursos compartidos y la segunda ofrece aislamiento completo de procesamiento y E/S. La flexibilidad del entorno de servidor virtual (VSE) ha dado paso a su uso con mayor frecuencia en implementaciones más nuevas. [ cita requerida ]

IBM proporciona tecnología de partición de virtualización conocida como partición lógica (LPAR) en los sistemas System/390 , zSeries , pSeries e IBM AS/400 . Para los sistemas Power de IBM, el hipervisor POWER (PHYP) es un hipervisor nativo (bare-metal) en el firmware y proporciona aislamiento entre las LPAR. La capacidad del procesador se proporciona a las LPAR de forma dedicada o en base a derechos, donde la capacidad no utilizada se aprovecha y se puede reasignar a cargas de trabajo con mucha actividad. Los grupos de LPAR pueden tener su capacidad de procesador administrada como si estuvieran en un "pool"; IBM se refiere a esta capacidad como Pools de procesadores compartidos múltiples (MSPP) y la implementa en servidores con el procesador POWER6 . Las asignaciones de capacidad de LPAR y MSPP se pueden cambiar dinámicamente. La memoria se asigna a cada LPAR (al inicio de la LPAR o dinámicamente) y el hipervisor POWER controla la dirección. Para el direccionamiento en modo real por parte de los sistemas operativos ( AIX , Linux , IBM i ), los procesadores Power ( POWER4 en adelante) han diseñado capacidades de virtualización donde se evalúa un desplazamiento de dirección de hardware con el desplazamiento de dirección del sistema operativo para llegar a la dirección de memoria física. Los adaptadores de entrada/salida (E/S) pueden ser "propiedad" exclusiva de las LPAR o compartidos por las LPAR a través de una partición de dispositivo conocida como Servidor de E/S virtual (VIOS). El hipervisor Power proporciona altos niveles de confiabilidad, disponibilidad y capacidad de servicio (RAS) al facilitar la adición/reemplazo en caliente de muchas partes (según el modelo: procesadores, memoria, adaptadores de E/S, ventiladores, unidades de energía, discos, controladores del sistema, etc.)

Se han producido tendencias similares con las plataformas de servidores x86/x86-64, donde los proyectos de código abierto como Xen han liderado los esfuerzos de virtualización. Entre ellos se incluyen hipervisores basados ​​en núcleos Linux y Solaris, así como núcleos personalizados. Dado que estas tecnologías abarcan desde grandes sistemas hasta computadoras de escritorio, se describen en la siguiente sección.

sistemas x86

La virtualización x86 se introdujo en la década de 1990, y su emulación se incluyó en Bochs . [15] Intel y AMD lanzaron sus primeros procesadores x86 con virtualización de hardware en 2005 con Intel VT-x (nombre en código Vanderpool) y AMD-V (nombre en código Pacifica).

Un enfoque alternativo requiere modificar el sistema operativo invitado para que realice una llamada de sistema al hipervisor subyacente, en lugar de ejecutar instrucciones de E/S de máquina que el hipervisor simula. Esto se denomina paravirtualización en Xen , "hiperllamada" en Parallels Workstation y "código de DIAGNÓSTICO" en IBM VM . Algunos microkernels, como Mach y L4 , son lo suficientemente flexibles como para permitir la paravirtualización de sistemas operativos invitados.

Sistemas embebidos

Los hipervisores integrados , destinados a sistemas integrados y ciertos entornos de sistemas operativos en tiempo real (RTOS), están diseñados con diferentes requisitos en comparación con los sistemas de escritorio y empresariales, incluyendo robustez, seguridad y capacidades en tiempo real . La naturaleza limitada en recursos de muchos sistemas integrados, especialmente los sistemas móviles alimentados por batería, impone un requisito adicional de tamaño de memoria pequeño y baja sobrecarga. Finalmente, en contraste con la ubicuidad de la arquitectura x86 en el mundo de las PC, el mundo integrado utiliza una variedad más amplia de arquitecturas y entornos menos estandarizados. El soporte para la virtualización requiere protección de memoria (en forma de una unidad de administración de memoria o al menos una unidad de protección de memoria) y una distinción entre modo de usuario y modo privilegiado , que descarta la mayoría de los microcontroladores . Esto todavía deja a x86 , MIPS , ARM y PowerPC como arquitecturas ampliamente implementadas en sistemas integrados de gama media a alta. [16]

Como los fabricantes de sistemas integrados suelen tener el código fuente de sus sistemas operativos, tienen menos necesidad de virtualización completa en este ámbito. En cambio, las ventajas de rendimiento de la paravirtualización hacen que esta sea la tecnología de virtualización preferida. No obstante, ARM y MIPS han añadido recientemente compatibilidad con virtualización completa como opción IP y la han incluido en sus últimos procesadores de gama alta y versiones de arquitectura, como ARM Cortex-A15 MPCore y ARMv8 EL2.

Otras diferencias entre la virtualización en entornos de servidores/escritorios y entornos integrados incluyen requisitos para compartir recursos de manera eficiente entre máquinas virtuales, comunicación entre máquinas virtuales de alto ancho de banda y baja latencia, una visión global de la programación y la administración de energía, y un control detallado de los flujos de información. [17]

Implicaciones de seguridad

El uso de la tecnología de hipervisor por parte de malware y rootkits que se instalan como un hipervisor debajo del sistema operativo, conocido como hyperjacking , puede hacerlos más difíciles de detectar porque el malware podría interceptar cualquier operación del sistema operativo (como que alguien ingrese una contraseña) sin que el software anti-malware necesariamente lo detecte (ya que el malware se ejecuta debajo de todo el sistema operativo). La implementación del concepto supuestamente ocurrió en el rootkit de laboratorio SubVirt (desarrollado conjuntamente por investigadores de Microsoft y la Universidad de Michigan [18] ) así como en el paquete de malware Blue Pill . Sin embargo, tales afirmaciones han sido cuestionadas por otros que afirman que sería posible detectar la presencia de un rootkit basado en hipervisor. [19]

En 2009, investigadores de Microsoft y la Universidad Estatal de Carolina del Norte demostraron un anti-rootkit de capa de hipervisor llamado Hooksafe que puede proporcionar protección genérica contra rootkits de modo kernel . [20]

Notas

  1. ^ super- proviene del latín, que significa "encima", mientras que hyper- proviene del término cognado en griego antiguo (ὑπέρ-), que también significa encima o encima de .

Véase también

Referencias

  1. ^ ab Goldberg, Robert P. (1973). Principios arquitectónicos para sistemas informáticos virtuales (PDF) (informe técnico). Universidad de Harvard. ESD-TR-73-105.
  2. ^ Bernard Golden (2011). Virtualización para tontos . pág. 54.
  3. ^ "¿Cómo surgió el término "hipervisor"?"
  4. ^ Gary R. Allred (mayo de 1971). Emulación integrada de System/370 bajo SO y DOS (PDF) . Conferencia informática conjunta de primavera de 1971. Vol. 38. AFIPS Press. pág. 164. doi :10.1109/AFIPS.1971.58 . Consultado el 12 de junio de 2022 .
  5. ^ Steinberg, Udo; Kauer, Bernhard (2010). "NOVA: A Microhypervisor-Based Secure Virtualization Architecture" (PDF) . Actas de la Conferencia Europea ACM de 2010 sobre Sistemas Informáticos (EuroSys 2010) . París, Francia . Consultado el 27 de agosto de 2024 .
  6. ^ "Hedron Microkernel". GitHub . Cyberus Technology . Consultado el 27 de agosto de 2024 .
  7. ^ "Cloud Hypervisor". GitHub . Proyecto Cloud Hypervisor . Consultado el 27 de agosto de 2024 .
  8. ^ Meier, Shannon (2008). "Virtualización de sistemas IBM: servidores, almacenamiento y software" (PDF) . pp. 2, 15, 20. Consultado el 22 de diciembre de 2015 .
  9. ^ Dexter, Michael. "Hands-on bhyve". CallForTesting.org . Consultado el 24 de septiembre de 2013 .
  10. ^ Graziano, Charles (2011). Un análisis del rendimiento de los hipervisores Xen y KVM para alojar el proyecto Xen Worlds (tesis de maestría). Universidad Estatal de Iowa. doi : 10.31274/etd-180810-2322 . hdl :20.500.12876/26405 . Consultado el 16 de octubre de 2022 .
  11. ^ Véase Historial de CP/CMS para simulación de hardware virtual en el desarrollo del Sistema/370
  12. ^ Loftus, Jack (19 de diciembre de 2005). «La virtualización de Xen se está convirtiendo rápidamente en una 'aplicación revolucionaria' de código abierto». TechTarget . Consultado el 26 de octubre de 2015 .
  13. ^ "Wind River apoyará el innovador procesador multiproceso de próxima generación UltraSPARC T1 de Sun". Wind River Newsroom (nota de prensa). Alameda, California. 1 de noviembre de 2006. Archivado desde el original el 10 de noviembre de 2006 . Consultado el 26 de octubre de 2015 .
  14. ^ Fritsch, Lothar; Husseiki, Rani; Alkassar, Ammar. Tecnologías complementarias y alternativas a la informática de confianza (TC-Erg./-A.), Parte 1, Un estudio por encargo de la Oficina Federal Alemana para la Seguridad de la Información (BSI) (PDF) (Informe). Archivado desde el original (PDF) el 7 de junio de 2020. Consultado el 28 de febrero de 2011 .
  15. ^ "Introducción a Bochs". bochs.sourceforge.io . Consultado el 17 de abril de 2023 .
  16. ^ Strobl, Marius (2013). Virtualización para sistemas integrados fiables. Múnich: GRIN Publishing GmbH. pp. 5-6. ISBN 978-3-656-49071-5. Recuperado el 7 de marzo de 2015 .
  17. ^ Gernot Heiser (abril de 2008). "El papel de la virtualización en sistemas embebidos". Proc. 1er Taller sobre Aislamiento e Integración en Sistemas Embebidos (IIES'08) . pp. 11–16. Archivado desde el original el 21 de marzo de 2012. Consultado el 8 de abril de 2009 .
  18. ^ "SubVirt: Implementación de malware con máquinas virtuales" (PDF) . Universidad de Michigan , Microsoft . 3 de abril de 2006. Consultado el 15 de septiembre de 2008 .
  19. ^ "Desmintiendo el mito de la píldora azul". Virtualization.info. 11 de agosto de 2006. Archivado desde el original el 14 de febrero de 2010. Consultado el 10 de diciembre de 2010 .
  20. ^ Wang, Zhi; Jiang, Xuxian; Cui, Weidong; Ning, Peng (11 de agosto de 2009). "Contrarrestar rootkits de kernel con protección ligera contra ataques de hackers". Actas de la 16.ª conferencia de la ACM sobre seguridad informática y de las comunicaciones (PDF) . CCS '09. Chicago, Illinois, EE. UU.: ACM . pp. 545–554. CiteSeerX 10.1.1.147.9928 . doi :10.1145/1653662.1653728. ISBN .  978-1-60558-894-0. S2CID  3006492 . Consultado el 11 de noviembre de 2009 .

Enlaces externos