La virtualización anidada ha pasado de ser una rareza de laboratorio a convertirse en una pieza clave para montar entornos complejos de pruebas, formación, desarrollo e incluso ciertos escenarios en la nube pública. Poder ejecutar máquinas virtuales dentro de otras máquinas virtuales abre un abanico enorme de posibilidades, desde montar un mini CPD en tu portátil hasta levantar un campus de prácticas completo en Azure o probar nuevas versiones de hipervisores en AWS sin arruinarte.
En este artículo vamos a bajar a tierra qué es exactamente la virtualización anidada, cómo se implementa en VMware, Hyper-V (Azure) y AWS EC2, qué requisitos tiene, sus principales casos de uso reales, implicaciones de rendimiento, redes, licenciamiento y buenas prácticas. La idea es que, al terminar de leer, tengas una visión muy completa y práctica sobre cuándo te interesa usarla, cómo montarla y qué limitaciones vas a encontrarte.
Qué es la virtualización anidada
Cuando hablamos de virtualización anidada nos referimos a la capacidad de ejecutar un hipervisor como máquina virtual dentro de otro hipervisor que corre sobre hardware físico, y a su vez poder crear VMs dentro de ese hipervisor invitado. Es decir, una VM dentro de otra VM, con varias capas de virtualización una encima de otra.
En este contexto se manejan varios términos que conviene tener claros para no liarse: el hipervisor que se ejecuta directamente sobre el servidor físico es el hipervisor host, mientras que el hipervisor que instalamos dentro de una máquina virtual se suele llamar hipervisor invitado. Las VMs que corren directamente sobre el host físico son los llamados huéspedes externos y las que se ejecutan dentro de ese hipervisor invitado son los huéspedes internos o máquinas virtuales anidadas.
Desde el punto de vista técnico, el hipervisor invitado se cree que está hablando con hardware físico real, pero en realidad está trabajando contra un hardware virtualizado que le presenta el hipervisor host. Si tienes suficientes recursos, puedes incluso encadenar más niveles (capa 4, capa 5, etc.), aunque el rendimiento y la gestión se complican bastante y en la práctica rara vez se pasa de dos o tres niveles.
Virtualización asistida por hardware y requisitos básicos
Para que la virtualización anidada funcione de forma medianamente decente es imprescindible contar con virtualización asistida por hardware (Intel VT-x, AMD-V o equivalentes). Estas extensiones permiten que el hipervisor gestione las transiciones de contexto y las instrucciones sensibles de manera mucho más eficiente que con técnicas antiguas como la traducción binaria o la paravirtualización.
En la práctica esto implica que debes asegurarte de que la CPU del servidor físico soporta estas extensiones y que están habilitadas en la BIOS/UEFI. Además, el hipervisor host debe tener la capacidad de exponer esas extensiones de virtualización al sistema operativo invitado para que el hipervisor que corre como VM pueda a su vez crear máquinas virtuales de 64 bits y aprovechar la aceleración por hardware.
Otro requisito importante en entornos VMware es el nivel de hardware virtual de la VM que va a alojar el hipervisor invitado. Para poder habilitar la virtualización anidada se requiere, como mínimo, la versión de hardware 9 de la máquina virtual. A partir de ahí, versiones más modernas de Workstation, Player, Fusion y ESXi incorporan soporte explícito para virtualizar las extensiones de CPU dentro de las VMs.
Hipervisores y compatibilidades
La virtualización anidada está disponible tanto en hipervisores de tipo 1 (bare metal) como en hipervisores de tipo 2. En el ecosistema VMware, ESXi es el clásico hipervisor de tipo 1, mientras que Workstation, Player y Fusion son hipervisores de tipo 2 que se instalan sobre un sistema operativo anfitrión.
En estos productos se puede ejecutar como VM otro ESXi, o incluso hipervisores de terceros como Microsoft Hyper-V o VirtualBox, siempre que el hipervisor host permita virtualizar la HV (Hardware Virtualization) hacia dentro. A grandes rasgos, las combinaciones soportadas de forma técnica serían:
- ESXi como VM en VMware Workstation, Player o Fusion.
- ESXi como VM en ESXi (entorno completamente anidado dentro del propio stack VMware).
- ESXi como VM en hipervisores de terceros (por ejemplo, sobre Hyper-V).
- Hipervisores no VMware como VM en ESXi, Workstation, Player o Fusion, siempre que sean capaces de aprovechar virtualización por hardware.
En Hyper-V, la virtualización anidada se aprovecha sobre todo en contextos como Azure Lab Services, donde se permite habilitar Hyper-V dentro de una VM de laboratorio para crear a su vez máquinas virtuales anidadas. Y en AWS, la llegada del soporte oficial de virtualización anidada a EC2 estándar (no solo instancias bare metal) ha supuesto un salto importante para muchos entornos de test y desarrollo.
Soporte y restricciones oficiales en VMware
Aunque en la práctica la virtualización anidada funciona muy bien en VMware, es importante tener en cuenta el aspecto de soporte oficial. VMware no contempla las VMs anidadas como una configuración soportada para entornos de producción, lo que se traduce en que, si abres un caso con soporte y la incidencia está relacionada con un entorno anidado, es muy probable que no te den cobertura.
La gran excepción en el ecosistema VMware es el uso del vSAN Witness Appliance, una máquina virtual ESXi anidada que actúa como testigo en arquitecturas de vSAN Stretched Clusters. En este caso VMware sí reconoce y documenta expresamente este uso, al formar parte de la arquitectura oficial del producto.
Hay otro escenario relevante: la seguridad basada en virtualización (VBS) de Microsoft en VMs Windows. Desde vSphere 6.7, VMware soporta habilitar VBS dentro de máquinas virtuales Windows, lo que en la práctica supone ejecutar Hyper-V y ciertas funciones de aislamiento por virtualización dentro de una VM. Este caso está claramente documentado y sí entra en el paraguas de soporte si cumples los requisitos de versión y configuración.
Licenciamiento en entornos anidados
Cuando se instalan ESXi, vCenter u otros componentes de vSphere como máquinas virtuales para montar un entorno anidado, hay que tener presente que el licenciamiento es exactamente el mismo que si se instalaran en servidores físicos. Cada instancia de ESXi, aunque sea virtual, requiere su licencia o, en su defecto, se puede utilizar la edición gratuita o versiones de prueba para entornos de laboratorio.
Esto se aplica tanto si despliegas ESXi anidados sobre VMware como si los ejecutas como VM en hipervisores de terceros. Una forma habitual de optimizar licencias de CPU en estos laboratorios es jugar con el número de cores por socket asignados a la VM ESXi (parámetro cpuid.coresPerSocket), siempre que las condiciones de licencia lo permitan y respetes los límites de la edición contratada.
Casos reales de uso de virtualización anidada en VMware
El gran atractivo de la virtualización anidada es que te permite montar entornos muy complejos sobre un único host físico sin necesidad de desplegar racks de servidores, cabinas de almacenamiento o switches dedicados. Algunos de los usos más habituales en VMware son especialmente claros.
Laboratorios de formación y autoaprendizaje
Quizá el caso más típico es el de los laboratorios de formación. Puedes desplegar varias máquinas virtuales ESXi, un vCenter Server y una VM para almacenamiento compartido (NAS virtual, vSAN o similar) sobre un único host físico y reproducir casi al completo un entorno vSphere de producción: clústers, HA, DRS, Storage DRS, vMotion, etc.
Este enfoque es perfecto tanto para que un administrador se monte un laboratorio doméstico en su PC o servidor de casa, como para impartir formación interna en una empresa. El hecho de que todo corra anidado simplifica mucho las pruebas: si un alumno rompe un host ESXi virtual o las VMs anidadas, basta con restaurar la VM ESXi externa desde una copia de seguridad para dejarlo todo como estaba.
Desarrollo de soluciones para vSphere
Los equipos que desarrollan aplicaciones o integraciones específicas para VMware (plugins, herramientas de backup, automatización, orquestación, etc.) suelen necesitar entornos repetibles donde levantar versiones concretas de ESXi, vCenter y diferentes configuraciones de red y almacenamiento.
Gracias a la virtualización anidada pueden desplegar hiper-rápido múltiples entornos de prueba, con combinaciones de versiones, clústers y políticas diferentes, sin necesidad de disponer de un gran parque de servidores físicos ni de cabinas costosas. Se arranca el entorno, se hace la prueba, se destruye o se clona según convenga, todo sobre un mismo hipervisor host.
Pruebas, actualizaciones y demos
Otro uso muy potente es el de las pruebas de nuevas versiones de hipervisores o de cambios de arquitectura. Antes de actualizar ESXi en los hosts físicos de producción o de introducir una nueva solución de almacenamiento, muchos administradores montan el escenario anidado, simulan la actualización y validan que todo funciona como se espera.
De la misma forma, los equipos comerciales y preventa suelen utilizar entornos vSphere anidados para hacer demos en vivo a clientes: levantan varios ESXi, un vCenter, un servidor de almacenamiento virtual y algunas VMs, todo dentro de una única máquina física de laboratorio o incluso un portátil potente, y pueden mostrar funcionalidades como vMotion, HA, DRS o SRM sin depender de una sala técnica completa.
Entornos mixtos y nubes públicas
La virtualización anidada también se aprovecha para que proveedores de servicios gestionados puedan alojar VMware sobre nubes públicas o sobre plataformas heterogéneas. Un ejemplo práctico es desplegar un ESXi virtual sobre un host de nube pública y alojar ahí las VMs de un cliente que ya trabaja con VMware, manteniendo sus herramientas y procedimientos.
Además, la posibilidad de hacer copia de seguridad de entornos anidados de varias formas (respaldando la VM que contiene el hipervisor invitado o las VMs anidadas individualmente) ofrece mucha flexibilidad de protección de datos en estos escenarios híbridos.
Rendimiento de las máquinas virtuales anidadas
A nivel de rendimiento hay que ser realista: cada capa adicional de virtualización introduce overhead. En VMware, por cada VM en ejecución existe un proceso en el host ESXi que consume RAM y CPU. Si dentro de una de esas VMs estás ejecutando a su vez un ESXi con varias VMs anidadas, en realidad estás acumulando varias capas de procesos, cambios de contexto y planificación sobre los mismos núcleos físicos.
En la práctica, las VMs anidadas suelen ir más lentas que las VMs normales. La magnitud del impacto depende de factores como el rendimiento del procesador físico, la cantidad de memoria disponible, el tipo de almacenamiento y, sobre todo, el número de niveles de anidamiento y de VMs simultáneas. Para carga ligera de laboratorio es perfectamente manejable, pero para producción exigente no suele ser la mejor opción.
Herramientas VMware específicas para ESXi anidado
Cuando instalas ESXi dentro de una máquina virtual, también es importante contar con VMware Tools para ese ESXi virtualizado. Se trata del conjunto de drivers y servicios que permite al hipervisor host comunicarse mejor con la VM invitada y mejorar su gestión.
En el caso de ESXi anidado, VMware Tools proporciona funcionalidades como la visualización de la IP y el hostname del ESXi virtual desde el cliente vSphere, la posibilidad de apagar o reiniciar ordenadamente el ESXi anidado desde la consola de gestión y la ejecución de scripts cuando cambia su estado de alimentación, además de soporte para operaciones dentro de la VM a través de la Guest Operations API.
En versiones antiguas de ESXi 5.x había que instalar estas herramientas manualmente mediante un paquete VIB. A partir de vSphere 6.0, las herramientas necesarias ya vienen integradas en ESXi, por lo que cuando instalas ESXi en una VM de manera estándar, VMware Tools aparece directamente como presentes y en ejecución, simplificando mucho la administración diaria.
Red y políticas de seguridad en entornos anidados VMware
El plano de red es uno de los puntos que más quebraderos de cabeza da al montar un entorno ESXi anidado. Por defecto, los switches virtuales de ESXi no se diseñaron pensando en hipervisores dentro de VMs, así que hay que ajustar ciertas políticas de seguridad para que las VMs anidadas puedan comunicarse correctamente con el exterior.
En un host ESXi físico que va a alojar hipervisores anidados hay que modificar el vSwitch (o el grupo de puertos correspondiente) habilitando el modo promiscuo, permitiendo cambios de dirección MAC y aceptando tramas con MAC de origen falsificada (Forged Transmits). Si se dejan estos parámetros en el valor por defecto (Reject), el switch virtual descarta el tráfico que proviene de las VMs anidadas al no coincidir la MAC efectiva con la de la NIC virtual del ESXi invitado.
Modo promiscuo y su impacto
El modo promiscuo es una política de seguridad que hace que una interfaz de red reciba todas las tramas L2 que pasan por el vSwitch, no solo las dirigidas a su propia MAC. Se suele usar para monitorización de red, análisis de tráfico y, en nuestro caso, para que el hipervisor anidado pueda ver el tráfico de sus VMs internas.
Al activar el modo promiscuo en un vSwitch o en un port group, el comportamiento se asemeja más al de un hub: se reenvía todo el tráfico a esa interfaz. Esto facilita que el ESXi virtual aprenda y gestione las MAC de las VMs anidadas, pero a cambio reduce el rendimiento de red, algo que se nota especialmente si las cargas son muy intensivas en tráfico.
Cambios de MAC y transmisiones falsificadas
Por defecto, un vSwitch estándar en ESXi no permite que una VM cambie su dirección MAC respecto a la configurada en el fichero VMX, como medida de seguridad frente a ataques de envenenamiento ARP y suplantación de identidad. De igual forma, se bloquean las tramas salientes cuyo campo MAC de origen no coincide con la dirección MAC efectiva de la VM, considerándolas transmisiones falsificadas (Forged Transmits).
En un escenario anidado, las VMs internas suelen tener MAC diferentes a la del ESXi invitado. Si no se ajustan estas políticas a Aceptar, el switch virtual del host físico considerará que las tramas que salen del ESXi virtual con MAC distintas son sospechosas y las descartará, rompiendo la conectividad de las VMs anidadas con el resto de la red.
A partir de vSphere 6.7, los Distributed Virtual Switch (VDS) incorporan opciones de aprendizaje de direcciones MAC mediante la opción macManagementPolicy, lo que permite reducir la necesidad de tirar del modo promiscuo y ofrecer un comportamiento más parecido al de un switch físico tradicional en entornos anidados.
Pasos clave para montar un entorno ESXi anidado
Si lo llevamos a la práctica, el despliegue típico de un entorno ESXi anidado sobre un host ESXi físico pasa por una serie de pasos relativamente estándar, aunque con algunos matices críticos para que todo funcione bien.
En primer lugar, se crea una máquina virtual que actuará como host ESXi. En el asistente se elige un nivel de compatibilidad de hardware adecuado (por ejemplo, ESXi 6.5 o posterior), se selecciona como sistema operativo invitado “VMware ESXi” y, en la parte de hardware, se asignan al menos 2 vCPU, 8 GB de RAM o más y un disco virtual suficiente (mínimo 32 GB para ESXi 7.x, aunque es preferible dar más).
El punto clave es marcar la opción de exponer virtualización asistida por hardware al sistema operativo invitado. Si no se hace, durante la instalación de ESXi en la VM aparecerá un aviso indicando que la virtualización por hardware no está soportada o no está activada en la CPU, y no será posible arrancar VMs anidadas dentro de ese ESXi virtual.
Una vez creada la VM, se monta la imagen ISO de instalación de ESXi desde un datastore y se procede a instalar el hipervisor en esa máquina virtual como si fuera un servidor físico: se formatea el disco, se configura la red de gestión con una IP y nombre de host y se comprueba que se puede acceder al VMware Host Client vía navegador.
Almacenamiento y datastores en ESXi anidado
Con ESXi 7.x, el esquema de particionado ha cambiado frente a versiones anteriores. En discos pequeños (por debajo de 128 GB) se crea una partición VMFSL destinada a datos del propio sistema (coredump, herramientas, scratch, etc.) y puede que no quede espacio para crear un datastore VMFS adicional donde alojar VMs anidadas.
Por eso es muy habitual añadir uno o varios discos virtuales adicionales a la VM ESXi invitada, apagando primero la máquina, editando sus ajustes y creando nuevos discos con aprovisionamiento fino (por ejemplo de 30 GB, 50 GB o más según necesidades). Después, desde el Host Client del ESXi anidado se detecta ese nuevo disco y se crea un datastore VMFS (normalmente VMFS 6) para almacenar las VMs internas.
Montaje de ISOs y creación de VMs anidadas
Para instalar sistemas operativos en las VMs anidadas dentro del ESXi invitado, se puede optar por dos enfoques principales a la hora de usar las imágenes ISO de instalación:
Por un lado, subir las ISOs directamente al datastore del ESXi anidado y seleccionarlas desde ahí al crear las VMs internas. Este enfoque es simple pero consume espacio de almacenamiento dentro del propio entorno anidado. Por otro lado, montar la ISO en la unidad de CD/DVD de la VM ESXi invitada desde un datastore del host físico y, dentro del ESXi virtual, configurar la unidad de CD/DVD de la VM anidada como “Dispositivo host”, aprovechando el passthrough.
Este segundo método suele ser preferible porque permite centralizar las ISOs en un único datastore en el host físico, ahorra espacio en el datastore del ESXi invitado y proporciona un ligero mejor rendimiento de acceso a medios. Una vez montada la ISO, el proceso de creación de la VM anidada es similar al de cualquier otra VM: se define nombre, tipo de sistema operativo invitado (Windows, Linux, etc.), recursos (CPU, RAM, disco) y se arranca la instalación.
Tras instalar el sistema operativo en la VM anidada, es crucial añadir VMware Tools dentro de esa VM para optimizar rendimiento de red, vídeo y operaciones de apagado y reinicio. Dependiendo de la distribución de ESXi utilizada, las imágenes ISO de las tools pueden venir integradas o ser necesario descargarlas desde el portal de VMware.
Clonado y replicación de hosts ESXi anidados
Una vez que se ha configurado un ESXi anidado con la versión deseada, red, datastore y alguna VM interna, lo normal es querer clonar esa VM para disponer de varios hosts ESXi virtuales idénticos, por ejemplo para formar un clúster de laboratorio con vCenter.
Antes de empezar a clonar, conviene realizar algunos ajustes dentro del ESXi invitado original: habilitar que el VMkernel siga la MAC del hardware virtual con el parámetro adecuado en ESXCLI, y eliminar el UUID del sistema del fichero /etc/vmware/esx.conf para que, al arrancar el clon, se genere un nuevo identificador único. Después de clonar, al encender cada ESXi virtual será necesario cambiarle nombre de host, IPs y cualquier otra configuración que deba ser distinta.
Virtualización anidada en Azure Lab Services (Hyper-V)
Azure Lab Services ofrece una forma muy cómoda de entregar laboratorios completos a estudiantes o usuarios internos mediante máquinas virtuales de laboratorio. Aquí la virtualización anidada se apoya en Hyper-V como hipervisor dentro de la VM de plantilla. La idea es que desde esa VM de plantilla se habilitan las características de Hyper-V, se crean las VMs anidadas necesarias y, al publicar el laboratorio, cada usuario recibe su propia copia de esa plantilla con todo ya montado.
En este escenario, la virtualización anidada solo está disponible en VMs de laboratorio basadas en Windows, aunque dentro de Hyper-V se pueden ejecutar tanto invitados Windows como Linux. Si el sistema operativo de la plantilla es Windows Server, suele ser necesario configurar una red NAT dentro de la VM de laboratorio para que las VMs anidadas puedan comunicarse entre sí y salir a Internet.
Al configurar estos laboratorios, hay que tener en cuenta varios aspectos prácticos: si se crean cuentas de usuario sin privilegios de administrador, es imprescindible añadirlas al grupo “Administradores de Hyper-V” para que puedan iniciar y detener VMs. Además, las VHDX de las VMs anidadas deben estar en rutas accesibles para ese usuario y, para ahorrar espacio en disco, se recomienda utilizar el formato VHDX dinámico en lugar de discos planos grandes.
En cuanto a la capacidad de cómputo, los tamaños de VM pensados para virtualización anidada en Azure (por ejemplo, Standard_D4s_v4 y Standard_D8s_v4) se basan en procesadores Intel Xeon Platinum de tercera generación. Dado que al detener y encender VMs en Azure el procesador subyacente puede variar dentro de la misma familia, se aconseja habilitar el modo de compatibilidad de procesador en las VMs anidadas de Hyper-V para minimizar problemas de migración entre distintos hosts físicos.
Otro punto crítico es configurar las VMs de Hyper-V para que se apaguen de forma ordenada cuando la VM de laboratorio se apaga, normalmente usando el cmdlet Set-VM para definir la acción de detención automática y evitar corrupción de datos. Y, como siempre, hay que planificar bien memoria y número de vCPU por VM anidada para que el rendimiento general sea aceptable.
Hay también limitaciones importantes: no todos los tamaños de VM de Azure soportan virtualización anidada, las VMs anidadas no tienen acceso directo a recursos de Azure como los DNS de la VNet y solo se soporta Hyper-V como tecnología de virtualización, quedando fuera del soporte otras soluciones que requieran extensiones de hardware como KVM o VMware dentro de esa capa.
Virtualización anidada en AWS EC2
Hasta hace poco, si querías virtualización anidada en AWS estabas prácticamente obligado a irte a instancias bare metal, con acceso directo al hardware pero a un coste muy superior y con menos flexibilidad. El anuncio de soporte oficial de virtualización anidada en instancias EC2 virtuales estándar ha cambiado el panorama por completo.
La actualización, reflejada por ejemplo en versiones recientes del SDK de AWS para Go, habilita la posibilidad de ejecutar hipervisores invitados y VMs anidadas dentro de instancias EC2 que no son bare metal, siempre que pertenezcan a familias compatibles (normalmente instancias con CPUs Intel VT-x o AMD-V de las series M, C, R, etc.). Esto abre la puerta a que startups y equipos de desarrollo monten laboratorios complejos, plataformas de CI/CD avanzadas o entornos de orquestación de VMs sin salirse del presupuesto.
En este contexto, los casos de uso más frecuentes incluyen pipelines de testing que reproducen arquitecturas de producción completas (diferentes sistemas operativos, capas de red, firewalls, etc.), plataformas de formación técnica que dan a cada alumno un mini CPD dentro de una EC2 o el desarrollo de herramientas cloud-native que necesitan gestionar VMs como parte de su funcionalidad (por ejemplo, soluciones de backup, seguridad o automatización).
Desde el punto de vista económico, el soporte de virtualización anidada en EC2 estándar puede suponer reducciones importantes de coste frente a bare metal, del orden del 60-70 % en muchos escenarios de laboratorio. Además, se gana en elasticidad: se pueden combinar instancias bajo demanda con Spot, escalar hacia arriba o abajo según las necesidades de prueba y aprovisionar entornos en segundos frente a los tiempos habituales de bare metal.
No obstante, también aquí hay que tener presente que cada capa de virtualización añade overhead. Las VMs anidadas en EC2 tienden a sufrir una penalización de rendimiento de entre un 10-20 % frente a una VM no anidada equivalente, por lo que su lugar natural son los entornos de desarrollo, pruebas, PoC y labs, mientras que para producción crítica conviene evaluar con calma si compensa esa pérdida de rendimiento.
Para el ecosistema de startups en Latinoamérica y otros mercados sensibles al coste de la nube, esta posibilidad es especialmente relevante: empresas de ciberseguridad pueden montar laboratorios de malware multicapas en la nube sin pagar bare metal, equipos de DevOps pueden replicar topologías de producción en staging con un coste contenido y proveedores SaaS pueden preparar demos complejas para clientes con arquitecturas reales sin desplegar hardware físico.
Por último, la integración con el SDK de AWS para Go y otras SDKs permite automatizar la gestión de estos entornos anidados, incluyendo la verificación de compatibilidad de instancias, la activación de capacidades de virtualización y la orquestación del ciclo de vida de las VMs dentro de las EC2 a través de pipelines de Infrastructure as Code.
La virtualización anidada se ha consolidado como una herramienta muy versátil para laboratorizar, probar y enseñar infraestructuras complejas sin necesidad de grandes inversiones en hardware. Desde escenarios de formación con ESXi anidado y laboratorios Hyper-V en Azure hasta plataformas de testing avanzadas en AWS EC2, el patrón se repite: un uso inteligente de esta tecnología permite ganar flexibilidad, reducir costes y acelerar el ciclo de pruebas, siempre que se respeten sus límites en rendimiento, soporte y licenciamiento y se planifiquen bien redes, seguridad y recursos.
