Il tuo VPS supporta le microVM Firecracker?

Il tuo VPS può eseguire microVM Firecracker?

Il tuo VPS può eseguire microVM Firecracker solo se ti fornisce /dev/kvm. Firecracker è un VMM (virtual machine monitor) basato su KVM (kernel-based virtual machine), il livello di virtualizzazione integrato in Linux, e KVM richiede le istruzioni di virtualizzazione della CPU. Su un VPS queste istruzioni sono disponibili soltanto se il provider le espone al guest, ma la maggior parte dei piani non lo fa.

La prima domanda, quindi, non è quale strumento per microVM installare. Devi verificare se la macchina per cui paghi può effettivamente ospitarne una. È una questione legata al servizio di hosting e puoi trovare la risposta in circa un minuto.

Controlla /dev/kvm prima di installare qualsiasi componente

Esegui questi tre comandi direttamente sul VPS.

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

Un sistema in grado di ospitare microVM restituisce un output simile:

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

La prima riga mostra il device node KVM, appartenente al gruppo kvm. La seconda indica che questa macchina è a sua volta un guest eseguito su KVM. Su un VPS è un comportamento normale e previsto. La terza conta i core CPU che espongono il flag di virtualizzazione hardware: vmx su Intel e svm su AMD. Un valore maggiore di zero all'interno di un guest indica che l'hypervisor espone la virtualizzazione annidata.

Controlla quindi che il tuo utente possa aprire il device. Questo è il test riportato nella documentazione introduttiva di Firecracker:

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

FAIL mentre il node esiste indica un problema di permessi, non un problema hardware. Concedi l'accesso al tuo utente con sudo setfacl -m u:${USER}:rw /dev/kvm oppure aggiungilo al gruppo con sudo usermod -aG kvm ${USER}, quindi accedi di nuovo.

Ubuntu include anche un controllo che riassume tutto questo in due righe di output:

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

Un host funzionante stampa INFO: /dev/kvm exists e quindi KVM acceleration can be used. Un host che non può farlo stampa INFO: Your CPU does not support KVM extensions e quindi KVM acceleration can NOT be used. Su una macchina fisica potresti invece visualizzare INFO: KVM (vmx) is disabled by your BIOS, un problema risolvibile nel firmware. Su un VPS questo messaggio è raro, perché non stai accedendo al firmware reale.

Che cosa significa ciascuna risposta relativa a /dev/kvm?

Il nodo esiste e il conteggio dei flag è maggiore di zero. Disponi della virtualizzazione hardware, quindi Firecracker funzionerà. Passa alla sezione sul dimensionamento: il vincolo rimanente riguarda la memoria, non le funzionalità della CPU.

Nessun nodo, systemd-detect-virt restituisce kvm o qemu e il conteggio dei flag è 0. Il tuo VPS è una macchina virtuale il cui host non espone la virtualizzazione al guest. Nulla di ciò che installi nel guest può modificare questa situazione, perché il flag è una proprietà della CPU virtuale che l'hypervisor ha configurato per te. sudo modprobe kvm_intel non riesce con modprobe: ERROR: could not insert 'kvm_intel': Operation not supported e sudo dmesg | grep -i kvm registra l'assenza del supporto hardware. Questo è il caso più comune nei piani VPS condivisi. Chiedi al provider se il piano supporta la virtualizzazione annidata. Se la risposta è negativa, ti serve un altro servizio di hosting, non un comando diverso.

systemd-detect-virt restituisce lxc, lxc-libvirt o openvz. Il tuo piano usa la virtualizzazione tramite container, quindi condividi il kernel dell'host. /dev/kvm non comparirà mai, perché non disponi di un kernel autonomo in cui caricare un modulo. Anche in questo caso nessun pacchetto può risolvere il problema.

I flag sono presenti, ma il nodo non esiste. Semplicemente, il modulo non è caricato. Esegui sudo modprobe kvm_intel (oppure kvm_amd sui sistemi AMD) e controlla di nuovo ls -l /dev/kvm. Se il nodo compare, inserisci il nome del modulo in /etc/modules-load.d/kvm.conf, così verrà caricato nuovamente dopo un riavvio.

Usi arm64. vmx e svm sono nomi x86, quindi il conteggio di grep è 0 su ogni macchina arm64, indipendentemente dal fatto che funzioni o meno. Su arm64, fai riferimento al nodo del dispositivo e al test di lettura e scrittura.

Perché usare una microVM invece di un container per il lavoro degli agenti

Un container è un processo eseguito sul kernel del sistema, isolato tramite namespace e cgroup. Il kernel è uno solo ed è quello dell'host, quindi un'eventuale evasione a livello di kernel consente di raggiungere l'host. Una microVM avvia un proprio kernel all'interno di un confine di virtualizzazione hardware e comunica con un modello di dispositivi emulati ridotto, invece di accedere all'intera superficie delle system call dell'host. Firecracker mantiene deliberatamente ridotto questo modello: è questo il principio progettuale. Meno dispositivi emulati significano meno possibilità di evasione.

Questa differenza è importante per un coding agent, perché il codice eseguito da un agente non è stato necessariamente esaminato da una persona. L'agente installa pacchetti, esegue script di build e ritenta alla velocità della macchina quando qualcosa non funziona. Un kernel separato fa sì che un'operazione errata danneggi una macchina che si può eliminare, senza coinvolgere il resto del sistema.

Il requisito deriva direttamente dal meccanismo. L'isolamento hardware richiede la virtualizzazione hardware, ma il piano VPS in uso potrebbe non fornirla. Un container non richiede nulla di tutto questo, ed è per questo che i container funzionano con qualsiasi piano mai offerto.

Quando quindi manca /dev/kvm, la VM usa e getta per coding agent basata su container resta la soluzione corretta ed è una misura di controllo effettiva, non un ripiego. Un container temporaneo, su un host che non contiene credenziali importanti, ripristinato da uno snapshot ogni volta che si comporta in modo anomalo, blocca la maggior parte dei problemi che si verificano realmente. Lo stesso vale per la configurazione più semplice descritta in eseguire un coding agent su un VPS. Scegli una microVM quando un agente deve essere eseguito senza supervisione per ore, su codice che non hai esaminato, e quando puoi mettere a disposizione l'host per questo scopo.

Cosa richiede un host per agent microVM

Nehemiah è un esempio attuale di questa categoria: un daemon con licenza Apache-2.0 che fornisce on demand a un sistema AI una macchina Linux reale, con una microVM Firecracker per ogni macchina. Il README dichiara il requisito senza ambiguità: «un sistema Linux con /dev/kvm» e, più precisamente, «Ubuntu 24.04, x86_64 o arm64, con /dev/kvm (bare metal oppure una VM con virtualizzazione annidata) a cui sia possibile accedere tramite SSH come root».

La configurazione documentata consiste nell'eseguire un comando su quel sistema:

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 esegue un controllo preliminare tramite SSH e si interrompe subito se il sistema non soddisfa i requisiti. I due rifiuti relativi all'hardware sono:

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

La prima stringa è il punto centrale di questo articolo. L'installer pone la stessa domanda appena verificata con ls -l /dev/kvm e, nella maggior parte dei piani VPS, riceve la stessa risposta deludente.

Superato il controllo preliminare, viene installato l'intero ambiente: Firecracker e il relativo jailer, una toolchain Go, un kernel guest e un filesystem root, un'immagine guest Python, un'immagine desktop opzionale con un browser e due unità systemd denominate nehemiahd.service e boring-net.service. Il daemon risponde quindi sulla porta 8080 e, se il controllo dello stato non riesce, stampa /healthz didn't return ok. SKIP_DESKTOP=1 esclude l'immagine desktop, che secondo il README richiede circa 8 minuti per la compilazione.

Leggere le avvertenze prima di incollare il comando

Richiede l'accesso SSH come root su un host appena installato. L'installer scrive pacchetti di sistema, unità systemd e configurazione di rete con privilegi root. Usalo su una macchina che sei disposto a ricreare da zero, non sul server che esegue già il tuo sito.

Il daemon è in ascolto su 0.0.0.0:8080 per impostazione predefinita. Chiunque raggiunga quella porta può creare macchine, che utilizzeranno la model key fornita all'installer. Imposta NEHEMIAH_TOKEN per richiedere l'autenticazione oppure imposta BIND_LOCALHOST=1 in modo che il daemon sia in ascolto solo su 127.0.0.1 e accedi tramite un tunnel con ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. La key richiede la stessa protezione di qualsiasi altro secret sul sistema, come descritto in non inserire secret negli agenti AI.

Ogni macchina è un computer con accesso a Internet e agenti preinstallati. Il README elenca claude, codex, cursor e pi all'interno del guest, oltre a node, python e git. Il progetto dichiara che i guest sono protetti da un firewall per il traffico in uscita e che il confine di isolamento è effettivo. Per progettazione, tuttavia, il guest può ancora raggiungere la rete, perché un agente di coding che non può scaricare un pacchetto è inutile. Pianifica di conseguenza invece di presumere l'esistenza di un air gap.

Non esiste alcuna release contrassegnata. Al 10 agosto 2026 il repository non contiene tag, quindi il cloning di main recupera qualsiasi contenuto sia stato aggiunto quella mattina. Fissa un commit e leggi lo script prima che venga eseguito con privilegi root sul server:

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

Il repository è stato creato alla fine di giugno 2026, quindi consideralo software ancora giovane. Rileggi infra/setup.sh dopo ogni aggiornamento che scarichi, perché ciò che stai autorizzando è l'accesso root a una macchina, non un semplice aggiornamento della versione di una libreria.

Verifica che KVM funzioni prima di attribuire il problema all’installer

Se la configurazione non riesce e vuoi sapere se la causa è KVM, testa Firecracker separatamente. Questi sono i passaggi di download del progetto 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

La stampa della versione dimostra che il binario corrisponde alla tua architettura e viene eseguito. Non dimostra che sia possibile accedere a KVM, quindi affiancala al test di lettura e scrittura su /dev/kvm descritto in precedenza. Insieme, i due test distinguono un problema dell’hosting da un problema del pacchetto. In questo modo eviti di eseguire il debug di un installer che funzionava correttamente.

Di quante risorse ha bisogno un server per diverse microVM?

Ogni microVM include un kernel guest reale e la memoria assegnata, che resta riservata finché la macchina è in esecuzione. Quindi, dimensiona l'host in base alle dimensioni dei guest e al numero di macchine che vuoi eseguire contemporaneamente. I valori riportati di seguito sono calcoli aritmetici, non misurazioni. Un guest senza interfaccia grafica richiede 1 GB, mentre un guest desktop con browser richiede 2 GB. L'host riserva 2 GB fissi per il sistema, il daemon e la creazione delle immagini.

[
  {
    "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
  }
]

Una macchina senza interfaccia grafica alla volta richiede circa 3 GB; questa quantità è gestibile da un VPS di fascia media che fornisca KVM. Quattro macchine richiedono 6 GB. Esegui 8 macchine desktop e lo stesso calcolo richiede 18 GB, senza considerare un solo gigabyte di spazio su disco.

Lo spazio su disco è la risorsa che spesso non viene pianificata. L'host memorizza un kernel guest, un filesystem root di base, un'immagine per ogni variante di guest e uno snapshot per ogni macchina in esecuzione; l'immagine desktop con browser è quella più grande. Il README non indica alcun valore per lo spazio su disco, quindi monitora df -h / durante la prima creazione invece di affidarti a una stima.

Per questo la risposta corretta alla domanda «quale VPS esegue Firecracker?» è spesso «una macchina di un'altra categoria». Il bare metal offre i flag della CPU senza un hypervisor interposto; questo è il compromesso descritto in scegliere tra un VPS e un server dedicato. Alcuni provider espongono la virtualizzazione annidata nei piani virtuali; virtualizzazione annidata su un VPS spiega come verificarne la disponibilità prima dell'acquisto. Se l'hardware è già tuo, Proxmox rispetto a un VPS semplice affronta la stessa questione dal punto di vista dell'hypervisor.

Il server è anche la parte meno costosa. Ogni macchina assegnata a un agente consuma token del modello per tutto il tempo in cui resta in esecuzione. Una microVM inattiva consuma memoria, mentre una microVM occupata consuma memoria e genera costi API. Un piano da 1 GB non può contenere l'host. Un piano abbastanza grande da contenere l'host potrebbe comunque non coprire il costo della chiave.

FAQ

Come verifico se il mio VPS può eseguire Firecracker?

Esegui ls -l /dev/kvm, systemd-detect-virt e grep -cE '\b(vmx|svm)\b' /proc/cpuinfo sul VPS. Un nodo dispositivo appartenente al gruppo kvm, insieme a un conteggio dei flag superiore a zero, indica che Firecracker può essere eseguito. L'assenza del nodo con un conteggio pari a 0 indica che l'hypervisor non sta esponendo la virtualizzazione al guest; sudo kvm-ok del pacchetto cpu-checker lo conferma con KVM acceleration can NOT be used. Su arm64, ignora il conteggio, perché vmx e svm sono nomi x86.

Posso abilitare la virtualizzazione annidata dall'interno del mio VPS?

No. La virtualizzazione annidata viene abilitata dall'host, nel modulo del kernel dell'hypervisor, e raggiunge il guest sotto forma di flag della CPU virtuale assegnata. Nel guest, sudo modprobe kvm_intel restituisce modprobe: ERROR: could not insert 'kvm_intel': Operation not supported perché la CPU virtuale non dispone di VMX da utilizzare. Le opzioni sono scegliere un provider che offra la virtualizzazione annidata nel piano oppure una macchina sulla quale gestisci direttamente l'hypervisor.

Un container è sufficiente per isolare un agente di coding?

Spesso sì. Un container condivide il kernel, quindi un'escape a livello di kernel raggiunge l'host; tuttavia, un container usa-e-getta su una macchina che non contiene credenziali importanti elimina gran parte del rischio effettivo. Scegli una microVM quando un agente viene eseguito senza supervisione per periodi prolungati su codice non verificato e quando puoi assegnargli un host con /dev/kvm. Quando non è possibile, un container che elimini dopo ogni attività è preferibile a una microVM che non riesci mai ad avviare.

Quanta RAM richiede l'host di un agente basato su microVM?

Parti dalle dimensioni del guest. Un guest headless da 1 GB con una riserva di 2 GB per l'host richiede complessivamente circa 3 GB, mentre 8 guest desktop da 2 GB ciascuno richiedono circa 18 GB. Lo spazio su disco è un requisito distinto e viene facilmente sottostimato, perché l'host conserva un kernel, i root filesystem, un'immagine per ogni variante di guest e uno snapshot per ogni macchina in esecuzione.