Soporte para Hyper-V en Windows 8

En este artículo vamos a hablar sobre cómo será el soporte para las tecnologías de virtualización en el sistema operativo de “cliente” Windows. Es una tecnología inicialmente pensada para Windows Server, donde ha demostrado su capacidad y ha tenido un gran éxito, pero queríamos mover la virtualización para abrir una serie de escenarios nuevos a usuarios de Windows profesionales. Entre ellos, los que más han merecido nuestra atención son el de los desarrolladores de software que trabajan en múltiples plataformas, clientes y servidores, y el de los profesionales de TI que necesitan gestionar clientes y servidores virtualizados de forma sencilla y transparente. Mathew John es Jefe de Programa de nuestro equipo de Hyper-V y es quien ha redactado este artículo. Una cosa a tener presente es que, como sucede con el resto de funcionalidades, aquí se habla de versiones preliminares y no de lo que será el producto final, puesto que muchas decisiones se irán tomando en fases más avanzadas del proyecto.

Tanto si sois desarrolladores de software como administradores de TI o simplemente os gusta el tema, muchos de vosotros necesitáis ejecutar varios sistemas operativos, normalmente en distintas máquinas. No todos tenemos posibilidad de montar un laboratorio completo con toda la gama de máquinas que nos gustaría, y es por eso que la virtualización es tan útil, ya que nos ahorra mucho tiempo, dinero y esfuerzo.

A la hora de desarrollar Windows 8 hemos tratado de que pueda ejecutar Hyper-V, la tecnología de virtualización que ha formado parte de las dos últimas versiones de Windows Server, parea que funcione también dentro del S.O. del cliente. En pocas palabras, Hyper-V nos permite ejecutar más de un sistema operativo de 32 y 64 bits al mismo tiempo sobre la misma máquina. En vez de trabajar directamente con el hardware del ordenador, el sistema operativo se ejecuta dentro de una máquina virtual (VM).

Hyper-V permite a los desarrolladores mantener sin dificultad múltiples entornos de test y es una alternativa sencilla para alternar entre dichos entornos sin tener que preparar hardware adicional. Por ejemplo, nosotros hemos publicado máquinas virtuales preconfiguradas con versiones antiguas de Internet Explorer para ayudar a los desarrolladores web. El administrador de TI tiene la ventaja adicional que supone poder emplear la misma máquina virtual y una misma experiencia de gestión con Hyper-V tanto en Windows Server como con el cliente Windows. Además sabemos que muchos de vosotros utilizáis la virtualización para probar novedades sin que supongan un riesgo para el PC que utilizáis habitualmente.

Introducción a Hyper-V

Hyper-V requiere un sistema operativo de 64 bits que disponga de la función SLAT (Second Level Address Translation). SLAT es una característica presente en la generación actual de procesadores de 64 bits de Intel y AMD. Así que necesitas una versión de Windows 8 de 64 bits y como mínimo, 4 Gb. de RAM. Hyper-V soporta la creación de sistemas operativos en VM tanto de 32 como 64 bits.

La memoria dinámica de Hyper-V permite asignar la memoria que necesitan las VMs y des-asignarla dinámicamente (se puede especificar un valor máximo y mínimo) y compartir la memoria no utilizada entre las VMs en ejecución. Se pueden ejecutar 3 ó 4 VMs en una máquina con 4 Gb de RAM, pero para 5 o más máquinas virtuales hay que añadir memoria. En el otro extremo del espectro, podemos crear grandes VMs con 32 procesadores y 512 Gb de RAM.

Para el acceso a las VMs a través de una interfaz de usuario, Windows ofrece dos mecanismos: la Consola de VM y la Conexión de Escritorio Remoto.

La Consola de VM (conocida también como VMConnect) es una vista en modo consola de las VMs. Ofrece una vista unificada en un mismo monitor de las VMs con resolución máxima de 1600x1200, en 32 bits de profundidad de color. Esta consola nos permite ver todo el ciclo de ejecución de las VMs desde el proceso de arranque.

Si necesitamos una experiencia más rica, podemos conectar con la VM utilizando una conexión de escritorio remoto (RDC). Con RDC, la VM aprovecha las funcionalidades que ofrece el PC físico. Por ejemplo, si tenemos varios monitores, la VM puede mostrar su salida de pantalla en todos esos monitores. De igual manera, si tenemos una interfaz multi-táctil en el PC, la VM puede utilizarla para disfrutar de una experiencia táctil. La VM además tiene plenas capacidades multimedia y es capaz de utilizar elementos del hardware físico como altavoces o micrófono. El S.O. raíz (esto es, el S.O. Windows que administra las VMs) puede también compartir su portapapeles y carpetas con las VMs. Y finalmente, con conexiones RDC podemos conectar dispositivos USB directamente a la VM.

En el caso del almacenamiento, podemos añadir múltiples discos a los controladores IDE o SCSI disponibles en la VM. Podemos utilizar discos duros virtuales (archivos .VHD o .VHDX) o discos reales que se pasan directamente a través de la máquina virtual. Los VHDs pueden también estar alojados en un servidor de archivos remoto, con lo que resulta más sencillo el mantener y compartir una misma serie de VHDs configurados o predefinidos para trabajar en equipo.

La funcionalidad de Hyper-V llamada “Live Storage Move” sirve para que las VMs tengan un grado muy amplio de independencia con respecto al almacenamiento. Con esta función podemos mover el almacenamiento de una VM desde un disco local a otro, a un pendrive USB o a un sistema remoto de almacenamiento compartido sin tener que parar la VM. Esta funcionalidad me ha resultado particularmente útil para realizar despliegues rápidos: cuando necesito una VM de urgencia, arranco una desde una biblioteca de VMs que tengo en una carpeta compartida y después traslado el almacén de la VM a mi disco local.

Otra gran ventaja de Hyper-V es la posibilidad de obtener instantáneas de una máquina virtual mientras se ejecuta. Una instantánea guarda todo el contexto de la máquina virtual en el momento de su creación y nos permite volver a un punto anterior en el tiempo de vida de una VM. Es además una herramienta muy potente para depurar problemas complejos. Al mismo tiempo, las máquinas virtuales de Hyper-V conservan todas las ventajas de manejabilidad de Windows. Windows Update puede aplicar actualizaciones y parches sobre los componentes de Hyper-V, así que no tenemos que definir procesos de mantenimiento adicionales. Y Windows ofrece todas las capacidades que le son inherentes cuando se instala Hyper-V sobre él.

Dicho esto, la virtualización también tiene sus limitaciones. Ciertas funcionalidades o aplicaciones que dependen de un hardware concreto no funcionan bien sobre VMs. Por ejemplo, Windows BitLocker y Measured Boot, requieren TPM (Trusted Platform Module), puede que no funcionen correctamente en una VM, y lo mismo ocurre en ciertos juegos y aplicaciones que necesitan acceder directamente a las GPUs (sin ofrecer ningún mecanismo de fallback por software). Además, ciertas aplicaciones que dependen de timers por debajo de los 10 milisegundos, como por ejemplo ciertas aplicaciones de alta precisión y sensibles a la latencia como son algunas aplicaciones de edición de vídeo o audio, pueden presentar problemas a la hora de funcionar en VM. El S.O. raíz también se ejecuta sobre la capa de virtualización de Hyper-V, pero es un caso especial puesto que tiene acceso directo a todo el hardware. Es por eso que las aplicaciones con requisitos especiales de hardware siguen funcionando bien en el S.O. raíz, pero las de alta precisión, sensibles a la latencia, aún pueden seguir presentando problemas a pesar de ejecutarse sobre el S.O. raíz.

Como recordatorio, no olvidemos que sigue siendo necesaria una licencia para cada uno de los sistemas operativos que se utilizan en las VMs.

Este es un vídeo que nos muestra de forma resumida, cómo funciona Hyper-V en Windows 8.

Descarga este vídeo y reprodúcelo en tu reproductor favorito:
MP4 de alta calidad | MP4 de menor calidad

Soporte para la comunicación de VMs a través de adaptadores de red inalámbrica

Como has podido ver en la demo, la creación de una conexión de red externa es algo tan simple como seleccionar un adaptador de red físico (NIC) de una lista desplegable y pulsar OK. Esto ya funciona perfectamente con Windows Server Hyper-V, pero para tener resultados similares en Windows 8 necesitamos que funcione con NICs inalámbricas, lo que supone un nuevo reto.

El problema

El switch virtual en Hyper-V es un “switch de nivel 2”, lo que quiere decir que conecta (esto es, determina la ruta que van a seguir ciertos paquetes Ethernet) utilizando las direcciones MAC que identifican de manera exclusiva a cada adaptador de red (tanto físicos como virtuales). La dirección MAC de las máquinas de origen y destino se envían en todos los paquetes Ethernet y el switch de nivel 2 utiliza estas direcciones para determinar a dónde tiene que enviar un paquete recibido. Un switch virtual externo se conecta al mundo exterior mediante una NIC física. Los paquetes Ethernet originados en una VM con destino a una máquina del mundo exterior se envían a través de esta NIC física. Esto quiere decir que la NIC física ha de ser capaz de gestionar el tráfico desde todas las VMs conectadas a este switch virtual, y por tanto, implica que los paquetes que se mueven a través de la NIC física van a contener diferentes direcciones MAC (una por cada NIC virtual de las VMs). Esta posibilidad está soportada en tarjetas de red de cable físicas (estando en modo promiscuo), pero no está soportada en tarjetas de red inalámbrica dado que el canal inalámbrico establecido por la tarjeta WiFi y su punto de acceso solo admite paquetes Ethernet con la dirección MAC de la tarjeta WiFi y ninguna otra. Dicho en otras palabras, Hyper-V no podría utilizar tarjetas WiFi para dotar switches externos si no cambiamos la actual arquitectura de switch virtual.

Figura 1: tráfico de red entre VMs y máquinas externas utilizando conexiones de cable

La solución

Para superar esta limitación hemos utilizado la solución de Microsoft Bridging que implementa la funcionalidad de proxy ARP (para IPv4) y Proxy de Descubrimiento de Vecinos (Neighbor Discovery Proxy) para IPv6, a fin de sustituir las direcciones MAC de los adaptadores de red virtuales con las direcciones MAC de los adaptadores WiFi para los paquetes salientes. El bridge mantiene una tabla de correspondencias entre las direcciones IP de las NIC virtuales y sus direcciones MAC para garantizar que los paquetes procedentes del mundo exterior se entregan en la NIC virtual adecuada.

Hyper-V integra el bridge dentro del proceso de creación del switch virtual de manera que cuando creamos un switch virtual externo utilizando una tarjeta de red WiFi, sigue estos pasos:

1. Crea un bridge específico conectado a la tarjeta WiFi
2. Crea el switch virtual externo
3. Enlaza el switch virtual externo para utilizar el bridge en lugar de atacar directamente a la tarjeta WiFi física

Bajo este modelo, la conmutación de paquetes Ethernet sigue teniendo lugar dentro del switch virtual y la traducción de direcciones MAC sucede en el bridge. A los efectos del usuario final que está creando una red externa, el flujo es el mismo, tanto con una red de cable como con una tarjeta inalámbrica.

Figura 2: tráfico de red entre VMs y máquinas externas utilizando conexión WiFi

En conclusión, al incorporar Hyper-V al cliente Windows, ahora disponemos también de una potente tecnología de virtualización diseñada para cubrir las necesidades de escalabilidad, seguridad, fiabilidad y rendimiento de la mayoría de centros de datos. Con Hyper-V los desarrolladores y profesionales de TI van a poder diseñar entornos más eficientes y económicos para usar y testear a través de múltiples máquinas.

--Mathew John

FUENTE: Steven Sinofsky - https://blogs.msdn.com/b/b8/archive/2011/09/07/bringing-hyper-v-to-windows-8.aspx

Saludos,

El equipo de MSDN España