Por que as VMs de Apple Silicon são tão diferentes?

Artigo original ↗ Discussão no Hacker News ↗

A mudança da Apple para o Silicon baseado em ARM remodelou a virtualização nos Macs, permitindo VMs ARM de macOS e Linux rápidas por meio dos frameworks de Virtualization/Hypervisor e do VirtIO, mas tornando convidados x86‑64 completos dependentes de emulação mais lenta. Desenvolvedores relatam bons resultados ao executar binários x86‑64 de Linux dentro de VMs ARM usando Rosetta ou a própria camada de tradução do Windows on ARM (muitas vezes via Docker, OrbStack, Parallels ou UTM), mas sistemas x86 totalmente virtualizados continuam significativamente mais lentos e, às vezes, frágeis. O thread também destaca limites e trade-offs da plataforma — como o teto de duas VMs de macOS, a ausência de virtualização ARM de 32 bits e o controle rígido da Apple sobre recursos como virtualização aninhada — além de questões mais amplas sobre os papéis do iPad vs. Mac e o futuro das configurações locais vs. remotas de desenvolvimento.

Estado do x86‑64 em Apple Silicon

  • Virtualizar totalmente sistemas operacionais x86/x86‑64 em Apple Silicon depende de emulação (por exemplo, QEMU puro) e é descrito de forma consistente como “muito lento”.
  • Um padrão comum: executar um sistema operacional ARM64 (Linux ou Windows) em uma VM e, em seguida, usar a própria tradução x86 desse sistema (Rosetta no Linux/macOS, a emulação x86 do Windows) para aplicativos individuais.
  • Alguns usuários relatam desempenho aceitável para ferramentas de CLI e produtividade leve; outros enfrentam instabilidade (por exemplo, builds de Elixir falhando com segfault) a menos que workarounds específicos sejam aplicados.

Rosetta 2 em VMs Linux e Docker

  • A Apple expõe o Rosetta a convidados Linux ARM64 via Virtualization.framework, permitindo binários x86‑64 dentro de uma VM ARM com bom desempenho.
  • Docker Desktop e ferramentas como OrbStack e Lima/Colima usam isso para executar contêineres amd64 em Apple Silicon; o desempenho muitas vezes é próximo ao, ou às vezes melhor que, o de laptops Intel de ponta.
  • Existem workarounds para bugs do JIT do QEMU (por exemplo, definir flags de build para Erlang/Elixir) para evitar crashes.

Ferramentas de VM: Parallels, UTM, VMware, Outras

  • Parallels + Windows 11 ARM é amplamente elogiado para produtividade geral e desenvolvimento; a emulação x86 embutida do Windows é em grande parte “invisível e simplesmente funciona”.
  • As reclamações sobre o Parallels incluem anúncios/vendas adicionais, licenciamento por assinatura, UX ruim em desktops Linux (por exemplo, rolagem) e preocupações com a política de privacidade.
  • UTM (frontend para QEMU) é visto como utilizável, mas muitas vezes lento para emulação completa de SO x86; melhor quando executa convidados ARM + Rosetta.
  • OrbStack e Lima são destacados como soluções fortes voltadas a CLI para Linux em Apple Silicon, frequentemente substituindo o Docker Desktop.

VirtIO, Apple Virtualization e limites de VMs do macOS

  • A discussão observa a transição da Apple para VirtIO e Virtualization.framework; o VirtIO em si não é específico de ARM ou da Apple, mas a Apple começou a fornecer drivers de host com Apple Silicon.
  • O macOS em Apple Silicon impõe um limite rígido de duas VMs de macOS simultâneas, tanto tecnicamente quanto contratualmente; VMs Linux não estão sujeitas a esse limite.
  • Alguns relatam que VMs de macOS não conseguem entrar com Apple ID, tornando-as menos adequadas para uso geral de desktop.

Windows, jogos e alternativas

  • Muitos jogos de Windows rodam razoavelmente bem sob Parallels + Windows ARM, mas a compatibilidade é inconsistente e anti-cheat em nível de kernel continua sendo um grande bloqueio.
  • Para jogos, vários comentaristas preferem soluções baseadas em Wine (CrossOver, Whisky, Game Porting Toolkit) ou cloud gaming (por exemplo, GeForce Now) em vez de VMs completas.

Temas mais amplos e reclamações

  • Vários argumentam que, para cargas pesadas de x86, um servidor/workstation x86 remoto é mais prático do que emulação local.
  • Há frustração com a falta de virtualização aninhada em convidados macOS, apesar do suporte de hardware, e com as restrições estratégicas/licenciamento da Apple em torno de VMs.