¿En qué se diferencia la virtualización de la emulación, en términos de estructura?


20

Alguien me dijo que un programa de virtualización como VirtualBox no funciona como un emulador, en el sentido de que no emula registros y usa los reales para los datos virtualizados que están en la CPU. Los emuladores deben emular los registros, ya que son principalmente para ejecutar software que depende de un entorno extraño (por ejemplo, un emulador Genesis necesita los registros y las direcciones de memoria de Motorola 68000, por lo que el desarrollador debe hacer que estos recursos estén disponibles como registros emulados).

Mi pregunta principal es, ¿cómo se desarrolla la virtualización? ¿Cómo permitimos que un sistema operativo completo se ejecute como un proceso en una máquina virtual, pero que se ejecute de forma independiente mientras se sigue utilizando la CPU real? Solo conozco la emulación, no la virtualización, así que si alguien pudiera ayudar, ¡sería bueno!

PD: No estoy preguntando únicamente cuál es la diferencia, sino las diferencias en cómo ejecutan el software.

Respuestas:


32

Originalmente, no podía permitir que el SO invitado usara hardware real porque no tenía forma de controlarlo. Si trató de ejecutarlo en la CPU real, no tenía garantía de que devolvería el control al sistema operativo host.

La virtualización tal como la describe se implementa en el hardware al permitir que ciertas reglas y restricciones se apliquen a nivel de hardware, que puede ser administrado por el sistema operativo host. Esto permite que el sistema operativo host establezca reglas sobre lo que el invitado puede y no puede hacer, y luego ejecutar el invitado en hardware real. Si el invitado intenta hacer algo con el hardware real que infringe las reglas (como intentar acceder a un dispositivo de disco), el hardware suspenderá al invitado y le enviará una interrupción al host, lo que le permite proporcionar una respuesta (como devolver datos de un dispositivo de disco emulado) y luego reanudar el invitado.

Aquí hay un ejemplo simplificado del proceso:

SO host: Hola CPU, necesito que ejecutes este código virtualizado. Llámame si quiere hacer algo que no sea solo ejecutar instrucciones.

CPU host: ¡lo tienes!
La CPU del host guarda todos los registros y el estado del host, y luego comienza a ejecutar el código del SO invitado

SO invitado: estoy vivo! Hola CPU, ¿puedes traerme este archivo?

CPU host: Uh ... claro. Un momento.
Host CPU guarda todos los registros de invitados y el estado, y luego restaura todos los registros de host y el estado
CPU de host: ¡Hola Host OS, el Invitado quería este archivo!

Host OS: Oh, bueno, dales esto: archivo del disco duro virtual

CPU host: ¡lo tienes!
La CPU del host guarda todos los registros y el estado del host, restaura los registros y el estado del invitado, y luego comienza a ejecutar el código del SO invitado.
CPU del host: ¡ Aquí está ese archivo!

SO invitado: ¡ Dulce, gracias!

La diferencia clave aquí está en un emulador, el sistema operativo invitado nunca se ejecuta realmente en el hardware. Con la virtualización, el sistema operativo host configura las limitaciones en la CPU, y luego ejecuta el código de invitado en la CPU física. El ejemplo anterior está extremadamente simplificado, pero la memoria, la E / S de disco e incluso las redes se pueden controlar en los últimos procesadores de la actualidad, lo que les permite interactuar de forma segura sin tener que molestar al sistema operativo host cada vez. Mientras el invitado no intente salir de los límites virtualizados, es posible que el sistema operativo host no tenga ningún código en ejecución si no tiene nada que hacer en un momento determinado.


Para agregar un poco de perspectiva, este es solo un paso más en una larga historia de virtualización y control. (No garantiza que esto esté en el orden correcto o que sea exhaustivo, pero debería proporcionar una buena visión general inicial)

Originalmente, no había virtualización. Todos los procesos compartían el mismo espacio de memoria, todos tenían acceso completo al hardware, y la capacidad de realizar múltiples tareas dependía por completo de que un proceso se detuviera y diera el control al siguiente proceso. Si el sistema operativo quería tener algún tipo de control sobre un proceso, tenía que ejecutar el proceso en un emulador (nadie lo hacía, porque era demasiado lento).

Primero fue la memoria privilegiada : ciertas acciones que solo pueden ser realizadas por regiones especiales de memoria. Estas regiones están ocupadas por el sistema operativo, lo que le permite actuar como una puerta de entrada a estas acciones privilegiadas. Un ejemplo es la capacidad de leer / escribir datos en el hardware. Esto evita que los procesos lean / escriban directamente en el disco duro, y en su lugar los obliga a pedirle al sistema operativo que los lea / escriba. Esto significa que el sistema operativo puede verificar si el proceso tiene permiso antes de realizar la acción.

Luego vino el "tiempo" virtualizado, por así decirlo. El sistema operativo podría configurar la CPU para interrumpir el proceso activo a intervalos establecidos, lo que le permite tomar el control de la programación y cambiar entre procesos. El sistema operativo ahora podría ejecutar procesos directamente en el hardware y aún así evitar que usen mal el tiempo de la CPU. Esto fue proporcionado por un temporizador de hardware .

Luego vino la memoria virtualizada : el problema con la memoria compartida es que cualquier proceso podría leer la memoria de cualquier otro proceso. ¿Qué sucede cuando el programa de Mary lee la contraseña de Bob desde su navegador web? La memoria virtual permite que el sistema operativo asigne la memoria que un proceso ve a diferentes partes de la memoria física, o incluso las saca completamente de la memoria física (al archivo de página). Cada vez que un proceso intenta leer o escribir en la memoria, la VMMU (unidad de administración de memoria virtual) de la CPU busca dónde está asignada en la memoria física y realiza la acción allí. Si está mapeado de memoria, entonces la CPU llama al sistema operativo para recuperar la página en la memoria desde el archivo de página.

Muy bien, en este punto hemos llegado a los inicios del procesador X86, donde podemos ejecutar procesos de manera segura y podemos evitar activamente que se hagan cargo del sistema a menos que el sistema operativo específicamente les permita hacerlo. En este punto, los procesos están efectivamente "virtualizados". Este soporte ha existido durante mucho tiempo, por lo que realmente no se escucha a la gente hablar sobre procesos virtualizados, ya que se supone que todos los procesos están virtualizados ahora.

Sin embargo, ¿por qué son especiales los SO virtualizados? ¿Por qué no podemos comenzar uno como un proceso y dejar que haga lo suyo? Bueno, el problema es que, como sistema operativo, el sistema invitado espera poder acceder y usar los mismos controles que usa el host para controlar los procesos; básicamente, el sistema operativo espera ser el gobernante supremo de la computadora, y simplemente no lo hacen ' No funciona si ese no es el caso. Las extensiones de "virtualización de hardware" (AMD-V para AMD y VT-x para Intel) permiten que el sistema operativo host proporcione un conjunto virtualizado de controles de procesos virtuales (memoria virtual privilegiada, temporizadores de hardware virtual, memoria virtual virtual).


Me recuerda a una obra de un acto de IRC que vi una vez (posiblemente NSFW: contiene algo de lenguaje PG-13)
Scott Chamberlain

Mi computadora no tiene virtualización de hardware (AMD-V ni VT-x). Pero puedo ejecutar una máquina virtual en VirtualBox ... VirtualBox instala un controlador en el sistema operativo para poder hacer eso. ¿Cómo se hace eso?
Nada imposible

1
@NothingsImpossible: a menos que tenga una máquina muy antigua, la mayoría de las CPU convencionales que se venden actualmente admiten la virtualización de hardware. La virtualización básica siempre es posible porque la CPU enviará una interrupción al supervisor (kernel) si algún programa (como un SO invitado) intenta ejecutar instrucciones que no están permitidas en el nivel de seguridad actual. Todo lo que el sistema operativo host debe hacer es atrapar esas interrupciones, descubrir la operación deseada y reanudar la ejecución del proceso secundario. AMD-V / VT-x solo permite una virtualización más eficiente, ya que ahora la CPU misma puede servir las instrucciones "no permitidas".
Lie Ryan

@LieRyan Gracias por la explicación. Pero no es viejo, es un procesador Atom. Este, para ser precisos: ark.intel.com/products/70105
NothingsImpossible

1

¿Cómo permitimos que un sistema operativo completo se ejecute como un proceso en una máquina virtual, pero que se ejecute de forma independiente mientras se sigue utilizando la CPU real?

(Lo siguiente se simplifica mucho).

Al aprovechar el mismo mecanismo o similar que utiliza el sistema operativo para mantener los procesos en modo de usuario en línea, principalmente.

Los procesos en modo de usuario causarán excepciones de CPU cuando intenten hacer algo que no se les permite hacer.

Entonces, si tenemos un kernel del sistema operativo ejecutado en modo de usuario, cada vez que intente hacer algo como acceder al hardware directamente, provocará una excepción. Un hipervisor puede detectar esa excepción y responder con un comportamiento emulado o virtualizado, en lugar de causar un bloqueo del sistema como lo haría un núcleo normal.

Puede realizar el acceso de hardware en nombre de este núcleo, realizar un acceso de hardware modificado (es decir, acceder a una parte de un archivo en lugar de un acceso directo al sector del disco) o cualquier otra cosa que pueda imaginar.

Las extensiones de máquina virtual de la CPU básicamente extienden todo el modo "supervisor" o "protegido" de la CPU un nivel más para hacer exactamente esto, y también proporcionan un "nivel de anidación" adicional de memoria virtual para que la paginación sea más fácil de virtualizar.


0

La virtualización implica simular partes del hardware de una computadora, lo suficiente para que un sistema operativo invitado se ejecute sin modificaciones, pero la mayoría de las operaciones aún se producen en el hardware real por razones de eficiencia. Por lo tanto, la virtualización es normalmente más rápida que la emulación, pero el sistema real debe tener una arquitectura idéntica al sistema invitado. Por ejemplo, VMWare puede proporcionar un entorno virtual para ejecutar una máquina virtual con Windows XP "dentro" de una real. Sin embargo, VMWare no puede funcionar en ningún hardware real que no sea una PC x86 real.

En la emulación, la máquina virtual simula el hardware completo del software. Esto permite que un sistema operativo para una arquitectura de computadora se ejecute en la arquitectura para la que está escrito el emulador. Sin embargo, todas las operaciones se ejecutan en software, la emulación tiende a ser más lenta, sin embargo, puede admitir más plataformas, ya que es independiente del hardware.


Ok ... pero, ¿cómo quieres decir "simular" partes del hardware? Un emulador hace exactamente lo mismo ... ¿cómo la virtualización consigue que el SO huésped aproveche los recursos reales de la CPU?
toneladas de bons

@tonsbons: por definición. : P Un emulador no hace exactamente lo mismo: emula todo, desde la CPU en adelante. Bochs, por ejemplo, es un emulador. La virtualización es más delgada; un hipervisor ejecuta el SO huésped en la CPU física (básicamente engaña al invitado para que piense que es el propietario de la CPU). Sin embargo, dado que el invitado no tiene los privilegios que cree que tiene, desencadena "fallas" cuando intenta hacer cosas kernelly. El hipervisor observa esas fallas y hace girar el hardware virtual para que parezca al huésped como si esas operaciones realmente sucedieran.
cHao

0

Solo para completar, también hay simulación , donde las acciones de la máquina se duplican, pero mediante el uso de código cuyas partes internas pueden ser radicalmente diferentes de la máquina "real". (Piense en "simulador de vuelo"). A menudo, los simuladores compilarán el código fuente de la máquina "real", pero se centrarán en una arquitectura de CPU completamente diferente, con un sistema operativo y unas instalaciones de E / S completamente diferentes.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.