Seu VPS consegue executar microVMs Firecracker?

Seu VPS pode executar microVMs Firecracker?

Seu VPS só pode executar microVMs Firecracker se fornecer /dev/kvm. O Firecracker é um VMM (monitor de máquina virtual) criado sobre o KVM (máquina virtual baseada no kernel), a camada de virtualização do Linux. O KVM precisa das instruções de virtualização da CPU. Num VPS, essas instruções só ficam disponíveis quando o provedor as expõe ao seu sistema convidado, e a maioria dos planos não faz isso.

Por isso, a primeira pergunta não é qual ferramenta de microVM instalar. É se a máquina que você já paga consegue hospedar uma microVM. Essa é uma questão do serviço de hospedagem, e você pode respondê-la em cerca de um minuto.

Verifique /dev/kvm antes de instalar qualquer coisa

Execute estes três comandos no próprio VPS.

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

Uma máquina capaz de alojar microVMs responde assim:

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

A primeira linha é o nó de dispositivo KVM, pertencente ao grupo kvm. A segunda linha indica que esta máquina é, por sua vez, um guest a executar sob KVM, o que é normal e esperado num VPS. A terceira linha conta os núcleos de CPU que indicam o sinalizador de virtualização de hardware, vmx na Intel e svm na AMD. Um valor superior a zero dentro de um guest significa que o hypervisor está a expor virtualização aninhada.

Depois, verifique se o seu utilizador consegue abrir o dispositivo. Este é o teste da própria documentação de introdução do Firecracker:

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

FAIL enquanto o nó existe indica um problema de permissões, não de hardware. Conceda acesso ao seu utilizador com sudo setfacl -m u:${USER}:rw /dev/kvm ou adicione-se ao grupo com sudo usermod -aG kvm ${USER} e inicie sessão novamente.

O Ubuntu também inclui uma verificação que resume tudo isto em duas linhas de saída:

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

Um host funcional apresenta INFO: /dev/kvm exists e depois KVM acceleration can be used. Um host que não consegue apresenta INFO: Your CPU does not support KVM extensions e depois KVM acceleration can NOT be used. Numa máquina física, poderá ver INFO: KVM (vmx) is disabled by your BIOS, um problema que pode ser corrigido no firmware. Num VPS, essa mensagem é rara, porque não está a consultar firmware real.

O que significa cada resposta sobre /dev/kvm?

O nó existe e a contagem de flags é superior a zero. Tem virtualização por hardware, portanto o Firecracker vai funcionar. Avance para a seção de dimensionamento, porque a sua limitação restante é a memória, não os recursos da CPU.

Não existe nó, systemd-detect-virt exibe kvm ou qemu e a contagem de flags é 0. O seu VPS é uma máquina virtual cujo host não está disponibilizando a virtualização para a máquina convidada. Nada que você instale dentro da máquina convidada altera isso, porque a flag é uma propriedade da CPU virtual que o hypervisor criou para você. sudo modprobe kvm_intel falha com modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, e sudo dmesg | grep -i kvm registra a ausência do suporte de hardware. Este é o caso comum em planos de VPS compartilhados. Pergunte ao provedor se o plano oferece virtualização aninhada. Se a resposta for não, você precisa de outra hospedagem, não de outro comando.

systemd-detect-virt exibe lxc, lxc-libvirt ou openvz. O seu plano usa virtualização por contêineres, portanto você compartilha o kernel do host. /dev/kvm nunca aparecerá, porque você não tem um kernel próprio para carregar um módulo. Nenhum pacote corrige isso.

As flags estão presentes, mas o nó não existe. O módulo simplesmente não está carregado. Execute sudo modprobe kvm_intel (ou kvm_amd em AMD) e verifique ls -l /dev/kvm novamente. Se o nó aparecer, escreva o nome do módulo em /etc/modules-load.d/kvm.conf para que ele volte a ser carregado depois de um reboot.

Você está em arm64. vmx e svm são nomes usados em x86, portanto a contagem de grep é 0 em qualquer máquina arm64, funcionando ou não. Em arm64, confie no nó de dispositivo e no teste de leitura e escrita.

Por que uma microVM e não um contentor para executar agentes

Um contentor é um processo no seu kernel, isolado por namespaces e cgroups. Existe um único kernel e ele é o seu, por isso uma fuga ao nível do kernel chega ao host. Uma microVM arranca o seu próprio kernel dentro de um limite de virtualização de hardware e comunica com um pequeno modelo de dispositivos emulados, em vez de usar toda a superfície de chamadas de sistema do host. O Firecracker mantém esse modelo deliberadamente pequeno. Esse é todo o objetivo do desenho: menos dispositivos emulados significam menos formas de sair.

Essa diferença é importante para um agente de programação, porque o código executado por um agente é código que ninguém leu previamente. O agente instala pacotes, executa scripts de compilação e repete operações à velocidade da máquina quando algo falha. Um kernel separado significa que um passo incorreto danifica uma máquina que pode apagar, e nada mais.

O requisito resulta diretamente do mecanismo. O isolamento de hardware precisa de virtualização de hardware, e a virtualização de hardware é precisamente aquilo que o seu plano VPS pode não disponibilizar. Um contentor não precisa de nada disso. É por isso que os contentores funcionam em todos os planos alguma vez vendidos.

Por isso, quando /dev/kvm está ausente, a VM descartável baseada em contentores para agentes de programação continua a ser a opção correta. É um controlo real, não um prémio de consolação. Um contentor descartável, num host que não guarda credenciais importantes, restaurado a partir de um snapshot sempre que apresenta problemas, impede a maior parte do que pode realmente correr mal. O mesmo se aplica à configuração mais simples descrita em executar um agente de programação num VPS. Use uma microVM quando um agente for executar tarefas sem supervisão durante horas, sobre código que ainda não reviu, e quando o host estiver sob o seu controlo.

O que um host de agentes microVM exige

Nehemiah é um exemplo atual desta classe: um daemon Apache-2.0 que fornece a uma IA uma máquina Linux real sob demanda, com uma microVM Firecracker por máquina. O README declara o requisito sem ambiguidades: "uma máquina Linux com /dev/kvm" e, mais precisamente, "Ubuntu 24.04, x86_64 ou arm64, com /dev/kvm (bare-metal ou uma VM com virtualização aninhada) à qual seja possível aceder por SSH como root".

A configuração documentada é executada com um comando nessa máquina:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

infra/setup.sh executa uma verificação preliminar por SSH e termina imediatamente quando a máquina não cumpre os requisitos. As duas recusas relacionadas com o hardware são:

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

A primeira mensagem é o ponto central deste artigo. O instalador faz a mesma pergunta que acabou de fazer com ls -l /dev/kvm e, na maioria dos planos VPS, obtém a mesma resposta dececionante.

Depois da verificação preliminar, trata-se de uma instalação completa na máquina: Firecracker e o seu jailer, uma toolchain Go, um kernel convidado e um sistema de ficheiros raiz, uma imagem convidada Python, uma imagem de desktop opcional com um browser e duas unidades systemd chamadas nehemiahd.service e boring-net.service. O daemon responde então na porta 8080, e uma verificação de integridade falhada apresenta /healthz didn't return ok. SKIP_DESKTOP=1 ignora a imagem de desktop, que, segundo o README, demora cerca de 8 minutos a ser criada.

Leia as ressalvas antes de colar esse comando

É necessário acesso SSH como root num host novo. O instalador escreve pacotes do sistema, unidades systemd e configuração de rede como root. Aponte-o para uma máquina que esteja disposto a reconstruir do zero, não para o servidor que já aloja o seu site.

O daemon associa-se a 0.0.0.0:8080 por predefinição. Qualquer pessoa que consiga aceder a essa porta pode criar máquinas, e essas máquinas consomem a chave do modelo que forneceu ao instalador. Defina NEHEMIAH_TOKEN para exigir autenticação ou defina BIND_LOCALHOST=1 para que o daemon se associe apenas a 127.0.0.1 e aceda a ele através de um túnel com ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. A chave exige o mesmo cuidado que qualquer outro segredo no sistema, tal como em manter segredos fora dos agentes de IA.

Cada máquina é um computador com acesso à Internet e agentes pré-instalados. O README lista claude, codex, cursor e pi dentro do guest, além de node, python e git. O projeto afirma que os guests ficam atrás de uma firewall de saída e que o próprio limite de isolamento é efetivo. O guest continua a aceder à rede por conceção, porque um agente de programação que não consiga obter um pacote não é útil. Planeie para esse cenário em vez de presumir que existe um air gap.

Não existe uma release etiquetada. Em 10 August 2026, o repositório não tinha quaisquer tags, por isso clonar main obtém tudo o que foi integrado nessa manhã. Fixe uma commit e leia o script antes de este ser executado como root no seu servidor:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

O repositório foi criado no final de June 2026, por isso trate-o como software recente. Leia infra/setup.sh novamente depois de cada atualização obtida, porque o que está a aprovar é acesso root a uma máquina, não uma atualização de versão de uma biblioteca.

Demonstre que o KVM funciona antes de culpar o instalador

Se a configuração falhar e quiser saber se a causa é o KVM, teste o Firecracker isoladamente. Estes são os passos de download do projeto upstream:

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

A apresentação da versão confirma que o binário corresponde à sua arquitetura e é executado. Não confirma o acesso ao KVM. Por isso, combine-a com o teste de leitura e escrita em /dev/kvm apresentado anteriormente. Em conjunto, os dois testes distinguem um problema de alojamento de um problema de empacotamento. Assim, evita depurar um instalador que estava correto desde o início.

De que servidor precisam várias microVMs?

Cada microVM inclui um kernel convidado real e a memória que lhe atribuir, e essa memória fica comprometida enquanto a máquina estiver em execução. Por isso, dimensione o host com base no tamanho dos convidados e no número que pretende executar em simultâneo. Os valores abaixo são cálculos, não medições. Um convidado sem interface gráfica recebe 1 GB e um convidado com desktop e navegador recebe 2 GB. O host mantém uma reserva fixa de 2 GB para si próprio, para o daemon e para a criação de imagens.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

Uma máquina sem interface gráfica em execução de cada vez precisa de cerca de 3 GB, o que um VPS de tamanho médio consegue suportar quando disponibiliza KVM. Quatro máquinas precisam de 6 GB. Execute 8 máquinas com desktop e o mesmo cálculo exige 18 GB antes de contabilizar um único gigabyte de disco.

O disco é o recurso que ninguém planeia corretamente. O host armazena um kernel convidado, um sistema de ficheiros raiz base, uma imagem por variante de convidado e um snapshot por máquina em execução. A imagem de desktop com navegador é a maior. O README não indica nenhum valor de disco, por isso monitorize df -h / durante a primeira criação, em vez de confiar numa estimativa.

É por isso que a resposta honesta à pergunta "que VPS executa Firecracker" é muitas vezes "uma classe diferente de máquina". O bare metal disponibiliza as flags do CPU sem um hypervisor no caminho. Essa é a principal diferença em escolher entre um VPS e um servidor dedicado. Alguns fornecedores disponibilizam virtualização aninhada em planos virtuais, e virtualização aninhada num VPS explica como confirmá-la antes de pagar. Se o hardware já lhe pertence, Proxmox em comparação com um VPS simples é a mesma questão vista do lado do hypervisor.

O servidor também é apenas a metade mais barata. Cada máquina que entrega a um agente consome tokens do modelo enquanto estiver em execução. Assim, uma microVM inativa consome memória, enquanto uma microVM ocupada consome memória e gera custos de API. Um plano de 1 GB não consegue suportar o host. Um plano que consiga suportar o host ainda não paga necessariamente a chave.

FAQ

Como verifico se o meu VPS pode executar o Firecracker?

Execute ls -l /dev/kvm, systemd-detect-virt e grep -cE '\b(vmx|svm)\b' /proc/cpuinfo no VPS. Um nó de dispositivo pertencente ao grupo kvm, juntamente com uma contagem de flags superior a zero, significa que o Firecracker pode ser executado. A ausência do nó, com uma contagem de 0, significa que o hypervisor não está a disponibilizar a virtualização, e sudo kvm-ok do pacote cpu-checker confirma isso com KVM acceleration can NOT be used. Em arm64, ignore a contagem, porque vmx e svm são nomes usados em x86.

Posso ativar a virtualização aninhada a partir do meu VPS?

Não. A virtualização aninhada é ativada pelo host, no módulo de kernel do próprio hypervisor, e chega até si como uma flag de CPU no processador virtual que lhe foi atribuído. Dentro do guest, sudo modprobe kvm_intel devolve modprobe: ERROR: could not insert 'kvm_intel': Operation not supported porque a CPU virtual não tem VMX disponível. As opções são escolher um fornecedor que ofereça virtualização aninhada no plano ou utilizar uma máquina na qual seja o proprietário do hypervisor.

Um contentor é suficiente para colocar um agente de programação numa sandbox?

Muitas vezes, sim. Um contentor partilha o seu kernel, portanto uma fuga ao nível do kernel chega ao host. No entanto, um contentor descartável numa máquina que não armazena credenciais valiosas elimina a maior parte do risco efetivo. Escolha uma microVM quando um agente executa tarefas sem supervisão durante longos períodos sobre código não revisto e quando lhe pode atribuir um host com /dev/kvm. Quando isso não for possível, um contentor que destrói após cada tarefa é melhor do que uma microVM que nunca consegue arrancar.

De quanta RAM precisa um host para agentes em microVM?

Comece pelo tamanho do guest. Um guest headless com 1 GB e uma reserva de 2 GB para o host precisa de cerca de 3 GB no total, e 8 guests desktop com 2 GB cada precisam de cerca de 18 GB. O disco é separado e é fácil subestimá-lo, porque o host mantém um kernel, sistemas de ficheiros root, uma imagem por variante de guest e um snapshot para cada máquina em execução.