Nota técnica: Virtualización asistida por hardware.

Mucho se habla (y más se hablará) sobre las ventajas e inconvenientes de la Virtualización asistida por Hardware. Los dos contendientes en la Chip Wars, AMD e Intel incorporan en sus chips nuevos juegos de instrucciones que facilitan la virtualización. Por un lado, AMD con Su codename Pacifica, y por otro, Intel con Vanderpool.

Pero antes de hablar sobre estas tecnologías, veamos los tres grandes tipos de virtualización: Emulación, Paravirtualización y traducción binaria.

El método de virtualización con el que creo todos estamos más familiarizados es la emulación. Todos hemos ejecutado el emulador de nintendo, o el de pocket PC, por poner ejemplos. Y todos sabemos cual es su principal problema: La lentitud. El overhead de simular byte a byte un hardware por software hace trabajar a las CPU de manera considerable. El desarrollo de emuladores es una tarea ardua y propensa a errores.

En el otro extremo está la Paravirtualización. La paravirtualización (PV) parte de la base de que el sistema operativo huesped "sabe" perfectamente que está siendo ejecutado en un entorno virtual, y modifica su comportamiento de acuerdo con esto. Los sistemas operativos necesitan ser modificados para adaptarse a un entorno "hardware" virtual, lo que implica que hay una relación directa entre cómo se escribe el kernel del sistema operativo y cómo virtualiza la capa de virtualización. Realmente la Paravirtualización no es virtualización pura, sino más bien una colaboración entre la capa de virtualización y el sistema operativo virtualizado. Esto funciona bastante bien en entornos abiertos, donde el kernel del sistema operativo (como linux o BSD) puede ser modificado para tener en cuenta que "debajo" hay una capa de virtualización, pero en el caso de otros OS'es (como es el caso de Windows), la cosa no está tan clara. En este caso, hablar de rendimiento nativo es realmente relativo, ya que un OS's virtualizado no ejecuta exactamente el mismo código ni opera igual que si corriera en hardware real.

En el medio de estas dos opciones encontramos la, que hasta el momento, parece ser la mejor opción: La traducción binaria. La traducción binaria. La traducción binaria parte de la base de la existencia de un monitor de máquinas virtuales (VMM) que monitoriza a cada segundo las instrucciones que el sistema operativo huesped envía al procesador. Si el VMM detecta una instrucción problemática (que puede afectar al entorno de virtualización, otras VMM o a la estabilidad del hardware hospedador - host), rápidamente la reescribe (muchas veces convirtiendo una sola instrucción en docenas de ellas), y devuelve el resultado al huesped, que interpreta que esa instrucción original ha sido ejecutada. El resto de instrucciones no problemáticas son pasadas directamente al procesador.

Es evidente que reescribir instrucciones no es la manera más rápida de virtualizar, pero sí nos garantiza la ejecución de cualquier OS soportado SIN necesidad de reescribir el kernel del mismo. También abre la puerta a la virtualización de OS's que corren en hardware distinto al de nuestra plataforma base (en este caso, x86, x64, i64)... imaginad AIX corriendo en una VM... o incluso el Cisco IOS... porqué no?

¿porqué es necesario hacer todo esto?... pues básicamente porque la arquitectura x86 no es virtualizable. Entendamos un poco cómo funciona nuestro PC.

Existen, al menos, 4 niveles de privilegio de acceso al procesador, llamados anillos y numerados del 0 al 3, cuya prioridad es inversa a su numeración, aunque en la práctica, sólo se usan el 0 y el 3 (el de mayor y menor prioridad, respectivamente). Los sistemas operativos usan típicamente el anillo 0, mientras que los programas usan, también típicamente, el anillo 3. De hecho, las extensiones de 64 bits de los procesadores x64 sacrifican, en muchos casos, los anilos 1 y 2... No hay demasiada gente que se haya preocupado por ello (¿vosotros lo notáis?)... salvo aquellos que trabajan desarrollando capas de virtualización.

Es evidente que las capas de virtualización (VMware ESX, por ejemplo) se ejecutan en el anillo 0, y para poder mantener constantemente el control del sistema, han de mantener al OS huésped fuera de él. La solución más obvia es, entonces, ejecutarlo en el anillo 1 (por ejemplo). Esto sería una solución gloriosa si no fuera por esa manía de los sistemas operativos de ejecutarse en el anillo 0. En entornos de paravirtualización no hay problema: como el huésped colabora con la capa de virtualización, este puede decidir ejecutarse en anillo 1, por ejemplo, si la capa de virtualización así se lo indica. En la traducción binaria, hay que "obligar" o "engañar" al huesped para que se ejecute en el anillo 1. Esto tampoco parece complicado, salvo porque hay determinadas instrucciones no funcionan o lo hacen de modo extraño si no se ejecutan en el anillo 0 del procesador. La traducción binaria hace eso exactamente: Mentirle al sistema operativo huesped.

La virtualización asistida por hardware entra precisamente en este punto mediante el nuevo modo VMX. Por resumirlo de una manera sencilla (aunque no totalmente exacta), tanto Vanderpool como Pacifica permiten a la capa de virtualización ejecutarse en un "anillo -1", es decir, con mayor prioridad que el 0, de forma que ya no es necesario engañar al sistema operativo. El Virtual Machine Monitor se ejecuta en modo VMX root, mientras las VM se ejecutan en modo VMX. El procesador alterna entre universos mediante los procesos "VM entry" y "VM exit."

Las tecnologías VT permiten movernos (mediante VM entry y VM exit) entre el modo VMX y el VMX root, aislando a nivel de procesador, los universos del Virtual Machine Monitor (VMM) y de la máquina virtual (VM).

¿Maravilloso, No? Pues no... El trabajo de recordar que estaban haciendo el VMM y todas las VM no está implementado a nivel de procesador. El procesador provee mecanismos simples que facilitan al VMM la conservación de estados, pero el trabajo sucio sigue siendo del VMM.

Para quien le interese enterarse en profundidad de qué va todo esto, le recomiendo el siguiente link de donde, y si mi inglés no me ha abandonado, he sacado parte de la información que ofrece este post.

Ahora bien... ¿Vanderpool o Pacífica? Aunque el mecanismo es el mismo, las instrucciones, e incluso el modo de operación, varía. Pacifica parece ser un superset de Vanderpool, ofreciendo más mecanismos en el chip para facilitar la vida de los VMM. Estos comandos extras se agrupan en tres tecnologías propias de AMD, Nested Table Pages, Device Exclusion Vector y el Tagged TLB. Este documento os cuenta más extensamente que hacen estas tecnologías.

Que conste que Pacífica aún no tiene implementadas del todo estas tecnologías, por lo que lo que obtendréis al pagar un AMD con Pacífica es poco más que lo que os dá Vanderpool.

Como resumen, parece ser que Pacífica le pondrá más fácil las cosas a los VMM, mientras que Vanderpool sacrifica funciones en favor de la velocidad.

¿porqué tanto ruido con la virtualización asistida por hardware? Respuesta fácil: es la única manera en que un entorno Paravirtualizado (como Xen o Viridian) pueda ejecutar un sistema operativo sin modificar el kernel. Básicamente el procesador permite a un OS sin modificar instalarse en el anillo 0, dejando el -1 para el VMM. Evidentemente, esto a VMware le hace bastante poca gracia, dado que, en teoría, la traducción binaria ya no haría falta. Digo en teoría porque se me ocurren un par de cositas que la traducción binaria puede solucionar y que me dá a mi que tal y como se llevan Intel y AMD la virtualización asistida no:

• Diferencia entre procesadores: el uso masivo de VT generará una mayor dificultad para el movimiento de VM entre diferentes modelos de procesador. Actualmente VMware "soporta" ligeros cambios de serie (Especialmente en Opterones y Xeones, donde los cambios en los micros suelen estar relacionados con el anillo 0, que se gestiona por Traducción Binaria y no por VT).
• Compatibilidad: La traducción binaria extiende el campo de la virtualización a prácticamente cualquier micro x86 de 32 bits. VT la limita a la incorporación de esta tecnología.
• VT es una tecnología emergente, aún saliendo del horno. Intel ya habla de VT v2, VT v3 y VT v4.... ¿Será la compatibilidad descendente una rémora de rendimiento tal y como lo fueron los 16 bits?
• VT está siendo desarrollada por fabricantes de hardware, no por fabricantes de VMM... y teniendo en cuenta pasadas colaboraciones.... no sé yo que pensar.
• VT limita la virtualización a plataformas x86.... La traducción binaria puede abrir nuevas puertas para la virtualización de otras plataformas.

¿Intereses creados? Todos. A favor: Microsoft el primero, porque si no se olvida de competir con VMware. Xen Enterprise, los segundos porque así pueden ejecutar Windows. Intel y AMD, los terceros, ya que la virtualización les quita "negocio", al menos algo recuperarán con lo que está por venir. En contra: VMware, que ve a la competencia meterse en su nicho privado, que era hasta ahora la ejecución de Windows en una VM.

Mi opinión: Que sobrevivan las dos. Hasta VMware puede sacar partido de VT.

¿Pero es tan realmente importante eso? Yo, personalmente, creo que no. No pienso que lo más importante en un entorno virtualizado sea en qué anillo se ejecute el OS, o la velocidad de ejecución de las máquinas virtuales. Creo que hay cosas más importantes que valorar: Estabilidad, snapshots, movilidad entre hosts, opciones de HA.... se me ocurren mil cosas que pedir antes de mayor o menor velocidad.

¿a vosotros no?

PD. Gura, espero que esto fuera lo que querías, camarada.