Por que substituiram o Firecracker pelo QEMU

• O Hocus (uma alternativa self-hosted ao GitPod/GitHub Codespaces) substituiu o Firecracker pelo QEMU

O Firecracker é otimizado para workloads que rodam por pouco tempo e depois terminam

• Um hipervisor de microVM leve, rápido e seguro usado no AWS Lambda
• Não é tão leve assim
  • Não oferece o "recurso de gerenciamento dinâmico de RAM", essencial para workloads de longa duração. A RAM alocada uma vez não é devolvida ao host
  • Também não há recurso para devolver armazenamento ao host. Mesmo que você crie e depois apague arquivos grandes dentro da VM, o espaço livre não volta para o host. Ele continua ocupado até que o disco inteiro da VM seja apagado
  • Não tem suporte a GPU e também não oferece IO de disco de alto desempenho

O QEMU também não é perfeito

• Há coisa demais para configurar
• Para devolver a RAM não utilizada, o host precisa resolver 3 desafios
  • Saber que esse recurso existe (ele é chamado de free page reporting e precisa ser ativado manualmente)
  • Entender o recurso DAMON do Linux, saber para que ele serve e como configurá-lo, além de compilar um kernel Linux que o suporte
  • É preciso impedir o uso de Transparent Huge Pages no guest; caso contrário, a VM não devolve grandes quantidades de memória
• Levou 2 meses para testar e aplicar
  • Ler o código do Firecracker/QEMU
  • E também trocar e-mails com desenvolvedores para configurar o DAMON
    → (O desenvolvedor do DAMON é o coreano SeongJae Park.)

Conclusão

• O QEMU tem os recursos necessários para operar workloads de uso geral
• Mas a configuração exige tempo e paciência
• Para Short-lived, Untrusted Workload, o Firecracker é uma boa escolha
• Mas se você quiser rodar seu ambiente de desenvolvimento em VMs, pode usar o Hocus (porque nós já fizemos toda a parte difícil)

[tujuc]

É bom apresentar o próprio produto, mas também fico pensando que talvez seja melhor simplesmente usar os serviços da AWS..
Como o ssssut comentou, é um serviço que também roda no Fargate, então não acho que chegue a esse ponto.

Ainda não entendi qual é exatamente o problema de não devolver memória. CPU, mesmo que haja contenção, no máximo deixa a aplicação mais lenta, mas não impede que ela suba; já com memória não tem saída...

[ssssut]

Adendo: a AWS usa Firecracker não só no Lambda, mas também no ECS Fargate para cargas de trabalho de longa duração.

[GN⁺]

Comentários do Hacker News

• O Firecracker é usado no CodeSandbox para hospedar ambientes de desenvolvimento, mas acho que também pode ser usado para tarefas de longa duração.
• O QEMU tem um alvo inspirado no Firecracker chamado microvm, um tipo mínimo de máquina sem suporte a PCI ou ACPI, projetado para guests de curta duração.
• O Cloud-hypervisor é outra opção semelhante ao Firecracker, com suporte a recuperação de memória e outros recursos.
• O Firecracker tem um dispositivo de balloon que pode inflar e desinflar para recuperar memória do sistema host.
• Este artigo menciona as limitações do Firecracker, mas não fornece muitas informações sobre o QEMU.
• A Fly usa o Firecracker para hospedar processos de longa duração.
• Quero que as VMs se integrem de forma mais inteligente ao host, incluindo deduplicação de cache de bloco e integração zero-copy.
• O QEMU, ao contrário do Firecracker, pode fazer bind mount de volumes, mas isso pode ser um risco de segurança.