Como contornar o limite de 2 máquinas virtuais no Apple Silicon (2023)

• O macOS baseado em Apple Silicon limita a no máximo 2 VMs de macOS executáveis via Virtualization.framework, com base em uma cláusula do contrato de licença do macOS
• A análise mostrou que esse limite é gerenciado pela variável privada hv_apple_isa_vm_quota dentro do kernel XNU, e que ela pode ser sobrescrita por meio de argumentos de boot
• Para contornar a verificação AppleInternal do System Integrity Protection, é usado um procedimento para compilar e iniciar com um kernel de desenvolvimento (Development Kernel)
• Após a configuração, foi possível executar até 9 VMs de macOS simultaneamente em UTM, Viable e Parallels
• Chama atenção o fato de a Apple ter deixado uma função de sobrescrita do limite de VMs dentro do kernel, e são sugeridas melhorias futuras por meio de ferramentas de automação ou extensões de kernel

---

Processo para remover o limite de 2 máquinas virtuais do macOS no Apple Silicon

• Ao executar máquinas virtuais de macOS em Macs com Apple Silicon usando o Virtualization.framework, existe um limite de no máximo 2 instâncias em execução
  • Esse limite é definido de acordo com a cláusula 2.B.iii do contrato de licença de software (SLA) do macOS
  • Essa cláusula permite executar no máximo 2 instâncias do macOS apenas para desenvolvimento, testes, uso com macOS Server e uso pessoal não comercial
• A análise mostrou que esse limite é implementado não no espaço do usuário, mas em uma área privada do kernel (XNU)
  • O kernel para Intel não contém o mesmo código, e o conjunto de funções hv_vm_* do kernel Apple Silicon é responsável pela pilha de virtualização
  • Dentro do código de inicialização hv_init(), a variável hv_apple_isa_vm_quota controla a quantidade de VMs e é incrementada ou decrementada na criação e remoção de VMs
  • O kernel possui os argumentos de boot hypervisor= e hv_apple_isa_vm_quota=, e o segundo pode sobrescrever o limite de VMs
• No kernel de release, em vez do argumento hypervisor, a restrição é aplicada por uma verificação AppleInternal do System Integrity Protection (SIP)
  • O argumento hv_apple_isa_vm_quota só é aplicado quando a flag CSR_ALLOW_APPLE_INTERNAL está ativada
  • Para contornar isso, foi usado o método de iniciar com o kernel de desenvolvimento da Apple (Development Kernel)

Compilando a coleção de kernel de desenvolvimento

• É necessário baixar e instalar o Kernel Debug Kit (KDK) no site Apple Developer
  • O KDK deve corresponder exatamente ao build do macOS hospedeiro; em caso de incompatibilidade, podem ocorrer erros de link do kernel e de kexts, além de falhas de boot
• Depois de verificar a arquitetura do kernel com o comando uname, usa-se o comando kmutil create para gerar a coleção de kernel de desenvolvimento (VirtualMachine.kc)
  • No exemplo, são usados o macOS 14.0 (build 23A5301h) e o kernel T6020
  • A opção --variant-suffix development seleciona o kernel de desenvolvimento e inclui vários repositórios de extensões do sistema

Configurando o boot com o kernel de desenvolvimento

• Desligue o Mac e inicialize em modo de recuperação (recoveryOS) para executar as configurações a seguir no Terminal
  1. Desativar o System Integrity Protection (csrutil disable)
  2. Remover a restrição de argumentos de boot (bputil --disable-boot-args-restriction)
  3. Definir a coleção de kernel personalizada (kmutil configure-boot)
  4. Configurar os argumentos de boot (passados pelo comando nvram)
     • kcsuffix=development : inicia com o kernel de desenvolvimento
     • hypervisor=0x1 : ativa recursos especiais da pilha de virtualização
     • hv_apple_isa_vm_quota=0xFF : define o número máximo de VMs como 255
• Após reiniciar, é possível verificar a aplicação com sysctl kern.osbuildconfig e nvram boot-args

Resultado ao executar múltiplas VMs

• Após concluir a configuração, foram realizados testes com soluções baseadas em Virtualization.framework, como UTM, Viable e Parallels
  • Em um MacBook Pro com M2 Pro, foi possível executar 9 VMs de macOS ao mesmo tempo
  • O sistema ainda permaneceu em um estado utilizável para testes

Momento em que a função foi adicionada e estrutura interna

• O argumento de boot hv_apple_isa_vm_quota foi adicionado junto com a pilha de Virtualization a partir do macOS 12 Monterey
  • Em versões posteriores, incluindo o macOS Sonoma, a verificação AppleInternal continua presente
  • Isso confirma que a Apple mantém várias funções privadas dentro do XNU

Cuidados ao atualizar o sistema operacional

• Ao usar uma coleção de kernel personalizada, o recurso de atualização automática do sistema operacional é desativado
  • Como ocorrem erros após a atualização, é necessário restaurar a coleção de kernel padrão
  • No modo de recuperação, é possível voltar ao kernel padrão criando uma nova política de boot com bputil
  • Ex.: bputil --full-security ou uso da opção --disable-boot-args-restriction

Encerramento e ideias para melhorias futuras

• Foi verificada a forma como a Apple implementa o limite de VMs e, de maneira não oficial, o método para remover essa limitação foi validado experimentalmente
  • Mesmo sem documentação oficial da equipe de Virtualization, chama atenção o fato de terem deixado uma função de sobrescrita do limite de VMs no kernel
• Ideias de melhorias futuras
  • Desenvolvimento de uma ferramenta de automação para compilar KC e configurar o boot
    • Suporte para gerar automaticamente a coleção de kernel de desenvolvimento por host e aplicar configurações no modo de recuperação
  • Implementação de uma função para sobrescrever a variável hv_apple_isa_vm_quota por meio de uma extensão de kernel (kext)
    • Explorar a possibilidade de remover a limitação sem iniciar com o kernel de desenvolvimento
• Como próximo tema de pesquisa, está previsto explorar a possibilidade de registrar Apple Silicon VM no DEP e sobrescrever o número de série

[GN⁺]

Comentários do Hacker News

• Esse tipo de limitação que se aplica igualmente a todos os Macs é muito irracional
  Se você comprou um Mac mais potente, deveria poder virtualizar mais instâncias do macOS
  Por exemplo, algo como limitar o M5 a 2, o M5 Pro a 4 e o M5 Max a 8 pareceria mais razoável

  • Nem entendo por que impor um limite em primeiro lugar
    O desempenho do hardware já é o limite natural, então o usuário vai parar por conta própria
  • Isso parece mais uma decisão de negócios do que uma questão de recursos
    É bem provável que seja uma medida para impedir serviços baratos de VPS para Mac
  • Isso não é uma limitação de hardware, e sim uma briga contra a preocupação do Tim Cook com as vendas
  • Se você compra uma licença do Windows 11 Pro por 100 dólares, o limite de VM é 1024
    O Hyper‑V pode executar até 1024 VMs ao mesmo tempo, se o hardware aguentar
    Até no meu pequeno notebook Windows ARM eu consigo rodar 4 sem dificuldade
  • É realmente absurdo
    Rodei uma VM para testar o openclaw e fiquei surpreso ao ver que o acesso ao iCloud e à App Store era restrito

• É interessante que, 2 anos depois de Mykola Grymalyuk escrever este post no blog, ele entrou na Apple
  Isso faz lembrar o meme do “ou você morre como herói...”

• A partir do M3, dá para rodar VM aninhada usando Hypervisor.framework / Virtualization.framework
  Seria bem divertido se isso permitisse contornar a limitação

  • Se bem me lembro, o aninhamento só é possível para guests Linux
    No macOS, só vai até um nível, então não dá para subir outro guest macOS dentro de um guest macOS
  • Se cada VM pudesse rodar 2 VMs, daria até para criar uma cadeia infinita de VMs
    Estou com preguiça, mas queria que alguém testasse isso

• Fico realmente curioso sobre por que a Apple impôs essa limitação

  • O modelo de negócios da Apple é vender hardware e software juntos
    As vendas de hardware financiam o desenvolvimento do software, então ela não quer que quem não comprou o hardware use o macOS
  • O macOS tem muitas dessas restrições ao usuário
    Para a Apple, manter o controle é prioridade acima da liberdade do usuário
  • Talvez isso também seja uma medida para impedir que uma única máquina rode uma fazenda de contas online (identity farm)

• É impressionante que seja possível compilar um kernel customizado, inicializar e ainda subir até a GUI

• O texto em si é realmente interessante, mas é estranho usar para desenvolvimento uma plataforma com esse tipo de limitação arbitrária

  • Fico em dúvida se a Apple foi uma plataforma de desenvolvimento séria em algum momento dos últimos 20 anos
    Muitos desenvolvedores usam por causa do hardware avançado, mas o macOS sempre foi “quase um Linux, só que um sistema operacional controlado por uma empresa obcecada pelo iTunes”

• Dizem que, no Apple Silicon, usar coleções de kernel customizadas torna impossível receber atualizações automáticas do sistema operacional
  Mas isso pode até ser uma bênção disfarçada

• Fico curioso se isso também pode funcionar no lume
  Atualmente há uma limitação parecida

  • Acho que sim
    Pelo que sei, o lume é um wrapper fino sobre o Virtualization.framework da Apple

• Ouvi dizer que, se você desativar o SIP e definir argumentos de boot, isso funciona mesmo sem kernel customizado

  • Se isso for verdade, é uma dica subestimada

• A Apple limitou as VMs a 2?

  • Sim, pela licença, os VMs de macOS ficam limitados a 2
    Guests de outros sistemas operacionais podem ser executados sem limite