La virtualización anidada se ha convertido en una de esas funciones “ocultas” que, cuando la descubres, te abre un mundo de posibilidades para montar laboratorios, hacer pruebas de versiones, simular entornos de producción o incluso dar formación sin gastarte una fortuna en hardware. En lugar de tener un montón de servidores físicos, puedes ejecutar hipervisores completos dentro de máquinas virtuales y, a su vez, crear más máquinas virtuales dentro de ellas. Sí, suena muy meta, pero es tremendamente útil.
En las últimas generaciones de hipervisores de VMware y Microsoft Hyper-V, así como en otros productos de virtualización, la virtualización anidada ya no es un experimento raro, sino una opción disponible (aunque muchas veces no soportada oficialmente en producción). Vamos a ver qué es exactamente, qué requisitos tiene, cómo se configura sobre todo en VMware y Hyper‑V, qué implicaciones de rendimiento y red conlleva, y sobre todo, qué casos de uso reales tiene en el día a día de administradores, desarrolladores y equipos de formación.
Qué es exactamente la virtualización anidada
Cuando hablamos de virtualización anidada nos referimos a ejecutar un hipervisor dentro de una máquina virtual que ya corre sobre otro hipervisor. Ese primer hipervisor que está instalado sobre el servidor físico se suele llamar hipervisor de host. El que se ejecuta dentro de la VM, por su parte, se conoce como hipervisor invitado o hipervisor virtual.
En este escenario, la máquina virtual que aloja al hipervisor invitado actúa como “huésped externo” (en terminología de VMware), y las máquinas virtuales que arrancan dentro de ese hipervisor invitado se consideran “huéspedes internos” o VMs anidadas. Desde el punto de vista del hipervisor invitado, el hardware virtual que le presenta la VM se comporta como si fuera hardware físico real, con su CPU, memoria, almacenamiento y red.
Es posible llegar a más de dos niveles de anidamiento, siempre que el hardware físico lo aguante. Sin embargo, cada nivel extra introduce más sobrecarga. Así que en la práctica lo habitual es usar uno o, como mucho, dos niveles de anidamiento para que la experiencia no sea desesperante.
Para que todo esto funcione de forma eficiente, se apoya en la virtualización asistida por hardware (Intel VT‑x, Extended Page Tables / EPT, AMD‑V, etc.). Es decir, extensiones del procesador pensadas justamente para ofrecer soporte nativo a hipervisores. Estas funciones permiten que el hipervisor gestione el cambio de contexto entre VMs y el manejo de memoria de forma mucho más rápida que con técnicas antiguas como la traducción binaria o la paravirtualización pura.
Tipos de hipervisores y requisitos básicos
La virtualización anidada puede funcionar tanto con hipervisores de tipo 1 (bare metal, instalados directamente sobre el hardware) como con hipervisores de tipo 2 (instalados encima de un sistema operativo convencional). En el ecosistema VMware, ESXi es un hipervisor de tipo 1. VMware Workstation, VMware Player y VMware Fusion se consideran de tipo 2.
Para poder activar la virtualización anidada, el hipervisor de host debe ser capaz de “re-exponer” las extensiones de virtualización de hardware (HV virtualizada) a la máquina virtual que vaya a alojar el hipervisor invitado. Esto significa que, dentro de la configuración de la VM, debe existir una opción que permita exponer VT‑x / AMD‑V.
- En el caso de VMware, la virtualización asistida por hardware y la HV virtualizada están soportadas en hipervisores de tipo 2 desde VMware Workstation 8, VMware Player 4 y VMware Fusion 4.
- En Hyper‑V, la historia es similar. Los procesadores deben disponer de VT‑x y EPT (o equivalentes AMD), y Hyper‑V se encarga de exponer estas capacidades a las VMs para que dentro de ellas se pueda volver a habilitar Hyper‑V u otro motor compatible.
Compatibilidad y soporte en VMware
Aunque a nivel técnico la virtualización anidada funciona en las líneas principales de productos VMware (ESXi, Workstation, Player, Fusion), el fabricante es bastante claro en cuanto al soporte. No se considera un escenario soportado oficialmente para producción. Es decir, si montas un entorno de producción basándote en VMs anidadas y tienes problemas, VMware puede negarse a darte soporte.
Hay una excepción muy concreta: el uso de vSAN Witness Appliance en VMware vSphere. Este appliance se basa en un ESXi anidado y sí está aprobado y soportado por VMware, ya que forma parte de la propia arquitectura de vSAN para determinados despliegues.
Por otro lado, VMware sí admite habilitar Hyper‑V dentro de máquinas virtuales Windows para seguridad basada en virtualización (VBS, Virtualization‑Based Security) a partir de vSphere 6.7. VBS es una característica de Windows 10 y Windows Server 2016 en adelante que aprovecha la virtualización para crear entornos aislados donde alojar funciones de seguridad sensibles.
Licenciamiento de entornos anidados en VMware
Es importante no caer en el error de pensar que, por estar en VMs, todo es “gratis”. Si despliegas ESXi y otros componentes de vSphere (como vCenter) en máquinas virtuales dentro de un entorno anidado, debes licenciar esos componentes igual que si estuvieran instalados en servidores físicos. Independientemente de si el hipervisor de host es VMware u otro proveedor.
Lo que sí puedes hacer, si estás probando o montando un laboratorio, es aprovechar las ediciones gratuitas o las versiones de evaluación de ESXi, vCenter y resto de productos vSphere, siempre respetando sus términos de uso. A nivel de configuración de CPU para evitar dolores de cabeza con las licencias por socket o por cores, tiene sentido asignar varios núcleos por CPU virtual en vez de muchas CPUs de un solo core, utilizando el parámetro cpuid.coresPerSocket de la máquina virtual.
Casos reales de uso de la virtualización anidada
La gran ventaja de la virtualización anidada es que te permite montar varios hipervisores virtuales con sus propias VMs dentro de un único host físico. Reduciendo costes de hardware y ganando una flexibilidad enorme. Esta capacidad se explota en numerosos escenarios prácticos del día a día.
En el ámbito de la formación, es un recurso fantástico para montar laboratorios. Puedes instalar ESXi dentro de VMs para enseñar vSphere sin tener que disponer de un rack de servidores reales. Con una máquina suficientemente potente, es posible crear un mini‑datacenter virtual con varios hosts ESXi virtuales, un almacenamiento compartido virtual y un vCenter Server anidado para practicar alta disponibilidad (HA), DRS, Storage DRS, vMotion, etc.
Además de permitir a estudiantes o técnicos curiosear sin miedo, la virtualización anidada facilita muchísimo la recuperación ante errores en los laboratorios. Si alguien rompe la configuración de un host ESXi virtual o de las VMs internas, basta con restaurar la VM ESXi desde una copia de seguridad a nivel de hipervisor. Herramientas de backup especializadas en vSphere permiten proteger tanto las VMs “huésped externo” como las VMs anidadas internas.
En desarrollo de software, equipos que construyen herramientas para vSphere o scripts contra sus APIs pueden probar sus aplicaciones directamente sobre servidores ESXi virtuales con VMs anidadas, sin tocar la infraestructura de producción.
Un último caso muy interesante es el de los proveedores de servicios gestionados y clouds públicas. Algunos aprovechan la virtualización anidada para alojar en su infraestructura distintos hipervisores de clientes. Ofreciendo una especie de “cloud dentro de otra cloud” para facilitar migraciones o mantener compatibilidad con herramientas existentes.
Rendimiento de las máquinas virtuales anidadas
En cuanto al rendimiento, hay que tener claro que una VM anidada siempre va a rendir peor que una VM “normal”. El motivo es que, en un host físico, cada VM se asocia con uno o varios procesos que consumen RAM y CPU. Cuando dentro de esa VM hay un ESXi o un Hyper‑V que, a su vez, lanza más VMs, estamos añadiendo otra capa de procesos y de gestión de contexto sobre los recursos físicos.
Cuantas más VMs y más niveles de anidamiento, más tiempo se consume en cambios de contexto de CPU y en programación de los recursos, lo que se traduce en mayor latencia y menos rendimiento efectivo. La magnitud de la degradación va a depender mucho de la potencia del hardware, del tipo de carga (CPU, disco, red) y de lo afinado que esté el entorno, pero no es raro ver diferencias muy notables frente a una VM del mismo tamaño que corra directamente en el host físico.
Por eso, la recomendación general es reservar la virtualización anidada para laboratorios, formación, pruebas y entornos donde el rendimiento no sea crítico. VMware, de hecho, no la soporta para producción salvo en el caso concreto de vSAN Witness Appliance, mientras que Microsoft sí la admite en algunos escenarios de producción para Hyper‑V (siempre con la recomendación de probar bien el comportamiento de las aplicaciones).
VMware Tools y gestión de ESXi anidado
Cuando instalas ESXi dentro de una máquina virtual, también necesitas VMware Tools en ese ESXi “virtual”. VMware Tools es el paquete de drivers y utilidades que mejora el rendimiento y la integración de la VM con el hipervisor (sincronización de tiempo, apagado ordenado, información de red, etc.).
En versiones antiguas (ESXi 5.x) las VMware Tools específicas para ESXi anidado se distribuían como un paquete VIB para instalación manual. Desde VMware vSphere 6.0 en adelante, las herramientas ya vienen integradas en ESXi, de forma que no es necesario instalarlas aparte cuando este se ejecuta como VM.
Gracias a VMware Tools, el hipervisor de host puede mostrar información detallada del ESXi anidado (IP, nombre de host, estado), realizar apagados o reinicios ordenados desde vSphere Client o mediante la API, y ejecutar scripts al cambiar el estado de energía del host virtual. Es posible comprobar el estado del servicio de Tools en un ESXi anidado con el comando:
/etc/init.d/vmtoolsd status
Configuración de red en entornos ESXi anidados
La red es uno de los puntos donde la virtualización anidada puede darte más quebraderos de cabeza si no conoces bien cómo funcionan las redes de nivel 2 y los switches virtuales. El problema típico: las VMs anidadas arrancan, pero no tienen conectividad hacia fuera del host ESXi virtual.
En un host ESXi físico, el switch virtual estándar o distribuido no aprende direcciones MAC mirando el tráfico como hace un switch físico, sino que se basa en la información de las VMs que gestiona el hipervisor. Por eso, si dentro de una de las VMs hay un ESXi con varias VMs anidadas cada una con su MAC, el vSwitch del ESXi físico no las “ve” como interfaces propias. Si no se ajustan ciertas políticas de seguridad, acaba descartando los paquetes.
Para que las VMs anidadas puedan comunicarse con el exterior, suele ser necesario habilitar en el vSwitch físico el modo promiscuo, los cambios de dirección MAC y las transmisiones falsificadas (Forged Transmits), al menos en el puerto o grupo de puertos donde está conectada la VM ESXi anidada. Por defecto, estas opciones suelen estar en estado «Rechazar» por motivos de seguridad.
El modo promiscuo permite que una interfaz conectada a ese grupo de puertos pueda recibir todo el tráfico que pasa por el switch virtual. Independientemente de la MAC de destino. Es imprescindible para que el ESXi virtual “vea” el tráfico destinado a las MACs de las VMs anidadas que están detrás de él. La contrapartida es que, al actuar el vSwitch casi como un hub, el rendimiento de red puede verse afectado en entornos con mucho tráfico.
El parámetro de cambio de dirección MAC protege ante ataques de suplantación. Normalmente se exige que la MAC efectiva de la VM coincida con la configurada en el fichero de la VM. Desactivarlo por defecto mejora la seguridad frente a envenenamientos ARP. Pero para que un ESXi virtual pueda “presentar” MACs distintas para sus VMs internas, hay que relajar esta política en el grupo de puertos correspondiente.
Cómo desplegar un ESXi anidado y una VM interna
Un ejemplo típico de uso consiste en desplegar un ESXi reciente como VM en un host ESXi físico ligeramente más antiguo. Y dentro de ese ESXi virtual crear una o varias máquinas virtuales de prueba, por ejemplo con Windows. El flujo de trabajo general sería algo así:
- Subir la ISO del instalador de ESXi al datastore del host físico, usando vSphere Client.
- Crear una nueva VM sobre el ESXi físico. Eligiendo la familia de SO “Otros” y la versión “VMware ESXi X.X o posterior”, y asignando los recursos adecuados.
- Marcar la opción de exponer la virtualización asistida por hardware al SO invitado. Esto se hace en la sección CPU. Si se deja desactivada, durante la instalación de ESXi aparecerá una advertencia indicando que la virtualización hardware no es una característica de la CPU o no está habilitada en BIOS. No se podrán arrancar VMs de 64 bits dentro de ese ESXi anidado.
- Tras completar el asistente, arrancar la VM ESXi e instalar el hipervisor igual que en un servidor físico. Configurando la IP de gestión, nombre de host y resto de parámetros iniciales.
- Revisar la configuración de red del host ESXi físico. Editando el vSwitch donde se conecta la VM ESXi anidada y activando modo promiscuo, cambios de MAC y transmisiones falsificadas en la política de seguridad.
- Proveer una ISO del sistema operativo invitado que se instalará en la VM anidada (Windows, Linux, etc.).
Finalmente, en el Host Client del ESXi virtual se crea una nueva VM, se selecciona la familia y versión de SO apropiadas, se ubican sus discos en el datastore anidado y se configura la unidad de CD/DVD para arrancar desde la ISO que hayamos montado.
Clonación de hosts ESXi anidados
Una vez que tienes un ESXi anidado bien configurado, con su red y su datastore, suele ser tentador clonarlo para desplegar varios hosts virtuales de forma rápida. Esto permite montar clústeres de vSphere completos con tan solo duplicar VMs en lugar de repetir instalaciones desde cero.
Antes de clonar, hay que tomar ciertas precauciones para que los clones no compartan identificadores críticos. Por ejemplo, es recomendable activar que el VMkernel siga la MAC de hardware como identificador usando ESXCLI con un comando del estilo:
esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1
Además, conviene editar el fichero /etc/vmware/esx.conf del ESXi origen y eliminar la línea que contiene el UUID del sistema (habitualmente bajo la clave /system/uuid). Así, al arrancar cada clon por primera vez, genere un identificador único. Tras apagar el ESXi original, se pueden realizar los clones. Y cuando arranquen, ajustar en cada uno las direcciones IP de gestión, los nombres de host y cualquier otro parámetro de red para evitar conflictos.
Virtualización anidada en Hyper‑V y escenarios soportados
En el mundo Microsoft, la virtualización anidada se refiere principalmente a ejecutar Hyper‑V dentro de una VM de Hyper‑V. El objetivo es muy similar al de VMware. La idea es disponer de entornos de laboratorio y prueba donde levantar un hipervisor completo y sus VMs sin requerir hardware adicional.
Los procesadores modernos ya incluían desde hace años VT‑x y EPT (en Intel) o AMD‑V y sus equivalentes de paginación anidada. Por eso muchos modelos anteriores a los Xeon v3 cumplen técnicamente los requisitos de CPU. De hecho, hay documentación oficial de Microsoft donde se indica que basta con disponer de VT‑x y EPT para poder usar virtualización anidada en Hyper‑V.
En cuanto a casos de uso, Microsoft detalla varios escenarios en los que se admite la virtualización anidada de Hyper‑V. Tanto en Azure como en instalaciones locales. Siempre y cuando también lo admitan los servicios y aplicaciones que se ejecuten encima.
También se soporta ejecutar contenedores aislados de Hyper‑V dentro de VMs de Hyper‑V. En este modo, cada contenedor corre en una micro‑VM, lo que introduce un nivel de hipervisor adicional (anidado) y por tanto una sobrecarga en el arranque del contenedor, almacenamiento, red y CPU. Aun así, Microsoft lo considera un escenario soportado para un nivel de virtualización anidada. Esto abre la puerta a arquitecturas de contenedores muy aisladas sobre VMs.
Otro caso interesante es el del Subsistema de Windows para Linux (WSL2) ejecutándose dentro de una VM Hyper‑V que, a su vez, corre sobre otro Hyper‑V. WSL2 utiliza tecnología de virtualización bajo el capó, así que cuando se activa dentro de una VM, se está haciendo uso de virtualización anidada. Este escenario también está soportado. Pensado sobre todo para desarrolladores que trabajan con Linux dentro de entornos virtualizados complejos.
Virtualización anidada y memoria dinámica en Hyper‑V
Un punto a tener en cuenta con Hyper‑V es que, cuando Hyper‑V está ejecutándose dentro de una VM, esa máquina virtual debe apagarse para poder ajustar su memoria asignada. Aunque la memoria dinámica esté habilitada en la VM, mientras el rol de Hyper‑V está activo dentro de ella, la cantidad de RAM efectiva no fluctúa.
Si se intenta cambiar la memoria de una VM sin memoria dinámica activada mientras Hyper‑V está corriendo en su interior, el ajuste tampoco surte efecto. Esta limitación aplica sólo mientras el hipervisor invitado está levantado. Algo a tener muy presente a la hora de planificar laboratorios anidados que vayan a cambiar de tamaño frecuentemente.
En todo caso, la activación de la virtualización anidada en sí no modifica por arte de magia el comportamiento de la memoria dinámica ni del redimensionado en caliente. Por eso conviene dimensionar con cierto margen las VMs que van a alojar Hyper‑V anidado. Para evitar tener que apagarlas continuamente sólo para ajustar recursos.
Con todo lo anterior, la virtualización anidada se consolida como una pieza clave para aprender, probar, migrar y desplegar tecnologías de virtualización modernas. Permitiendo reproducir entornos complejos sobre un número reducido de servidores físicos y ofreciendo una flexibilidad que, bien utilizada, compensa con creces la sobrecarga y las limitaciones de soporte que pueda implicar.
