- Windows en ARM combina emulación x86/x64 con soporte nativo ARM64, pero los drivers de kernel deben ser siempre ARM64 para habilitar escenarios de virtualización avanzados.
- En Linux puedes detectar fácilmente si estás en máquina física o virtual y qué hipervisor usas con herramientas como hostnamectl, systemd-detect-virt, virt-what o dmidecode.
- Soluciones como Xen, KVM, LXC y VirtualBox conviven en el ecosistema Linux y cada una ofrece un enfoque diferente de virtualización o aislamiento, también con pasos hacia ARM.
- En Mac con Apple Silicon, Windows 11 ARM vía Parallels ofrece hoy una vía práctica para usar aplicaciones y juegos de Windows mientras la virtualización ARM sigue madurando.
La virtualización se ha convertido en una pieza clave tanto en entornos domésticos como profesionales, y con la llegada de procesadores ARM a portátiles y servidores el panorama se ha complicado un poco: no vale con que el equipo sea potente, también tiene que ofrecer soporte de virtualización adecuado y, además, la arquitectura invitada debe encajar con la del host. Si trabajas con Windows sobre ARM o con distribuciones Linux modernas en ARM y quieres saber hasta qué punto puedes virtualizar, te interesa entender bien qué soporta cada sistema y cómo comprobarlo.
En este artículo vamos a juntar todo lo que necesitas para comprobar y aprovechar el soporte de virtualización en equipos ARM con Windows 11 y con Linux: desde la emulación x86/x64 que ofrece Windows en ARM hasta las opciones de hipervisores como Hyper-V, KVM y virt-manager, Xen, LXC o VirtualBox, pasando por cómo verificar si tu hardware soporta virtualización por hardware y qué comandos usar en Linux para descubrir en qué tipo de entorno virtual se está ejecutando tu máquina.
Windows en ARM: emulación x86/x64 y soporte nativo para ARM64
Los dispositivos Windows basados en ARM han dejado de ser rarezas y ya compiten de tú a tú con portátiles x86 tradicionales, sobre todo gracias a su bajo consumo, la autonomía brutal y la integración con NPUs (unidades de procesamiento neuronal) pensadas para cargas de IA y aprendizaje automático. Microsoft ha apostado fuerte por Windows en ARM, y eso incluye una capa de emulación para poder seguir utilizando aplicaciones heredadas.
En Windows 10 sobre ARM se incluye una emulación de aplicaciones x86 que permite ejecutar programas de 32 bits sin modificarlos, mientras que Windows 11 en ARM amplía esa capacidad y es capaz de emular también binarios x64. Es decir, muchas aplicaciones «de siempre» para escritorio x86 pueden funcionar sin que el desarrollador cambie nada, aunque con una penalización de rendimiento frente a ejecutarlas de forma nativa.
El escenario ideal para exprimir un equipo ARM no es depender de la emulación sino ofrecer binarios nativos ARM64. Cuando una aplicación se recompila de forma específica para ARM64, puede sacar partido de un consumo energético optimizado, de un mejor rendimiento de CPU y GPU, y de la NPU integrada para tareas de IA. Además, en el mundo de la virtualización cobra especial importancia que los controladores de kernel sean nativos ARM64, porque el kernel de Windows no emula drivers.
La ausencia de emulación a nivel de kernel impacta directamente en los escenarios de virtualización avanzada: si tu solución necesita drivers de bajo nivel para dispositivos virtuales, filtros de red o almacenamiento y esos controladores no existen en ARM64, no podrás simplemente «tirar de emulación». En estos casos es obligatorio recompilar los drivers como ARM64 nativos y probarlos sobre Windows en ARM.
Requisitos y herramientas para desarrollar y portar aplicaciones a ARM64 en Windows
Si eres desarrollador y quieres añadir soporte nativo ARM64 a tu aplicación Windows, la buena noticia es que el ecosistema de herramientas se ha puesto las pilas. Hoy en día puedes compilar, depurar y optimizar aplicaciones ARM64 tanto desde un propio dispositivo ARM como desde un PC x64 haciendo compilación cruzada.
Para trabajar directamente sobre un equipo Windows en ARM puedes utilizar Visual Studio 2022 a partir de la versión 17.4, que fue la primera edición de disponibilidad general con soporte nativo para ARM64. Esta versión y posteriores incluyen un MSVC optimizado para ARM64, con un rendimiento muy superior a ejecutar el IDE en modo emulado. También se soportan versiones recientes de LLVM/Clang (a partir de la 12), que cuentan con binarios oficiales para Windows sobre ARM64.
Si en lugar de compilar en el propio ARM prefieres compilación cruzada desde un PC Intel/AMD x64, también es posible generar binarios ARM64 desde ahí. La elección entre nativo o cruzado depende del hardware que tengas disponible, de la comodidad para ejecutar pruebas automatizadas y de la integración con tu pipeline de CI/CD.
A nivel de frameworks y runtimes Microsoft ha ido alineando versiones para que no te quedes colgado en ARM64: .NET 7, .NET 6 LTS, .NET 5.0.8+ y .NET Framework 4.8.1 cuentan con soporte para esta arquitectura, al igual que herramientas como clang-cl, que puede actuar como sustituto del compilador y enlazador de MSVC utilizando sus mismas cabeceras y bibliotecas.
Cómo añadir una configuración de compilación ARM64 en Visual Studio
El primer paso práctico para portar una aplicación de escritorio suele ser añadir una nueva configuración de plataforma ARM64 al proyecto existente, que probablemente esté ahora mismo pensado para x86 y/o x64. Visual Studio lo pone relativamente fácil a través del gestor de configuraciones.
El flujo típico en Visual Studio es: abrir la solución, ir al menú de «Plataformas de solución» en la barra de herramientas y seleccionar el «Administrador de configuraciones». Desde ahí creas una nueva plataforma de solución, escoges ARM64 como destino y copias la configuración desde x64, marcando la casilla para crear también las nuevas plataformas de proyecto.
Una vez creada la plataforma ARM64, el siguiente paso es compilar y ver si el proyecto se construye sin errores. Si la compilación falla, lo más habitual es que exista alguna dependencia (biblioteca, SDK de terceros o plugin) que todavía no disponga de binarios para ARM64. En ese punto toca revisar qué dependencias son bloqueantes y buscar alternativas o versiones actualizadas.
Si quieres asegurarte de que el binario resultante es realmente ARM64, puedes abrir el directorio del proyecto en PowerShell, ir a la carpeta bin\ARM64\Debug o Release y lanzar dumpbin /headers .\tuapp.exe. En la sección FILE HEADER VALUES debería aparecer AA64 machine (ARM64), confirmando que se ha generado un ejecutable nativo para esta arquitectura.
Pruebas y depuración de aplicaciones ARM64 en dispositivos y máquinas virtuales
Compilar es solo la mitad del trabajo, luego toca probar y depurar sobre un entorno real ARM64. Si estás desarrollando directamente en un portátil Windows en ARM, lo tienes fácil: configuras la depuración local tal y como harías en un equipo x64 y ejecutas la aplicación nativa sin más.
En cambio, si estás compilando desde un PC x64 mediante compilación cruzada resulta muy práctico configurar la depuración remota: Visual Studio se queda en tu máquina Intel/AMD, pero la app ARM64 se ejecuta en un dispositivo Windows sobre ARM o una máquina virtual que expone los puertos necesarios para adjuntar el depurador.
Para escenarios de pruebas automatizadas e integración continua puedes recurrir tanto a hardware físico (portátiles ARM, miniPCs, etc.) como a máquinas virtuales de Windows en ARM desplegadas en Azure u otras nubes. Microsoft documenta cómo crear rápidamente una VM Windows en ARM desde Azure Portal y usarla como entorno de CI para ejecutar tus suites de tests sobre la arquitectura objetivo.
En el contexto de la virtualización con Hyper-V en ARM, también debes tener en cuenta que algunas herramientas de rendimiento, como Windows Performance Recorder, tienen soporte limitado para muestreo de CPU dentro de máquinas virtuales ARM64, así que conviene comprobar qué métricas están disponibles en cada versión.
Publicación, instaladores y mantenimiento de versiones ARM64
Cuando ya tienes tu binario ARM64 estable, toca pensar en distribución. Si publicas en Microsoft Store, el proceso es bastante directo: desde el panel del Centro de partners puedes agregar los nuevos binarios ARM64 al envío existente, de manera que los usuarios en dispositivos Windows en ARM reciban automáticamente la versión nativa adecuada.
Si en lugar de la Store usas instaladores propios en formato MSI, EXE o MSIX, tendrás que asegurarte de que tu framework de instalación soporta Windows en ARM. La mayoría de soluciones conocidas (WiX, Squirrel, InnoSetup, InstallAware y compañía) ya funcionan sin problema sobre esta plataforma, pero conviene revisarlo y probar el flujo de instalación y desinstalación con calma.
Para instalaciones descargadas desde web resulta interesante aprovechar los Client Hints del User-Agent para detectar si el usuario está navegando desde un dispositivo ARM y ofrecerle por defecto el instalador ARM64, dejando el x64 solo como opción secundaria. A diferencia de la antigua cadena User-Agent, los Client Hints permiten distinguir con más precisión entre clientes ARM y x86.
Una vez que soportas varias arquitecturas es vital mantenerlas a la par: las versiones ARM64 deben recibir las mismas actualizaciones y funciones que las builds x64, de lo contrario acabarás generando confusión entre los usuarios. Lo ideal es que todo tu proceso de CI/CD esté preparado para generar, probar y sacar a producción las variantes x86, x64 y ARM64 de forma casi simultánea.
Problemas habituales al portar a ARM64: dependencias, ensamblador y drivers
El principal dolor de cabeza al migrar una aplicación a ARM64 suele ser una dependencia que aún no está compilada para esta arquitectura. Puede tratarse de una librería interna de tu organización, un SDK de un proveedor externo o un componente open source que llevas años usando.
En el caso de dependencias internas, la solución pasa por recompilarlas para ARM64 siguiendo un proceso similar al de tu propia app. Si hablamos de componentes de terceros, toca pedir oficialmente al proveedor que ofrezca versión ARM64 o buscar una alternativa equivalente que sí la tenga. Con dependencias open source, merece la pena revisar primero vcpkg u otros gestores para ver si existe ya un port ARM64 listo para usar, y si no, plantearte contribuir tú mismo los cambios necesarios.
Otra estrategia interesante es usar Arm64EC, una ABI híbrida que permite mezclar código nativo ARM64 con módulos x64 emulados dentro de un mismo proceso. Con Arm64EC puedes recompilar solo la parte crítica de tu aplicación a ARM64 mientras sigues utilizando DLLs x64 bajo emulación, lo que facilita una migración progresiva cuando alguna dependencia todavía no tiene build nativa.
Si tu código tiene secciones escritas en ensamblador o usa intrínsecos específicos para x86/x64, también tendrás que revisarlos. No basta con recompilar: habrá que adaptar esas partes a las instrucciones y funciones intrínsecas disponibles en CPUs ARM. Microsoft ofrece guías sobre cómo trabajar con ensamblador e intrínsecos en C/C++ orientados a ARM para evitar errores sutiles de portabilidad.
El caso más delicado es cuando la aplicación depende fuertemente de drivers de kernel: como comentábamos antes, el kernel de Windows no emula drivers, así que todos los controladores que necesites deben existir en versión ARM64 pura. Para desarrollar o portar drivers puedes apoyarte en el Windows Driver Kit (WDK) siguiendo la documentación específica de creación de controladores ARM64.
Soporte de máquinas virtuales Windows sobre ARM e Hyper-V
En cuanto a virtualización nativa en equipos Windows 11 ARM, Hyper-V está presente con capacidades específicas. Puedes crear máquinas virtuales ARM64 de Windows 11 y aprovecharlas para pruebas, desarrollo o entornos aislados. Además, Microsoft ofrece documentación y cursos centrados en añadir compatibilidad con ARM a aplicaciones Windows y en cómo desplegarlas y depurarlas dentro de VMs en Hyper-V.
Ahora bien, la experiencia con invitados Linux ARM bajo Hyper-V en portátiles ARM todavía arrastra limitaciones. Hay casos reportados en los que una ISO ARM de Ubuntu o Kali arranca el GRUB sin problemas, pero el instalador se queda congelado al seleccionarlo. En contraste, una ISO de Windows 11 ARM se instala sin dificultad en la misma configuración, lo que deja claro que el problema está en la combinación Hyper-V + distribuciones Linux ARM concretas.
Si necesitas Linux en un Windows ARM y Hyper-V no coopera, puedes valorar otras rutas como WSL (cuando haya soporte sólido para ARM en la distribución deseada) o el uso de soluciones de virtualización de terceros en cuanto vayan madurando en esta arquitectura. En el ecosistema x86 ya tenemos muchas alternativas, pero en ARM todavía se está recorriendo camino.
Comprobar el tipo de virtualización y el entorno en Linux
Pasando al lado Linux, una duda bastante habitual es saber si el sistema se está ejecutando sobre bare metal o dentro de una máquina virtual, y en este último caso, bajo qué tecnología: KVM, Xen, VMware, VirtualBox, etc. Esto es clave si administras servidores en la nube, VPS o incluso contenedores que se ejecutan sobre hipervisores.
En sistemas con systemd, uno de los métodos más sencillos es el comando hostnamectl, que además de mostrar el nombre de host, la arquitectura, el sistema operativo y el proveedor de hardware, incluye un campo de «Virtualization» indicando si se trata de KVM, VMware, Oracle (VirtualBox) u otro tipo. Puedes filtrar la salida con hostnamectl | grep -i virtualization para ver solo ese dato.
Otra herramienta especialmente pensada para esto es systemd-detect-virt, incluida en el propio systemd. Basta con ejecutarla sin opciones y te devolverá el tipo de virtualización detectado: kvm, vmware, oracle para VirtualBox, etc. Si quieres ver la lista completa de tecnologías que puede reconocer, puedes usar systemd-detect-virt --list.
Si necesitas un diagnóstico algo más exhaustivo, el script virt-what también es una buena opción. No viene instalado de serie en la mayoría de distros, pero lo puedes añadir fácilmente con el gestor de paquetes (apt, yum, pacman, zypper, etc.). Una vez instalado, ejecutas sudo virt-what y mostrará la tecnología de virtualización detectada; si no imprime nada, lo más probable es que estés en una máquina física o bajo un hipervisor que aún no reconoce.
Por último, la herramienta dmidecode puede darte pistas examinando los datos SMBIOS del firmware. Con algo como sudo dmidecode -s system-product-name puedes descubrir si el sistema se identifica como producto de VMware, KVM, VirtualBox o un modelo de servidor físico concreto, lo que ayuda a confirmar en qué entorno estás trabajando.
Virtualización por hardware en PCs x86/AMD64 y su impacto en ARM
Aunque el foco de este contenido es ARM, conviene entender cómo funciona la virtualización por hardware en PCs tradicionales, porque muchos conceptos se extrapolan a ARM: necesitas instrucciones específicas del procesador y soporte del firmware (BIOS/UEFI) para que hipervisores como Hyper-V, KVM o VirtualBox puedan aprovechar la aceleración.
En Windows 10 puedes comprobar si la virtualización por hardware está activa sin reiniciar, abriendo el Administrador de tareas (Ctrl+Shift+Esc), yendo a la pestaña de «Rendimiento» y seleccionando la CPU. Ahí verás un campo de «Virtualización» que indica si está habilitada o deshabilitada, y también si el sistema está corriendo sobre Hyper-V, lo cual puede limitar el uso de otros hipervisores como VirtualBox al crear VMs de 64 bits.
Si la virtualización aparece deshabilitada, hay dos posibles motivos: o bien el procesador es demasiado antiguo y no soporta Intel VT-x o AMD-V, o simplemente la opción está desactivada en la BIOS/UEFI, algo muy frecuente con la configuración de fábrica. En chips modernos (de los últimos 10-12 años) casi siempre está presente, así que suele bastar con entrar en la BIOS y activar «Intel Virtualization Technology» o «AMD-V».
Cuando Hyper-V está activado, Windows pasa a ejecutarse sobre el hipervisor y eso impide que VirtualBox pueda crear máquinas virtuales de 64 bits usando VT-x/AMD-V. En ese caso, si necesitas VirtualBox, tendrás que ir a «Activar o desactivar las características de Windows» y desmarcar Hyper-V, reiniciando después para que el sistema vuelva a arrancar directamente sobre el hardware.
En equipos con Windows sobre ARM la idea es similar: el procesador necesita exponer las instrucciones de virtualización y el firmware debe permitir habilitarlas para que Hyper-V u otras capas de virtualización puedan aprovechar todo el potencial. La diferencia está en que hablamos de instrucciones de virtualización específicas de ARM en lugar de VT-x/AMD-V, pero el concepto de «aceleración por hardware» es el mismo.
VirtualBox, KVM, Xen y LXC: panorama de virtualización y contenedores en Linux
En el mundo Linux, la virtualización real y el aislamiento tipo contenedor conviven desde hace años. Entre las soluciones más populares encontramos hipervisores como Xen y KVM, herramientas más de usuario como VirtualBox y sistemas de contenedores a bajo nivel como LXC, cada uno con sus fortalezas y limitaciones.
Xen es un sistema de paravirtualización clásico que introduce un hipervisor muy fino entre el hardware y los sistemas operativos invitados. Habla de dominios: el dom0 (dominio 0) actúa como anfitrión con control sobre el hipervisor y la gestión de otros dominios, mientras que los domU son los invitados. Para usar Xen en Debian, por ejemplo, necesitas instalar el paquete xen-hypervisor adecuado a tu arquitectura (amd64, armhf, arm64), un kernel compatible (cualquier 3.0 o superior) y las utilidades xen-utils, que incluyen herramientas de administración como xl.
La creación de domU con Xen se puede automatizar con xen-tools, utilizando comandos como xen-create-image que fabrican discos virtuales, configuran memoria, distros base (por ejemplo bullseye), red (DHCP o IP fija) y otros parámetros. Después, se gestiona el ciclo de vida de los invitados con órdenes xl: listar dominios, iniciarlos, pausarlos, guardarlos en disco, restaurarlos, etc.
LXC, por su parte, no es virtualización al uso sino aislamiento de procesos mediante cgroups y namespaces del kernel Linux. Los contenedores LXC comparten el mismo kernel que el host, pero tienen su propio espacio de procesos, red y sistema de ficheros. Esto permite conseguir un rendimiento casi nativo a costa de no poder ejecutar otros sistemas operativos o kernels distintos dentro del contenedor.
Configurar LXC implica asegurarse de que los cgroups están activos (algo que con systemd ya viene de fábrica), instalar el paquete lxc y preparar la red, normalmente mediante un puente (bridge) que conecta las interfaces virtuales de los contenedores con la interfaz física del host. Luego, con lxc-create y plantillas como «debian» puedes crear sistemas mínimos que arrancan con su propio init y a los que accedes con lxc-console o por SSH.
KVM (Kernel-based Virtual Machine) es otra pieza fundamental del ecosistema: no es un hipervisor completo por sí solo, sino un módulo del kernel que habilita las extensiones de virtualización del procesador (Intel VT o AMD-V) para que QEMU u otras herramientas puedan usarlas. En Linux i386/amd64 puedes comprobar si el hardware soporta estas extensiones buscando las flags «vmx» o «svm» en /proc/cpuinfo.
La gestión diaria de KVM suele hacerse a través de libvirt, un framework que proporciona un demonio (libvirtd) y herramientas de consola como virsh, así como frontends gráficos como Virtual Machine Manager (virt-manager). Con virt-install puedes describir las características de una VM (memoria, disco QCOW2, ISO de instalación, red en puente o NAT, etc.) y disparar el proceso de instalación, para luego controlarla con virsh start, shutdown, suspend, autostart y demás.
VirtualBox se mantiene como solución sencilla y multiplataforma para muchos usuarios
VirtualBox 7.2, por ejemplo, ha mejorado bastante la interfaz reorganizando las herramientas globales y de máquina virtual, y, lo que aquí nos interesa, ha dado pasos importantes en soporte para ARM. La versión para Windows en ARM permite virtualizar invitados Windows también ARM mediante el instalador universal, ofreciendo incluso Guest Additions específicas.
En Linux como host, VirtualBox 7.2 ha añadido reproducción de vídeo acelerada por hardware cuando el soporte 3D está activo, compatibilidad inicial con kernels Linux 6.17 como anfitrión e invitado, y correcciones para el módulo vboxvideo en arranques antiguos. Además, se incluye en el paquete base un controlador de emulación de almacenamiento NVMe abierto, lo que mejora el rendimiento de las VMs.
En macOS sobre ARM, VirtualBox ofrece soporte experimental de aceleración 3D mediante DXMT, sustituyendo a la anterior combinación DXVK + MoltenVK, que no terminaba de funcionar. Eso sí, la aceleración 3D ha dejado de estar disponible en hosts macOS sobre Intel, centrándose claramente en Apple Silicon.
Windows en ARM dentro de Mac con Apple Silicon: el papel de Parallels
Una situación curiosa relacionada con ARM es la de los Mac con chips M1/M2: Apple ha eliminado Boot Camp en esta arquitectura, así que ya no es posible instalar Windows de forma nativa ni en versión x86 ni en ARM en una partición aparte. Además, Microsoft no comercializa libremente licencias de Windows ARM para instalación directa en cualquier equipo; se centra en acuerdos con fabricantes.
Pese a ello, la combinación Windows 11 ARM + Parallels Desktop ha demostrado ser una solución bastante sólida para quienes necesitan Windows en un Mac Apple Silicon. Parallels automatiza incluso la descarga de la imagen ARM de Windows 11 (apoyándose en el programa Windows Insider) y crea una máquina virtual optimizada para el hardware del Mac, con drivers y herramientas propias (Parallels Tools).
En máquinas como un MacBook Air con chip M2 se ha comprobado que Windows 11 ARM funciona de forma muy fluida, con animaciones suaves, buena integración del teclado y el sonido y un rendimiento en benchmarks como Geekbench muy cercano al del propio macOS, incluso asignando solo parte de los núcleos al invitado.
En cuanto a compatibilidad de aplicaciones y juegos, el panorama es mezclado: títulos veteranos como Half-Life 2 funcionan a pleno rendimiento, aprovechando que sus requisitos gráficos son modestos y que la emulación x86 se apoya en un hardware muy capaz. Otros juegos más recientes, como Shadow of the Tomb Raider, llegan a arrancar pero muestran artefactos gráficos y errores, en buena parte por limitaciones de los drivers gráficos emulados.
Para tareas de productividad (Office 365, Teams, Outlook, hojas de cálculo complejas), la experiencia es más que aceptable, con tiempos de cálculo comparables a PCs modernos y una integración muy cómoda gracias al modo Coherence, que mezcla ventanas de Windows en el escritorio de macOS. Mientras no exista un Boot Camp nativo ARM, esta vía de virtualización se ha vuelto la opción realista para disponer de Windows en Mac actuales.
En conjunto, el soporte de virtualización sobre ARM en Windows, Linux y macOS está avanzando a buen ritmo, pero aún hay aristas: drivers de kernel que faltan, distribuciones Linux ARM con problemas bajo Hyper-V, juegos exigentes que no se entienden bien con la emulación gráfica… Por eso es clave saber detectar qué entorno de virtualización estás usando, comprobar que tu hardware soporta las extensiones necesarias y elegir la combinación de hipervisor y arquitectura invitada que mejor encaje con tus necesidades reales.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.