¿Por qué son tan diferentes las VMs en Apple Silicon?

Artículo original ↗ Discusión en Hacker News ↗

La transición de Apple a Silicon basado en ARM ha transformado cómo funciona la virtualización en los Mac, permitiendo VMs rápidas de macOS y Linux ARM mediante los frameworks de Virtualization/Hypervisor de Apple y VirtIO, pero haciendo que los huéspedes x86‑64 completos dependan de una emulación más lenta. Los desarrolladores informan buenos resultados al ejecutar binarios Linux x86‑64 dentro de VMs ARM usando Rosetta o la propia capa de traducción de Windows en ARM (a menudo mediante Docker, OrbStack, Parallels o UTM), aunque los sistemas x86 totalmente virtualizados siguen siendo significativamente más lentos y, a veces, frágiles. El hilo también pone de relieve límites y compensaciones de la plataforma —como el tope de dos VMs de macOS, la falta de virtualización ARM de 32 bits y el estrecho control de Apple sobre funciones como la virtualización anidada— junto con cuestiones más amplias sobre los papeles del iPad frente al Mac y el futuro de las configuraciones de desarrollo locales frente a las remotas.

Estado de x86‑64 en Apple Silicon

  • La virtualización completa de sistemas operativos x86/x86‑64 en Apple Silicon depende de la emulación (por ejemplo, QEMU puro) y se describe de forma constante como «muy lenta».
  • Un patrón común: ejecutar un SO ARM64 (Linux o Windows) en una VM y luego usar la traducción x86 propia de ese SO (Rosetta en Linux/macOS, emulación x86 de Windows) para aplicaciones individuales.
  • Algunos usuarios informan de un rendimiento aceptable para herramientas de línea de comandos y productividad ligera; otros encuentran inestabilidad (por ejemplo, compilaciones de Elixir que hacen segfault) salvo que se apliquen ciertas soluciones alternativas.

Rosetta 2 en VMs Linux y Docker

  • Apple expone Rosetta a huéspedes Linux ARM64 mediante Virtualization.framework, lo que permite binarios x86‑64 dentro de una VM ARM con buen rendimiento.
  • Docker Desktop y herramientas como OrbStack y Lima/Colima utilizan esto para ejecutar contenedores amd64 en Apple Silicon; el rendimiento a menudo es cercano o incluso a veces mejor que el de portátiles Intel de gama alta.
  • Existen soluciones alternativas para errores de JIT de QEMU (por ejemplo, establecer flags de compilación para Erlang/Elixir) para evitar fallos.

Herramientas de VM: Parallels, UTM, VMware y otras

  • Parallels + Windows 11 ARM es muy elogiado para productividad general y desarrollo; la emulación x86 integrada de Windows es en gran medida «invisible y simplemente funciona».
  • Las quejas sobre Parallels incluyen anuncios/ventas adicionales, licencias por suscripción, mala UX de escritorio Linux (por ejemplo, el desplazamiento) y preocupaciones sobre la política de privacidad.
  • UTM (un front-end de QEMU) se considera usable, pero a menudo lento para la emulación completa de sistemas operativos x86; funciona mejor al ejecutar huéspedes ARM junto con Rosetta.
  • OrbStack y Lima se destacan como soluciones sólidas orientadas a la línea de comandos para Linux en Apple Silicon, que a menudo sustituyen a Docker Desktop.

VirtIO, Apple Virtualization y límites de las VMs de macOS

  • La discusión señala la transición de Apple a VirtIO y Virtualization.framework; VirtIO en sí no es específico de ARM ni de Apple, pero Apple comenzó a incluir controladores de host con Apple Silicon.
  • macOS en Apple Silicon impone un límite estricto de dos VMs de macOS simultáneas, tanto técnica como contractualmente; las VMs Linux no están sujetas a este límite.
  • Algunos informan de que las VMs de macOS no pueden iniciar sesión en Apple ID, lo que las hace menos adecuadas para un uso general de escritorio.

Windows, juegos y alternativas

  • Muchos juegos de Windows funcionan razonablemente bien con Parallels + Windows ARM, pero la compatibilidad es impredecible y el anti-cheat a nivel de kernel sigue siendo un obstáculo importante.
  • Para jugar, varios comentaristas prefieren soluciones basadas en Wine (CrossOver, Whisky, Game Porting Toolkit) o cloud gaming (por ejemplo, GeForce Now) antes que VMs completas.

Temas más amplios y quejas

  • Varios sostienen que, para cargas de trabajo x86 pesadas, un servidor/estación de trabajo x86 remota es más práctico que la emulación local.
  • Hay frustración por la falta de virtualización anidada en huéspedes macOS a pesar del soporte de hardware, y por las restricciones estratégicas y de licencias de Apple en torno a las VMs.