¿Hyper-V o VirtualBox para un PC doméstico? Comparativa a fondo

Si te estás planteando montar un pequeño laboratorio casero en tu PC con Windows 11 Pro y no tienes claro si tirar de Hyper-V, VirtualBox o incluso mirar VMware, no eres el único. Con un portátil gaming con 32 GB de RAM, ganas de trastear con Kali Linux y otras distros, y la necesidad de hacer snapshots para romper cosas sin miedo, la elección del hipervisor importa más de lo que parece.

A lo largo de este artículo vamos a desgranar, con calma pero sin rodeos, qué ofrece el hipervisor nativo de Windows frente a VirtualBox (y dónde encaja VMware) cuando el escenario es un PC doméstico o de usuario avanzado. Verás conceptos como tipo de hipervisor, rendimiento, redes virtuales, compatibilidad de sistemas invitados, snapshots, cifrado, migración y más, siempre con el foco en lo que te interesa para un laboratorio en casa y no solo en entornos empresariales.

Hipervisor tipo 1 vs tipo 2: qué implica en tu PC de casa

Lo primero es entender la diferencia entre hipervisor de tipo 1 y de tipo 2, porque de ahí salen muchos de los pros y contras de Hyper-V y VirtualBox.

Hyper-V es un hipervisor de tipo 1 (bare metal o nativo). Eso significa que, en cuanto arranca el equipo, el control del hardware pasa primero por el hipervisor y después se levanta Windows como un sistema operativo de administración más, en vez de ser «el dueño absoluto» de la máquina. Técnicamente, cuando Hyper-V está activo, tu propio Windows 11 se ejecuta ya como una máquina sobre ese hipervisor.

VirtualBox, en cambio, es un hipervisor de tipo 2 o alojado. Funciona como una aplicación más instalada sobre Windows, Linux, macOS o Solaris: arranca primero el sistema operativo host, y luego tú abres VirtualBox y lanzas las máquinas virtuales como procesos de usuario que piden CPU, RAM y E/S al sistema.

Requisitos, ediciones de Windows y activación de Hyper-V

Para poder usar Hyper-V necesitas Windows 10/11 Pro, Enterprise o Education. En Home no está soportado oficialmente, aunque sí existe parte de la infraestructura subyacente que puede activarse de forma parcial y dar problemas a VirtualBox.

Hyper-V se instala como característica opcional de Windows: desde «Activar o desactivar características de Windows» o mediante PowerShell y DISM. Una vez habilitado y reiniciado el equipo, el hipervisor pasa a cargarse en el arranque. Windows Sandbox y WSL2 también tiran del mismo hipervisor de bajo nivel.

En una máquina doméstica esto implica algo que mucha gente pasa por alto: si Hyper-V está activo al arrancar, todo lo que use VT‑x/AMD‑V pasa a depender de él. VirtualBox y VMware Workstation ya no pueden usar la virtualización de hardware directamente y tienen que hacer malabares con el modo compatible con Hyper-V, que aún hoy da bastantes quebraderos de cabeza y penaliza rendimiento.

Cómo afecta Hyper-V a VirtualBox (y cómo convivir con ambos)

Si intentas arrancar una VM de 64 bits en VirtualBox con Hyper-V activado, es muy probable que veas en el log mensajes tipo «Attempting fall back to NEM: VT-x/AMD-V is not available» y que aparezca el icono de la tortuga verde en la barra de estado de VirtualBox. Eso significa que la VM está corriendo sobre el motor de compatibilidad con Hyper-V, no sobre la virtualización de hardware directa.

Este modo alternativo funciona, pero va mucho más lento y puede provocar bloqueos o errores en la instalación de sistemas operativos, sobre todo en invitados exigentes. Para que VirtualBox vaya realmente fino en un PC doméstico, lo ideal es que Hyper-V esté desactivado por completo a nivel de arranque.

La gestión se hace con bcdedit y, en su caso, con DISM:

Para apagar Hyper-V: bcdedit /set hypervisorlaunchtype off
Y, si hace falta, desactivar la característica: DISM /Online /Disable-Feature:Microsoft-Hyper-V
Para volver a activarlo: bcdedit /set hypervisorlaunchtype auto

Cada vez que cambias ese parámetro, necesitas reiniciar el equipo, porque el hipervisor se decide antes de cargar Windows. No hay forma «en caliente» de pasar de Hyper-V a VirtualBox usando VT‑x/AMD‑V nativamente sin reinicio.

En la práctica, en un entorno doméstico razonable, tienes tres opciones:

Vivir solo con Hyper-V y renunciar a VirtualBox/VMware (o asumir el modo lento).
Vivir solo con VirtualBox (desactivar Hyper-V y todo lo que tire de él: WSL2, Sandbox, Docker Desktop…) para exprimir la virtualización de hardware.
Ir alternando según necesites Hyper-V o VirtualBox, cambiando el hypervisorlaunchtype y reiniciando. Es tedioso, pero se puede.

Cómo forzar solo las actualizaciones que necesitas en Windows 11 sin riesgos

Virtualización de hardware y software: quién soporta qué

Tanto Hyper-V como VirtualBox son capaces de usar virtualización asistida por hardware (Intel VT‑x, AMD‑V), siempre que esté activada en BIOS/UEFI. Esa es la base para ejecutar invitados de 64 bits con un rendimiento aceptable.

La diferencia interesante es que VirtualBox también puede usar virtualización por software (emulación) para invitados de 32 bits en arquitecturas x86 cuando el procesador no soporta VT‑x/AMD‑V. Esto hoy en día importa menos, pero si reaprovechas un equipo muy viejo, VirtualBox puede levantar VMs donde Hyper-V ni arranca.

En Linux puedes comprobar si tu CPU soporta estas extensiones buscando vmx (Intel) o svm (AMD) en /proc/cpuinfo, y validar requisitos con utilidades como virt-host-validate. En Windows, basta con revisar en el Administrador de tareas o con herramientas como systeminfo o Coreinfo.

Sistemas operativos host y guest: dónde gana cada uno

En un laboratorio doméstico con un portátil gaming, lo normal es tener Windows 11 Pro como host. Ahí Hyper-V puede correr sin problemas, pero solo en ese sistema operativo; no hay Hyper-V para Linux, macOS, etc.

VirtualBox, por contra, es multiplataforma: se instala en Windows, Linux, macOS, Solaris y FreeBSD. Eso te permite, por ejemplo, mover tus VMs a otro host con un SO distinto sin cambiar de herramienta, lo cual es muy cómodo si un día decides montar un mini-servidor con Linux en vez de seguir usando tu portátil como host.

En cuanto a SO invitados:

Hyper-V soporta Windows, muchas distribuciones Linux y FreeBSD. Cada versión de Windows Server/documentación de Hyper-V especifica las distros y versiones soportadas oficialmente.
VirtualBox tiene una lista más larga: Windows de casi todas las épocas, Linux, FreeBSD, Solaris, macOS (con muchas comillas legales), sistemas antiguos como DOS, OS/2, etc.

Si tu objetivo principal son Windows y distribuciones Linux modernas (incluyendo Kali), con Hyper-V vas sobrado en cuanto a compatibilidad. Si te apetece trastear con sistemas muy raros o muy viejos, VirtualBox suele comportarse mejor.

Rendimiento, gráficos 3D y consumo de recursos

En cuanto a rendimiento bruto, con el hardware que comentas (32 GB de RAM y un portátil gaming) ambos hipervisores son perfectamente válidos para 2-3 VMs simultáneas moderadas.

Hay varios matices a tener en cuenta:

VirtualBox suele ir algo por detrás de VMware Workstation en rendimiento puro y sobre todo en gráficos 3D, pero para un uso «de andar por casa» suele ser suficiente. En comparación con Hyper-V, el rendimiento depende mucho de la carga y de si Hyper-V está usando bien VT‑x/AMD‑V.
Hyper-V, al ser tipo 1, suele consumir algo menos de overhead en el host, sobre todo cuando tienes muchas VMs o cargas intensivas. Sin embargo, su integración gráfica con Linux puede ser más tosca (sesiones por VNC/RDP, soporte de 3D bastante básico en muchos casos).
VirtualBox soporta 3D limitado (OpenGL 3.0, Direct3D 9), con hasta 128 MB de VRAM virtual. Es suficiente para interfaces de escritorio fluidas y algo de aceleración, pero no esperes maravillas con aplicaciones 3D complejas.

Para un laboratorio de ciberseguridad con Kali, Windows y alguna otra VM, lo que de verdad manda es cómo repartes la RAM y los cores, y no tanto si usas Hyper-V o VirtualBox. Lo razonable con 32 GB es algo tipo:

Host: dejarle al menos 8-10 GB libres para que Windows no sufra.
Kali o distro principal de pruebas: 4-8 GB según herramientas.
Algún Windows invitado: 4-6 GB.
Alguna VM ligera (router, servidor pequeño): 1-2 GB.

Formatos de disco virtual y tipos de aprovisionamiento

Hyper-V trabaja con VHD y VHDX. VHDX es el formato moderno (desde Windows Server 2012), más robusto, con soporte de discos grandes y mejor tolerancia a cortes. VirtualBox soporta VDI (nativo), VMDK (VMware), VHD y HDD de Parallels, pero no puede manejar VHDX directamente.

Tanto Hyper-V como VirtualBox permiten crear discos de tamaño fijo (thick) o de tamaño dinámico (thin):

Un disco fijo reserva todo el espacio desde el principio (por ejemplo, 40 GB en el host si creas un disco de 40 GB), tarda más en crearse, pero suele dar algo más de rendimiento y menos fragmentación.
Un disco dinámico crece según escribes datos (arranca ocupando poco y se va inflando hasta su máximo posible). Es comodísimo para un laboratorio doméstico donde quieres ahorrar espacio, a costa de un pequeño coste en rendimiento.

En un PC doméstico con SSD grande, lo habitual es usar discos dinámicos para casi todo y, si una VM va a ser muy intensiva en E/S (por ejemplo, una base de datos gordita), valorar disco fijo para esa VM concreta.

Snapshots, puntos de control e instantáneas

Para tu escenario (ciberseguridad, romper cosas, deshacer cambios) la función clave es poder guardar el estado de una VM y volver atrás cuando algo sale mal.

Hyper-V ofrece puntos de control (checkpoints) con dos sabores:

Estándar: capturan estado de memoria y disco tal cual; útiles para pruebas rápidas, pero con riesgo de inconsistencia en aplicaciones que escriben mucho en disco.
De producción: usan VSS en Windows o congelación de sistema de archivos en Linux para dejar la VM en un estado consistente a nivel de aplicación mientras se hace el punto de control. Son más «limpios» para máquinas que corren servicios.

Fondos dinámicos de Spotlight y automatización avanzada con PowerShell

VirtualBox tiene instantáneas que funcionan de forma muy parecida a los checkpoints estándar: cuando creas una snapshot, se genera un disco diferencial y todos los cambios posteriores se escriben ahí. Si eliminas una snapshot, VirtualBox fusiona el disco diferencial con el principal.

En ambos casos, las snapshots son herramientas fantásticas para laboratorio, pero no deben considerarse copias de seguridad definitivas. Tener muchas instantáneas encadenadas también puede penalizar el rendimiento y complicar la gestión del almacenamiento.

Integración entre host e invitado: carpetas compartidas, portapapeles y drag & drop

Para trabajar cómodo, es fundamental poder pasar ficheros y texto entre el host y las VMs sin estar montando un servidor FTP a cada rato.

VirtualBox incorpora de serie:

Carpetas compartidas: las configuras en la VM, eliges una ruta del host (por ejemplo, C:\temp) y se monta en el invitado como un recurso compartido. Requiere tener instaladas las Guest Additions.
Portapapeles compartido y drag & drop: puedes copiar/pegar texto y arrastrar ficheros en una o ambas direcciones (host→guest, guest→host o bidireccional), según configures.

Hyper-V, en cambio, no tiene una función de «carpetas compartidas» tan directa. Lo habitual es:

Compartir una carpeta en el host con las herramientas normales de Windows y acceder desde la VM por red (SMB) con las credenciales adecuadas.
Usar Copy-VMFile en PowerShell para copiar archivos hacia/desde la VM (sobre todo en entornos automatizados).

Para portapapeles y drag & drop, Hyper-V se apoya en el modo de sesión mejorada (Enhanced Session Mode) y los servicios de integración instalados en el invitado. Una vez configurado, puedes redirigir portapapeles, unidades, audio, USB, etc., de forma parecida a una sesión RDP avanzada.

Gestión y acceso a las VMs: GUI, consola y acceso remoto

En un PC doméstico cuenta mucho lo fácil que es crear, arrancar y toquetear máquinas virtuales sin morir en la consola.

Hyper-V se gestiona principalmente con:

Hyper-V Manager: GUI con la que creas, importas, configuras, arrancas, paras y borras VMs, además de gestionar switches virtuales, discos, checkpoints, etc. También te puedes conectar a hosts remotos.
VMConnect: cliente de consola para acceder a la interfaz gráfica o consola de la VM, usando WMI y RDP por debajo. Con sesión mejorada puedes redirigir dispositivos locales.
PowerShell: imprescindible si quieres automatizar algo serio o manejar varios hosts. Para un laboratorio casero, te basta con aprender unos cuantos cmdlets básicos (New-VM, Set-VM, Start-VM, Checkpoint-VM…).

VirtualBox, por su parte, ofrece:

VirtualBox Manager (GUI): interfaz muy directa, excelente para un usuario doméstico que quiere ver sus VMs en una lista, arrancar, apagar y cambiar cuatro parámetros sin complicarse.
VBoxManage (CLI): comando súper potente para scripting, con el que puedes hacer prácticamente todo lo que permite la GUI y más.
phpVirtualBox: interfaz web en PHP que clona bastante bien la GUI oficial y que viene de lujo si tienes VirtualBox en un servidor sin entorno gráfico.
VRDE/VRDP: extensión de escritorio remoto compatible con RDP de Microsoft que te permite conectarte a las VMs de VirtualBox desde cualquier cliente RDP estándar, incluso aunque la VM no tenga un servidor RDP propio dentro.

Redes virtuales: que tus VMs se hablen entre ellas (y con el exterior)

Para un laboratorio con Kali y otras VMs, es clave poder montar topologías de red sencillas: que ciertas máquinas solo se vean entre ellas, que otras tengan salida a Internet, etc.

VirtualBox ofrece varios modos de red muy flexibles:

NAT: la VM sale a Internet a través del host, pero desde fuera no se puede acceder a ella salvo que configures reenvío de puertos.
Red NAT: similar al NAT, pero las VMs dentro de esa red NAT se ven entre sí directamente, ideal para mini-laboratorios internos.
Adaptador puenteado: la VM aparece en la LAN física como un equipo más; perfecta para que Kali escanee la red «real».
Red interna: las VMs solo se ven entre ellas, sin acceso a host ni a LAN externa.
Solo-anfitrión: las VMs se ven entre sí y con el host, pero no con la LAN externa.

Hyper-V utiliza switches virtuales que cumplan funciones parecidas:

Externos: conectados a una NIC física; las VMs salen a la LAN/Internet directamente, como si fueran equipos físicos.
Internos: conectan VMs entre sí y con el host, pero no con el exterior.
Privados: solo conectan VMs entre sí, sin ni siquiera el host.

Para lo que quieres (Kali atacando otras VMs, todas comunicándose, y de vez en cuando algo con salida a Internet), cualquiera de los dos es suficiente. VirtualBox suele resultar más intuitivo al principio por sus modos NAT/puenteados preconfigurados; Hyper-V brilla más cuando montas cosas complejas con varios hosts.

Memoria, overcommit y ballooning

Con 32 GB no deberías ir muy justo, pero aun así conviene entender cómo trata cada hipervisor la memoria física cuando hay muchas VMs.

Tanto Hyper-V como VirtualBox soportan ballooning, una técnica que permite que el hipervisor recupere memoria no usada de algunas VMs para dársela a otras más necesitadas. En VirtualBox se configura con VBoxManage y requiere Guest Additions; en Hyper-V necesitas los servicios de integración y, en general, se controla a nivel de asignación dinámica de memoria.

Cómo mantener Windows 11 seguro: consejos y configuración pro

En un entorno doméstico pequeño, salvo que empieces a sobreasignar memoria agresivamente (más RAM «virtual» sumada que la RAM física disponible), esta parte no debería preocuparte demasiado, pero es útil saber que existe si un día quieres apurar más el hardware.

Snapshots, cifrado y seguridad de las VMs

Además de las instantáneas, muchos hipervisores permiten cifrar los discos virtuales para protegerlos si alguien roba o accede al host.

VirtualBox puede cifrar discos de VM con XTS‑AES‑256 o XTS‑AES‑128, pero requiere tener instalado el Extension Pack (que para uso personal es gratuito, pero no es de código abierto). El cifrado se configura en las opciones de la VM: eliges algoritmo, pones contraseña y de ahí en adelante cada arranque de la VM te la pedirá.

Hyper-V no tiene un «cifrado de VM» tan directo en la edición de escritorio como en vSphere, pero en entornos profesionales la combinación típica es cifrar el almacenamiento subyacente con BitLocker para proteger los ficheros VHD/VHDX. En Windows Server y vSphere existen opciones más granuladas de cifrado de VMs, pero eso ya se sale de un laboratorio doméstico típico.

Migración en vivo y teletransporte: utilidades en casa

Hyper-V puede hacer Live Migration de VMs entre hosts cuando tienes un clúster con almacenamiento compartido; VMware ESXi hace lo mismo con vMotion; VirtualBox ofrece algo parecido llamado Teleporting, que mueve una VM en ejecución de un host VirtualBox a otro usando TCP/IP y un almacenamiento compartido.

En un PC doméstico con un único portátil, todo esto es prescindible. Son funciones pensadas para alta disponibilidad y balanceo de carga en datacenters. VirtualBox Teleporting puede ser curioso si montas dos equipos en red con el mismo almacenamiento (iSCSI, NFS, SMB), pero no es algo que vaya a marcar tu elección para practicar ciberseguridad en casa.

¿Y VMware Workstation dónde entra en todo esto?

VMware Workstation (Player o Pro) es el otro gran nombre. Es un hipervisor de tipo 2 como VirtualBox, pero con más pulido y mejor soporte de gráficos 3D y ciertas integraciones avanzadas (vSphere, etc.).

Sus puntos fuertes en un PC doméstico son:

Rendimiento muy fluido y mejor soporte de gráficos 3D que VirtualBox.
Integración fina con el host (carpetas compartidas, drag & drop, modo Unity para mezclar ventanas de la VM con las del host).
Soporte excelente para Windows y muchas distros Linux.

Los puntos flojos desde la óptica de un laboratorio casero son claros: la versión Pro es de pago y no precisamente barata, y aunque Player es gratuita para uso personal, viene recortada (por ejemplo, sin snapshots). Además, la interfaz y opciones pueden abrumar a quien solo quiere unas pocas VMs para pruebas.

Para un entorno casero centrado en aprender ciberseguridad y romper cosas sin miedo, VirtualBox suele ser más que suficiente. VMware brilla más cuando quieres rendimiento muy fino y te merece la pena pagar por la licencia Pro.

Ventajas e inconvenientes de cada opción en un PC doméstico

Resumiendo lo más práctico para un PC de casa con Windows 11 Pro y 32 GB de RAM:

Hyper-V te interesa si:

Vas a usar mucho WSL2, Windows Sandbox o Docker Desktop, que dependen del hipervisor de Microsoft.
Quieres un entorno lo más parecido posible a uno empresarial basado en Windows.
Te atrae la idea de usar discos físicos directamente para arrancar VMs o incluso aprovechar características avanzadas de Windows Server (cluster, etc.) a medio plazo.

VirtualBox te interesa si:

Buscas algo gratuito, sencillo y multiplataforma que conozcas de hace años.
Quieres poder mover tus VMs entre distintos sistemas operativos host (por ejemplo, hoy Windows, mañana Linux).
Vas a trastear con muchos sistemas distintos, incluyendo viejos o «raros», y necesitas flexibilidad máxima.
Prefieres una GUI muy clara, con instantáneas y modos de red fáciles de entender para laboratorio.

VMware Workstation entra en juego si:

Buscas máximo rendimiento y estabilidad en un hipervisor de tipo 2.
No te importa pagar la licencia Pro para tener snapshots, clones enlazados y resto de funciones avanzadas.
Quieres una excelente experiencia con Windows y Linux invitados, incluyendo gráficos 3D más decentes que en VirtualBox.

En tu caso concreto (laboratorio casero, 2-3 VMs, foco en Kali y comunicación entre VMs), la opción más razonable suele ser usar VirtualBox como herramienta principal si no necesitas WSL2/Docker Sandbox todo el día, y activar Hyper-V solo cuando realmente quieras jugar con esas características, asumiendo el reinicio de rigor para alternar.