Virtualización anidada en hardware: requisitos, usos y configuración

Informatec Digital » Recursos » Virtualización anidada en hardware: requisitos, usos y configuración

La virtualización anidada en hardware moderno se ha convertido en una herramienta casi imprescindible para equipos de TI, desarrolladores y formadores que necesitan montar laboratorios complejos, entornos de pruebas o escenarios de seguridad sin llenar el CPD de servidores físicos. En pocas palabras, hablamos de poder ejecutar máquinas virtuales dentro de otras máquinas virtuales, manteniendo un rendimiento aceptable y un control fino de los recursos.

Más allá del típico “poner una VM dentro de otra”, la virtualización anidada abre la puerta a canalizaciones DevOps flexibles, entornos de capacitación realistas, pruebas de seguridad aisladas y despliegues de IoT Edge sobre distintas plataformas, desde Hyper-V en local hasta máquinas virtuales en Azure o VMware ESXi. Eso sí, para que todo funcione como debe, el hardware y la configuración del hipervisor tienen que cumplir ciertos requisitos muy concretos.

Qué es exactamente la virtualización anidada y por qué importa

Cuando hablamos de virtualización anidada nos referimos a la capacidad de que una máquina virtual actúe como host de virtualización para otras máquinas virtuales internas. Es decir, hay un hipervisor de primer nivel sobre el hardware físico (por ejemplo, Hyper-V en Windows Server o en Azure Local) y dentro de una de sus VMs instalamos de nuevo Hyper-V u otro hipervisor compatible para crear más VMs.

En el caso de Hyper-V, la virtualización anidada permite instalar el rol de Hyper-V dentro de una máquina virtual invitada que a su vez se ejecuta sobre un host físico con Hyper-V. Esta VM “intermedia” expone las extensiones de virtualización del procesador a las VMs internas, que se comportan como si estuvieran más cerca del hardware, aunque en realidad hay varias capas por debajo.

Esta funcionalidad apareció inicialmente en Windows Server 2016 y Windows 10 para procesadores Intel, y con el tiempo se ha ido ampliando el soporte a nuevas versiones de Windows Server, Windows 11 y procesadores AMD. Hoy en día es una característica madura que Microsoft integra en su documentación oficial y que también aprovechan soluciones de terceros.

El valor práctico es claro: con virtualización anidada podemos replicar entornos de producción, crear clústeres completos, probar configuraciones arriesgadas o simular redes multicapa sin necesidad de invertir en nuevos racks ni reservar espacio en el CPD. Para muchas empresas, el ahorro de costes y la agilidad que aporta compensa de sobra la ligera penalización de rendimiento.

Casos de uso habituales de la virtualización anidada

Uno de los escenarios más populares es el montaje de laboratorios de pruebas complejos. Los equipos de desarrollo y QA pueden levantar pilas de aplicaciones de múltiples niveles (bases de datos, servicios intermedios, frontends) íntegramente dentro de una única máquina virtual principal, y dentro de ella alojar todas las VMs internas necesarias para replicar un entorno de producción.

También es muy útil en entornos de formación y entrenamiento técnico. Los instructores pueden preparar una VM host donde cada alumno crea sus propias máquinas virtuales invitadas, configura redes, prueba roles de servidor o despliega contenedores, sin tocar en ningún momento la infraestructura “seria” de la empresa. Todo queda contenido en un sandbox fácilmente desechable.

Otro uso típico es la evaluación y prueba de nuevas versiones de software. En lugar de cambiar configuraciones delicadas directamente en el host físico, los administradores pueden duplicar el escenario sobre una VM con virtualización anidada y validar parches, nuevas releases o cambios de seguridad antes de dar el salto a producción.

La virtualización anidada también juega un papel importante a la hora de habilitar características de seguridad avanzadas como la seguridad basada en virtualización (VBS) o aislamientos específicos que dependen de funciones de hipervisor a diferentes niveles. Esto permite endurecer ciertos entornos sin necesidad de hardware adicional.

En el ámbito IoT, la virtualización anidada es clave para escenarios de Azure IoT Edge para Linux en Windows, donde es necesario combinar Windows, contenedores Linux y capacidades de hipervisor sobre diferentes capas de virtualización, tanto en local como sobre plataformas de terceros como VMware ESXi o máquinas virtuales en Azure.

Requisitos de hardware y software para virtualización anidada

Para que todo esto funcione correctamente, el primer filtro es el hardware compatible y las versiones mínimas de sistema operativo. En entornos de Azure Local, por ejemplo, se requiere ejecutar la versión 2411.3 o posterior, junto con máquinas virtuales cuya versión de configuración sea 10.0 o superior, asegurando así el soporte de las extensiones de virtualización necesarias.

En el plano del procesador, si se trabaja con Intel es indispensable tener habilitada la tecnología de virtualización Intel VT-x en la BIOS/UEFI. En arquitecturas AMD, se necesita soporte AMD-V y, para escenarios avanzados, la tecnología Secure Encrypted Virtualization (SEV) activada, que añade cifrado a las VMs y mejora el aislamiento y la seguridad a bajo nivel.

El sistema operativo host debe ser una versión moderna de Windows Server o Windows 10/11, convenientemente actualizada con los últimos parches. Hyper-V tiene que estar instalado en el equipo físico antes de intentar habilitar el anidamiento; no es una característica que venga funcionando de serie solo por disponer de un CPU compatible.

Otro punto clave es el estado de las máquinas virtuales. Para modificar parámetros de procesador y exponer extensiones de virtualización, la VM que va a actuar como host anidado debe estar completamente apagada, no en pausa ni en estado de guardado. Solo así Hyper-V permite cambiar opciones avanzadas del procesador virtual.

Por último, hay que planificar bien la conectividad de red. Las VMs anidadas pueden requerir acceso hacia fuera o hacia otras capas, por lo que conviene definir desde el principio si se van a usar switches internos, NAT, suplantación de dirección MAC u otras técnicas de red virtual para evitar problemas de comunicación y filtrado.

Habilitar virtualización anidada en Hyper-V mediante PowerShell

La forma más directa y granular de activar la virtualización anidada en Hyper-V es utilizar cmdlets de PowerShell. Esta vía funciona tanto en Windows Server como en ediciones cliente compatibles y permite automatizar la configuración en varios hosts o VMs de forma consistente.

El primer paso es asegurarse de que la máquina virtual donde queremos instalar Hyper-V como invitado está apagada desde el Administrador de Hyper-V (opción Apagar) o mediante el comando adecuado en PowerShell, por ejemplo Stop-VM -Name 'NombreVM'. Si permanece suspendida o en estado de guardado, los cambios en el procesador no se aplicarán correctamente.

Con la VM detenida, hay que exponer las extensiones de virtualización del procesador al sistema operativo invitado con el cmdlet Set-VMProcessor, indicando la opción de ExposeVirtualizationExtensions a verdadero. Este ajuste es el que permite que, desde dentro de la VM, el sistema vea las funciones necesarias para instalar roles de hipervisor.

Para verificar si la operación se ha aplicado correctamente podemos usar Get-VMProcessor combinado con Select sobre el campo ExposeVirtualizationExtensions. De este modo, se comprueba si el valor aparece en true en la configuración del procesador virtual de la VM objetivo y se evita arrancar un entorno parcialmente configurado.

Si en algún momento es necesario revertir la configuración —por ejemplo, durante una tarea de diagnóstico o porque ya no se requieren VMs anidadas— basta con repetir el mismo cmdlet de procesador pero cambiando el valor a false, lo que desactiva de nuevo la exposición de extensiones de virtualización a la VM invitada.

Una vez ajustado el procesador virtual, se enciende la máquina con Start-VM o desde el Administrador de Hyper-V y, desde el interior del sistema operativo invitado, se procede a instalar el rol completo de Hyper-V siguiendo los métodos habituales: Server Manager (Agregar roles y características), DISM, PowerShell, etc. A partir de ahí, esa VM se comporta como un host Hyper-V adicional desde el punto de vista del administrador.

Configuración de red y suplantación de MAC en entornos anidados

Con la parte de procesador lista, el siguiente frente es la conectividad de red de las máquinas virtuales anidadas. Si queremos que las VMs internas se comuniquen con otras redes, con internet o con equipos de la capa superior, es fundamental ajustar ciertos parámetros en el adaptador virtual de la VM intermedia.

En Hyper-V, una práctica habitual es habilitar la opción de suplantación de direcciones MAC (MAC spoofing) en el adaptador de red de la VM que actúa como host anidado. Esta característica permite que las VMs internas envíen tráfico utilizando sus propias direcciones MAC a través del mismo adaptador, evitando bloqueos o filtrados en el switch virtual del host físico.

El ajuste puede hacerse desde PowerShell usando el cmdlet Set-VMNetworkAdapter con el parámetro MacAddressSpoofing establecido en On, aplicado al adaptador de red correspondiente de la VM. De esta forma se garantiza que el tráfico procedente de las VMs más profundas no sea descartado por el hipervisor de primer nivel.

Para configuraciones más avanzadas, resulta conveniente diseñar con antelación la topología de switches virtuales e instancias NAT en cada capa. Por ejemplo, podemos combinar switches internos para aislar laboratorios, reglas de enrutamiento o firewall entre niveles y NAT en el host intermedio para proporcionar acceso a internet a múltiples VMs anidadas sin exponerlas directamente.

Cuando se trabaja con varias capas de virtualización, los problemas de conectividad suelen tener que ver con MAC spoofing desactivado, reglas NAT mal encadenadas o firewalls demasiado restrictivos. Revisar estos puntos y reiniciar adaptadores o servicios de red en cada nivel suele resolver la mayoría de incidencias de conectividad en entornos anidados.

Uso de la interfaz gráfica para tareas relacionadas

Aunque la activación estricta de la virtualización anidada se controla por completo desde PowerShell, en la práctica muchas tareas relacionadas resultan más cómodas a través de la interfaz gráfica del Administrador de Hyper-V, sobre todo si gestionamos varios hosts o queremos revisar la configuración de forma visual.

Un flujo típico consiste en abrir el Administrador de Hyper-V, localizar la máquina virtual objetivo y asegurarse de que está apagada utilizando la opción Apagar. Esto complementa al uso de PowerShell y evita arrancar por error una VM que todavía no tiene todos los parámetros correctamente configurados.

Una vez ejecutados los cmdlets necesarios para exponer las extensiones de virtualización, podemos regresar al entorno gráfico y abrir la ventana de configuración de la VM. Desde ahí es sencillo revisar y modificar las propiedades del adaptador de red, el número de procesadores virtuales asignados o la memoria disponible para la VM host anidado.

En la sección de funciones avanzadas del adaptador de red, es donde se encuentra la casilla para habilitar la suplantación de dirección MAC. Activarla desde la interfaz gráfica es rápido y transparente para administradores que prefieren trabajar visualmente o que no memorizaron todos los parámetros de los cmdlets.

Una vez completada esta configuración, la administración diaria del entorno puede hacerse indistintamente desde la consola de Hyper-V en el host físico o dentro de la VM anidada, utilizando las herramientas estándar para crear nuevas VMs, configurar switches, añadir roles o realizar snapshots según las necesidades de cada laboratorio.

Virtualización anidada en Azure Local y escenarios IoT Edge

En entornos de Azure Local, la virtualización anidada se apoya en los mismos principios, pero añade requisitos específicos de versión y soporte para funciones avanzadas como AMD SEV o extensiones de seguridad. Se exige ejecutar una versión mínima del sistema (2411.3 o superior) y que las VMs utilicen una versión de configuración compatible (10.0 o posterior).

Cuando se trabaja con Azure IoT Edge para Linux en Windows, existen tres modalidades de despliegue con virtualización anidada compatibles. Cada una responde a diferentes necesidades de infraestructura y grado de control que la organización desea mantener sobre el entorno subyacente y el hipervisor.

La primera opción consiste en implementar IoT Edge sobre una máquina virtual de Windows en un host local con Hyper-V. Es el enfoque más directo: se habilita la virtualización anidada en esa VM de Windows y, a partir de ahí, se instala y configura Azure IoT Edge para Linux en Windows según la documentación específica de Microsoft.

En este caso es crucial asegurarse de que, en el host local (Windows Server o Azure Local), el rol de Hyper-V esté correctamente instalado. Sin Hyper-V activo en el host, la VM invitada no podrá actuar como hipervisor anidado ni exponer las funciones requeridas para IoT Edge en una capa adicional.

Este tipo de despliegues son muy útiles cuando se necesita integrar dispositivos IoT, contenedores Linux y servicios de Azure dentro de infraestructuras existentes de Windows, manteniendo un equilibrio razonable entre flexibilidad, rendimiento y facilidad de gestión.

Virtualización anidada con VMware ESXi y Azure IoT Edge

Otro escenario interesante se da cuando queremos ejecutar Azure IoT Edge para Linux en Windows sobre una máquina virtual de Windows alojada en VMware ESXi. En este contexto, la virtualización anidada depende de las capacidades del hipervisor de VMware en lugar de Hyper-V directamente sobre el hardware.

Las versiones de VMware ESXi 6.7 y 7.0 incluyen soporte explícito para virtualización asistida por hardware en invitados, lo que hace posible habilitar el anidamiento necesario para que una VM de Windows pueda convertirse en host de Hyper-V. VMware documenta esta característica en su base de conocimiento, donde se detallan requisitos y posibles consideraciones de rendimiento.

El procedimiento general pasa por crear primero una VM de Windows en el host ESXi, siguiendo las recomendaciones habituales de VMware para procesadores, memoria, almacenamiento y adaptadores de red. Una vez creada, se apaga la máquina para poder modificar su configuración avanzada de CPU.

Desde la interfaz de ESXi o vSphere Client, se selecciona la VM de Windows, se entra en la opción Edit settings y, dentro del bloque de ajustes de CPU, se localiza el apartado de virtualización de hardware. Ahí es donde se activa la casilla de Exponer virtualización asistida por hardware al sistema operativo invitado, que permite a Windows ver las extensiones VT-x/AMD-V a pesar de estar corriendo dentro de ESXi.

Tras guardar los cambios y arrancar de nuevo la VM, se procede a instalar el hipervisor Hyper-V en Windows, ya sea en una edición cliente (Windows 10/11) o en Windows Server, asegurándose de incluir las herramientas de administración y cualquier componente adicional requerido para los contenedores o servicios que se vayan a usar con IoT Edge.

Virtualización anidada en máquinas virtuales de Azure

Cuando subimos el escenario un nivel más y trabajamos directamente con máquinas virtuales en Azure como host de virtualización anidada, entran en juego particularidades de la plataforma, especialmente en lo que respecta a los switches virtuales y la red por defecto que usan las VMs de Azure.

Azure IoT Edge para Linux en Windows no se considera compatible de forma nativa sobre cualquier VM de Azure que ejecute una SKU de servidor si no se ejecuta un script específico para habilitar un conmutador virtual adecuado. Este script abre un switch predeterminado que permite al entorno IoT Edge trabajar correctamente con la capa de virtualización adicional.

La documentación oficial de Microsoft describe los pasos para crear y configurar un conmutador virtual para Linux en Windows en el contexto de Azure, alineando así los requisitos de red de los contenedores y servicios Edge con las características de la infraestructura de red de la nube.

En este tipo de despliegues, es particularmente importante revisar la SKU de la VM, el tipo de almacenamiento y las cuotas de CPU y RAM, ya que la virtualización anidada añade su propia sobrecarga y las VMs internas pueden consumir recursos de forma intensiva si no se dimensiona todo el conjunto adecuadamente.

A pesar de estas complejidades, el beneficio es significativo: se puede utilizar una VM de Azure como plataforma de pruebas, desarrollo o preproducción de soluciones IoT Edge en las mismas condiciones que luego se replicarán en dispositivos edge físicos o gateways industriales desplegados sobre el terreno.

Copia de seguridad de VMs anidadas de Hyper-V con soluciones especializadas

Un aspecto que muchas veces se pasa por alto al diseñar entornos de virtualización anidada es la estrategia de copias de seguridad y recuperación ante desastres. Aquí entran en juego soluciones de backup de nivel empresarial capaces de manejar correctamente entornos Hyper-V con varias capas de virtualización y múltiples plataformas en paralelo.

Entre estas soluciones se encuentran herramientas como Vinchin Backup & Recovery, que soportan más de una quincena de plataformas de virtualización distintas, incluyendo VMware, Proxmox, oVirt, OLVM, RHV, XCP-ng, XenServer, OpenStack, ZStack y, por supuesto, Hyper-V. Este tipo de software está pensado para infraestructuras heterogéneas donde conviven hipervisores de varios fabricantes.

Funciones como la copia de seguridad incremental perpetua, la deduplicación y compresión de datos o las restauraciones granulares permiten reducir significativamente el consumo de almacenamiento y el tiempo necesario para recuperar máquinas individuales, archivos concretos o incluso objetos específicos de aplicaciones críticas.

Además, las políticas de respaldo programado y las opciones de archivado en cinta o en la nube ayudan a adaptar la estrategia de backup a los requisitos normativos o internos de cada organización, manteniendo retenciones largas sin disparar los costes de almacenamiento en cabinas de alto rendimiento.

La consola web de administración simplifica mucho la protección de entornos Hyper-V con VMs anidadas: se seleccionan las VMs a proteger, se elige el repositorio de backup, se define la estrategia de ejecución (ventanas de tiempo, tipo de copia, retención) y se lanza el trabajo. Muchas de estas soluciones ofrecen periodos de prueba completos durante varias semanas para evaluar su rendimiento y encaje en la infraestructura existente.

Limitaciones y buenas prácticas en entornos anidados

Aunque las posibilidades de la virtualización anidada son amplias, también existen limitaciones técnicas impuestas por el propio diseño de los hipervisores que conviene conocer desde el principio para no llevarse sorpresas en producción o en escenarios de alta disponibilidad.

Un ejemplo claro es la migración en vivo de VMs que están utilizando virtualización anidada. A día de hoy, no es posible realizar live migration de un host de primer nivel mientras dentro de sus VMs existan invitados que dependan del anidamiento activo. Microsoft documenta esta restricción y, en general, la recomendación es planificar actualizaciones o movimientos de host con paradas controladas en estos entornos.

El seguimiento del consumo de recursos a través de varias capas requiere una estrategia combinada. Es aconsejable usar Hyper-V Manager, contadores de rendimiento y cmdlets como Get-VM en el host de primer nivel y, simultáneamente, herramientas similares dentro del host anidado para tener una visión clara de cómo se distribuye la carga entre CPU, memoria, red y almacenamiento.

Cuando de repente una VM interna pierde conectividad de red, suele ser síntoma de cambios en las reglas de firewall, problemas con NAT o ajustes de MAC spoofing desactivados en alguno de los adaptadores implicados. Revisar todos los niveles, verificar la configuración y reiniciar los servicios de red afectados acostumbra a resolver la mayoría de estos cortes.

Como buena práctica general, antes de desplegar virtualización anidada conviene definir claramente el objetivo del entorno, el número de capas, el tipo de cargas que se van a ejecutar y la política de backups. De ese diseño inicial dependerá que el laboratorio o escenario de pruebas sea sostenible a largo plazo y no se convierta en una maraña difícil de mantener.

En definitiva, la virtualización anidada de Hyper-V y otras plataformas permite sacar mucho más partido al hardware existente y montar escenarios de laboratorio, pruebas, seguridad o IoT Edge con una flexibilidad enorme, siempre que se respeten los requisitos de CPU, versión de sistema y configuración de red, y se acompañe todo ello con una buena estrategia de supervisión y copias de seguridad.