Far girare Proxmox su VPS: è possibile?

La risposta breve

La virtualizzazione annidata consiste nell'esecuzione di un hypervisor all'interno di una macchina virtuale: il VPS è già un guest e si desidera che ospiti altri guest. Questa funzione è attiva solo se l'hypervisor del provider espone deliberatamente le estensioni di virtualizzazione della CPU all'istanza. Verificare la presenza del flag vmx (Intel) o svm (AMD) in /proc/cpuinfo; se nessuno dei due è presente, nessuna configurazione interna al VPS può risolvere il problema.

Nota preliminare: Docker non richiede questa funzione. I container condividono il kernel del VPS e non interagiscono mai con /dev/kvm. Se l'obiettivo è "eseguire diversi servizi in container sul server", le risorse attuali sono sufficienti. La virtualizzazione annidata è necessaria solo se si richiede un secondo kernel: un lab Proxmox, un guest Windows, microVM Firecracker, un emulatore Android, un ambiente di test Kubernetes con VM reali o runner CI che avviano immagini VM.

Cosa viene effettivamente annidato

Tre livelli:

• L0 — l'hypervisor del provider, sull'hardware fisico. Non hai accesso a questo livello.
• L1 — il tuo VPS. Per L0, questo è solo un guest.
• L2 — la VM che vuoi eseguire all'interno del tuo VPS.

La virtualizzazione hardware è composta da VT-x (il flag vmx) più EPT su Intel, e AMD-V / SVM (svm) più RVI/NPT su AMD. Un hypervisor utilizza queste istruzioni per entrare in guest mode e per permettere alla CPU di scorrere due page table contemporaneamente.

Nessuna delle due tecnologie è stata progettata per essere re-entrante, quindi l'annidamento viene emulato: quando L1 esegue un'istruzione VMX, questa viene intercettata da L0, che mantiene le shadow structures per L2 per conto di L1. KVM gestisce bene questo processo, ma L0 deve eseguire lavoro extra ad ogni exit — motivo per cui il provider deve abilitare esplicitamente l'opzione.

Per avere un L2 accelerato devono verificarsi entrambe le seguenti condizioni:

1. Il modulo KVM di L0 è caricato con nested=1.
2. L0 assegna al tuo VPS un modello CPU che include il flag — <cpu mode='host-passthrough'/> in libvirt, cpu: host in Proxmox, -cpu host in QEMU raw. Un modello emulato generico (qemu64, kvm64) nasconde vmx anche se l'annidamento è abilitato globalmente.

Controlla il tuo VPS in un minuto

# 1. Are you in a VM, and under what?
systemd-detect-virt          # kvm, vmware, xen, microsoft, or "none" on metal

# 2. Does the CPU expose the extensions to you?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i -E 'virtual|hypervisor'

# 3. The definitive check
sudo apt update && sudo apt install -y cpu-checker
kvm-ok

# 4. The device node the whole stack depends on
ls -l /dev/kvm

Un'istanza funzionante stampa vmx o svm, kvm-ok riporta KVM acceleration can be used, e /dev/kvm esiste in modalità root:kvm 660. Se il flag è presente ma il nodo del dispositivo manca, carica il modulo manualmente e leggi il log del kernel:

sudo modprobe kvm_intel     # or kvm_amd
sudo dmesg | tail -n 20

Un file viene citato spesso ma viene interpretato male:

cat /sys/module/kvm_intel/parameters/nested   # Y or N

All'interno del tuo VPS questo è il parametro del tuo modulo KVM, e determina se un guest L2 può eseguire il nesting di un terzo livello. Non indica se L0 ha abilitato il nesting per te — /proc/cpuinfo e kvm-ok forniscono questa informazione. Il parametro nested è il valore da impostare su una macchina di tua proprietà:

echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

La rimozione del modulo viene rifiutata se una VM è in esecuzione; arresta prima i guest.

Perché la maggior parte degli host VPS lo disabilita

• Live migration. Fornire vmx significa esporre un modello di CPU che include il flag; un guest che dipende da tali funzionalità CPU non può essere migrato in sicurezza su una macchina la cui CPU non le possiede. Un host che svuota i nodi tramite migrazione deve rinunciare a questa funzione non appena abilita il nesting.
• Superficie di attacco. I percorsi nested VMX/SVM sono tra i segmenti di codice più complessi nel layer di virtualizzazione del kernel e presentano una storia di CVE rilevanti.
• L0 potrebbe non essere KVM. Se systemd-detect-virt stampa vmware, xen o microsoft, le regole di nesting appartengono a quello stack e non a KVM.

Nessun flag sulla tua istanza? Contatta il supporto (alcuni lo abilitano per singola VM), scegli un piano che documenti il nesting o passa a un server dedicato. Il resto di questa guida assume l'accesso root su una macchina che mostra il flag.

Esecuzione di un guest L2 con libvirt

sudo apt install -y qemu-system-x86 libvirt-daemon-system virtinst ovmf
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # log out and back in

virt-install \
  --name guest1 \
  --memory 2048 \
  --vcpus 2 \
  --cpu host-passthrough \
  --disk path=/var/lib/libvirt/images/guest1.qcow2,size=20,format=qcow2,bus=virtio \
  --network network=default,model=virtio \
  --os-variant debian13 \
  --location https://deb.debian.org/debian/dists/trixie/main/installer-amd64/ \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

Non è necessaria una sessione grafica. L'installazione seriale richiede tempo, quindi avviarla all'interno di una shell persistente: lo stesso workflow tmux che mantiene attive le sessioni Claude Code su un VPS mantiene una console virt-install collegata anche in caso di disconnessione SSH. Se --os-variant debian13 viene rifiutato, la versione di osinfo-db è precedente al rilascio — esegui osinfo-query os e scegli un nome esistente. --cpu host-passthrough inoltra vmx verso il livello L2; questa operazione è necessaria solo se l'L2 deve a sua volta virtualizzare. Rendi il guest sicuro per il boot utilizzando virsh autostart guest1.

Il bus virtio su disco e NIC non è puramente estetico: i dispositivi emulati IDE ed e1000 generano trap verso l'hypervisor molto più frequentemente rispetto alle code virtio; in modalità nesting, ogni trap comporta un doppio costo computazionale.

Networking: la parte che i tutorial saltano

Il VPS dispone di un unico IP pubblico ed è posizionato dietro un fabric che filtra gli indirizzi MAC sconosciuti. Ciò comporta due conseguenze.

Il bridging L2 degli ospiti sulla rete pubblica solitamente non funziona. Se si imposta br0 sulla NIC pubblica e si assegna all'ospite un proprio MAC, le richieste ARP verranno inviate ma non riceveranno risposta: lo switch del provider scarta i frame provenienti da un MAC che non è stato assegnato. Se si riscontra questo problema, interrompere il debugging del bridge; questo è il comportamento previsto.

Utilizzare invece la rete NAT. libvirt include default: virbr0, 192.168.122.0/24 e lease dnsmasq; la connettività in uscita è immediata. Per la connettività in entrata, terminare il TLS su L1 e utilizzare un proxy — i percorsi dei certificati riportati di seguito derivano da l'emissione di un certificato Let's Encrypt con Certbot su Nginx:

server {
    listen 443 ssl;
    server_name lab.example.com;

    ssl_certificate     /etc/letsencrypt/live/lab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.example.com/privkey.pem;

    location / {
        proxy_pass http://192.168.122.50:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Assegnare all'ospite un lease statico (virsh net-edit default) affinché l'indirizzo in quel proxy_pass rimanga invariato.

Le interfacce di gestione non devono essere esposte su internet: VNC sulla porta 5900 e la web UI di Proxmox sulla porta 8006 devono essere configurate su loopback, accessibili tramite un tunnel SSH (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) o tramite una VPN WireGuard self-hosted verso il VPS, che posiziona l'intero range degli ospiti 192.168.122.0/24 a un solo salto privato di distanza. Configurare il firewall in modo restrittivo — sudo ufw allow 22,80,443/tcp, nient'altro. Se gli ospiti perdono la connettività in uscita subito dopo l'attivazione di ufw, il colpevole abituale è DEFAULT_FORWARD_POLICY="DROP" in /etc/default/ufw — impostarlo a ACCEPT e ricaricare ufw.

Proxmox su un VPS

Proxmox VE 9 si basa su Debian 13. Per installarlo su un VPS Debian, è necessario aggiungere il repository pve-no-subscription e il pacchetto proxmox-ve. Utilizza le righe relative al repository e al keyring presenti nella documentazione ufficiale di Proxmox; un URL copiato da un vecchio post di un blog causa il fallimento dell'installazione.

I pacchetti non sono la parte difficile. Proxmox richiede un bridge vmbr0 collegato a una NIC fisica, il che causa il problema del filtraggio MAC descritto sopra. La configurazione funzionante su un VPS è un bridge vmbr0 tramite NAT o routing senza porte fisiche collegate. Gli ospiti devono essere su un range privato. Per il traffico pubblico, utilizzare regole DNAT o un reverse proxy sull'host. Se i servizi pubblici sono container invece di VM, Traefik che gestisce più app da un unico file Docker Compose svolge la stessa funzione di routing con certificati automatici. Esegui prima uno snapshot /etc/network/interfaces: una definizione errata del bridge può impedire l'accesso a una macchina di cui non si dispone della console.

Performance, dichiarata con onestà

La virtualizzazione nested è più lenta rispetto a quella a singolo livello. Il motivo è specifico: il costo non è dovuto all'accesso alla memoria, ma alle uscite (exits). Con l'uso di EPT/NPT, L0 mantiene le shadow page tables per L2 e le letture di memoria ordinarie avvengono alla velocità dell'hardware. Il costo aumenta per ogni operazione che esce dalla guest mode — I/O, timer interrupts, MMIO, inter-processor interrupts — poiché ogni L2 exit viene gestita da L0 e può essere riflessa attraverso L1. I carichi di lavoro CPU-bound su dati già presenti in RAM sono simili alle prestazioni native; qualsiasi attività dominata da syscall, pacchetti e I/O disco risente dei livelli di virtualizzazione.

In sintesi: utilizzare dispositivi virtio ovunque. Il file qcow2 risiede su un disco che il provider ha già virtualizzato: due livelli di thin-provisioning sovrapposti, dove cache=none sul disco guest evita che gli stessi blocchi risiedano in due page cache contemporaneamente. Non vengono forniti dati di benchmark: misurare il proprio carico di lavoro sulla propria istanza.

Modalità di errore e stringhe visualizzate

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used da kvm-ok. Il modulo non è caricato o il flag non è esposto. Controllare prima /proc/cpuinfo.

kvm: disabled by bios in dmesg. Su bare metal, attivare l'opzione VT-x/SVM nel firmware. In un VPS significa che L0 non fornisce le estensioni; nessuna configurazione nel guest può risolvere il problema.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. La CPU rilevata dal kernel non ha vmx — si tratta di una decisione di L0.

Could not access KVM kernel module: Permission denied. Problema di permessi, non di hardware. ls -l /dev/kvm dovrebbe mostrare il gruppo kvm e la modalità 660; aggiungere l'utente al gruppo e avviare una nuova shell di login, poiché l'appartenenza al gruppo non si applica a sessioni già attive.

kvm: Device or resource busy all'avvio di QEMU. Un altro modulo hypervisor occupa la CPU: eseguire lsmod, cercare vboxdrv o moduli VMware insieme a kvm_intel, e scaricare il modulo non desiderato.

/var/run/libvirt/libvirt-sock: No such file or directory da virsh. Il daemon è spento: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. Un guest ha l'accelerazione KVM attiva su un host che non può fornirla. Configurare correttamente il nesting, oppure disattivare l'opzione e accettare l'emulazione.

Android emulator: x86_64 emulation currently requires hardware acceleration! di nuovo /dev/kvm — solitamente un problema di gruppo.

Nessun errore, ma prestazioni estremamente lente. QEMU senza flag di accelerazione utilizza TCG, il suo emulatore software. Il funzionamento è corretto ma lento: un avvio di pochi secondi può richiedere minuti. Passare esplicitamente -accel kvm, in modo che QEMU restituisca un errore invece di procedere con l'emulazione silenziosa.

Il guest scompare durante l'esecuzione. Controllare dmesg per Out of memory: Killed process ... qemu-system-x86_64. Un guest L2 è un processo su L1, e l'OOM killer lo tratta come qualsiasi altro processo. La RAM del guest L2 proviene dall'allocazione fissa di L1 — non può essere prelevata dall'host.

Operating it: backups, upgrades, limits

Backups. Copiare il file qcow2 di un guest in esecuzione produce un'immagine corrotta. È necessario eseguire virsh shutdown guest1 e copiare, oppure scattare uno snapshot esterno (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) per reindirizzare le scritture su un overlay durante la copia della base statica, per poi reintegrarla con virsh blockcommit. Trasferire le copie fuori dal VPS: uno snapshot sullo stesso disco non offre alcuna protezione.

Upgrades. apt full-upgrade installa i nuovi moduli kvm_intel/kvm_amd, ma il kernel in esecuzione mantiene i vecchi moduli fino al reboot. Mantenere il kernel precedente installato ed eseguire nuovamente kvm-ok dopo ogni modifica al kernel: un host che riavvia senza vmx richiede un'unica voce di avvio per tornare operativo.

Limiti di scalabilità. Un singolo IP pubblico implica che ogni servizio L2 raggiunga il mondo esterno tramite un proxy o una regola DNAT su L1. La live migration non è disponibile. In caso di contesa della CPU, il percorso di nested exit è il primo elemento a risentirne. Un hypervisor con diversi guest consuma la RAM disponibile; le VM nidificate non possono superare l'allocazione fissa tramite overcommit. Quando un lab supera queste capacità, la soluzione non è aumentare lo stack nidificato; serve un server dedicato dove si opera a livello L0 e dove queste limitazioni non si applicano.

FAQ

È necessaria la virtualizzazione nidificata per eseguire Docker su un VPS?

No. I container condividono il kernel del VPS e non aprono mai /dev/kvm. Un'istanza standard senza flag vmx o svm esegue correttamente Docker e Docker Compose. La nidificazione è necessaria solo se è richiesto un secondo kernel: ad esempio per un lab Proxmox, un guest Windows, microVM Firecracker, un emulatore Android o runner CI che avviano immagini VM.

Come posso verificare se il mio VPS supporta la virtualizzazione nidificata?

Esegui grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, quindi kvm-ok dal pacchetto cpu-checker. Un'istanza utilizzabile stampa vmx (Intel) o svm (AMD); kvm-ok riporta KVM acceleration can be used, e /dev/kvm esiste con gruppo kvm e modalità 660. Ignora /sys/module/kvm_intel/parameters/nested per questa verifica: quel file descrive il modulo KVM locale, non ciò che l'hypervisor del provider espone all'utente.

Perché la maggior parte dei provider VPS disabilita la virtualizzazione nidificata?

Esporre vmx significa assegnare al guest un modello di CPU che include il flag. Un guest che dipende da tali funzionalità CPU non può essere sottoposto a live-migration su una macchina il cui CPU non le possiede; i provider che spostano i clienti tra i nodi disabilitano questa funzione. I percorsi di codice VMX/SVM nidificati presentano inoltre una lunga cronologia di CVE. Alcuni host la abilitano per singola VM su richiesta, altri la indicano come funzionalità pianificata.

La mia VM nidificata non ha rete sul bridge pubblico. Qual è il problema?

Lo switch del provider scarta i frame provenienti da un indirizzo MAC che non è stato assegnato. Un guest L2 collegato tramite bridge alla NIC pubblica invia pacchetti ARP ma non riceve risposte. Non tentare il debugging di br0: utilizza la rete NAT default di libvirt (virbr0, 192.168.122.0/24), assegna al guest un indirizzo statico e pubblica il traffico pubblico tramite un reverse proxy o una regola DNAT sul VPS stesso.

Quanto è più lenta una VM nidificata?

Il calo di prestazioni dipende dai VM exits, non dall'accesso alla memoria. Con EPT/NPT attivo, le normali operazioni di lettura e scrittura all'interno di L2 avvengono alla velocità dell'hardware; l'I/O, gli interrupt del timer, MMIO e IPI sono gestiti da L0 e possono essere rimandati attraverso L1. I carichi di lavoro CPU-bound con dati già in RAM sono simili alle prestazioni native; i carichi pesanti in termini di syscall, pacchetti e disco risentono di ogni livello. Utilizza dispositivi virtio ovunque e cache=none sui dischi del guest, quindi misura il tuo specifico carico di lavoro.