La virtualización anidada (nested virtualization) es una función que te deja correr Hyper-V dentro de una máquina virtual de Hyper-V. Dicho de otro modo: una VM deja de ser solo una invitada y pasa a poder hospedar sus propias máquinas virtuales.
Esto funciona porque los procesadores modernos incluyen extensiones de hardware que aceleran y aseguran la virtualización, como Intel VT-x y AMD-V. Hyper-V depende de esas extensiones para arrancar sus VMs. Sin anidamiento, el hipervisor toma el control total de esas capacidades y no las expone al sistema operativo invitado. Con la virtualización anidada activada, Hyper-V sí las expone a la VM, y entonces esa invitada puede instalar su propio hipervisor y ejecutar sus propias VMs.
Para quién es útil
La documentación de Microsoft señala varios casos concretos donde compensa:
- Ejecutar aplicaciones o emuladores en una VM anidada.
- Probar versiones de software sobre VMs antes de pasarlas a producción.
- Reducir los tiempos de despliegue de entornos de formación.
- Usar Hyper-V isolation para contenedores.
Para laboratorios de pruebas y entornos de evaluación encaja especialmente bien. Puedes modificar configuraciones con facilidad y usar estados guardados para volver a una situación concreta. Y como un laboratorio no suele exigir el mismo SLA que producción, te ahorras montar hardware físico solo para ensayar.
Hay escenarios soportados en producción, tanto en Azure como on-premises: VMs de Hyper-V sobre VMs de Hyper-V, contenedores aislados con Hyper-V ejecutándose anidados, y WSL2 dentro de una VM de Hyper-V que a su vez corre anidada. Microsoft admite un nivel de anidamiento en producción, que es justo lo que necesita un despliegue de contenedores aislados. Eso sí, recomienda comprobar que tus propios servicios y aplicaciones también estén soportados en ese montaje.
Lo que no funciona igual
La virtualización anidada arrastra limitaciones que conviene tener claras antes de montarte un laboratorio:
- Memoria. Cuando Hyper-V corre dentro de una VM, esa VM debe estar apagada para ajustar su memoria. Aunque tengas la memoria dinámica activada, la cantidad no fluctúa. Activar el anidamiento por sí solo no cambia el comportamiento de la memoria dinámica ni del redimensionado en caliente. Si la VM no tiene memoria dinámica, intentar ajustar la RAM mientras está en marcha falla. La incompatibilidad solo aparece mientras Hyper-V se está ejecutando dentro de la VM.
- Otros hipervisores. Las aplicaciones de virtualización ajenas a Hyper-V no están soportadas dentro de VMs de Hyper-V y es probable que fallen. Aquí entra cualquier software que necesite extensiones de virtualización por hardware.
- Rendimiento. Microsoft desaconseja la virtualización anidada para Windows Server Failover Clustering y para aplicaciones sensibles al rendimiento. Cuando un contenedor aislado corre anidado hay dos niveles de hipervisor por encima del host físico, y eso suma latencia en arranque, almacenamiento, red y CPU.
Cómo encaja en un entorno de virtualización
Si gestionas un parque de Hyper-V, la virtualización anidada te ahorra hardware: un único host físico puede albergar laboratorios completos donde cada VM hace de host a su vez. Es la forma natural de probar un clúster, ensayar una migración o formar a un equipo sin tocar la infraestructura real.
El concepto no es exclusivo de Microsoft. Plataformas como Proxmox VE también permiten anidar hipervisores con un planteamiento parecido, exponiendo las extensiones de CPU a la VM invitada. Si trabajas con varias plataformas, el patrón es reconocible: la diferencia está en los detalles de soporte y en las limitaciones de cada una.
Azure Local merece una nota aparte: está diseñado y probado sobre hardware físico validado. Puede correr anidado en una VM para evaluación, pero los entornos de producción en configuración anidada no están soportados.