Proxmox VE 9.2 Arm64: 5 limiti tecnici per il tuo homelab

Proxmox VE 9.2 aggiunge ufficialmente il supporto Arm64

Per anni, il sogno di un homelab completamente ARM è rimasto una promessa frustrante. Abbiamo visto tentativi di porting, fork non mantenuti e adattamenti fragili su Raspberry Pi o SBC generici. Con l’annuncio di agosto 2026, Proxmox Server Solutions ha finalmente chiuso il cerchio, rilasciando il supporto ufficiale per l’architettura Arm64 in Proxmox Virtual Environment (VE) 9.2. Questa non è una beta sperimentale: è un rilascio basato su Debian GNU/Linux 13.5 “Trixie” con kernel Linux 7.0, che condivide lo stesso codice, le stesse repository e il ciclo di vita della versione x86.

Tuttavia, come operatori di infrastruttura, sappiamo che la parità di codice non implica parità di esperienza. La notizia ha generato entusiasmo immediato tra gli appassionati di edge computing e virtualizzazione, ma ha anche innescato una corsa frenetica alla verifica della compatibilità hardware. La realtà operativa è più sfumata: il supporto è reale, ma è vincolato a requisiti architetturali specifici che escludono implicitamente gran parte dell’hardware ARM consumer attualmente disponibile. La domanda cruciale per chi gestisce un cluster domestico non è “Proxmox gira su ARM?”, ma “il mio hardware può gestire le complessità di UEFI, ACPI e l’assenza di funzionalità x86 legacy?”.

Fondamenta tecniche: Debian 13.5, Kernel 7.0 e codebase condivisa

La decisione di allineare la versione Arm64 alla stack software x86 è strategicamente intelligente. Proxmox VE 9.2 Arm64 utilizza QEMU 11.0 per le macchine virtuali, LXC 7.0 per i container e OpenZFS 2.4 per la gestione dello storage. Questo significa che l’interfaccia web, la gestione del software-defined networking e le funzioni di clustering HA funzionano identicamente a quelle che conosciamo su x86.

Questa uniformità riduce drasticamente l’attrito cognitivo per i DevOps. Non è necessario imparare un nuovo sistema di gestione o adattarsi a differenze nell’API. Tuttavia, la condivisione del codice nasconde insidie tecniche. Le dipendenze software che diamo per scontate su x86, come specifici moduli kernel per la virtualizzazione o librerie di accelerazione hardware, potrebbero non avere equivalenti diretti o performanti sull’architettura ARMv9-A. La stabilità del rilascio dipende dalla maturità del driver stack ARM, che è ancora in fase di consolidamento rispetto ai decenni di ottimizzazione x86.

Supporto hardware ufficiale: Nvidia Grace Hopper e Vera

È fondamentale leggere i dettagli del supporto hardware con attenzione critica. Inizialmente, il supporto ufficiale è focalizzato su sistemi server con architetture Nvidia Grace Hopper e Nvidia Vera, sviluppate in collaborazione con Nvidia e Supermicro. La piattaforma è stata validata specificamente sui sistemi Nvidia Grace Hopper Superchip (GH200).

Questi non sono dispositivi economici o accessibili a un tipico homelab. Il GH200 è un superchip ARMv9-A compatibile con 72 core ARM Neoverse V2, fino a 480 GB di memoria LPDDR5X e una GPU Nvidia H100 integrata. I server GH200 partono da circa 40.000 Euro. Questo indica chiaramente che il target primario di Proxmox per l’ARM sono i data center ad alte prestazioni e l’AI inference, non il Raspberry Pi del cassetto.

Esiste un supporto “best-effort” per altre hardware ARMv9-A o più recenti che rispettino i requisiti UEFI/ACPI, e in generale i sistemi ARMv8-A possono funzionare se configurati correttamente. Sono state testate piattaforme come Ampere Altra Dev Platform, Minisforum MS-R1, Radxa Orion O6 e Framework AI PC Mainboard. Se possiedi uno di questi dispositivi, hai una strada percorribile. Se hai un SBC generico, sei fuori dalla copertura ufficiale.

Limitazioni chiave: No SeaBIOS, No Live Migration e funzionalità x86 mancanti

Qui risiede il vero “gotcha” per chi pianifica una migrazione. L’architettura ARM impone vincoli tecnici che Proxmox non può aggirare magicamente. Le VM Arm64 possono avviarsi esclusivamente tramite UEFI utilizzando AAVMF (ARM Architecture Virtual Machine Firmware). SeaBIOS, il firmware legacy spesso usato per la compatibilità con OS vecchi o specifici tool di boot, non è disponibile.

Questo ha conseguenze pratiche:

• Assenza di funzionalità x86 specifiche: Caratteristiche come AMD SEV (Secure Encrypted Virtualization) e Intel GVT-g (vGPUs) sono semplicemente non disponibili. Se la tua sicurezza dipende dall’isolamento hardware della memoria o dalla virtualizzazione GPU specifica Intel, l’ARM non è un’opzione.
• Nessuna Live Migration tra architetture: È tecnicamente impossibile migrare a caldo una VM da un host x86 a un host Arm64. Questo spezza qualsiasi strategia di failover eterogeneo o bilanciamento del carico ibrido tra architetture diverse. Il cluster deve essere omogeneo per quanto riguarda l’architettura della CPU.
• Bootloader e compatibilità guest: Gli utenti hanno segnalato problemi minori nell’installazione di specifiche distribuzioni Linux ARM64 (ad esempio Ubuntu 24.04.1) via live CD all’interno delle VM. Questo suggerisce che, sebbene il supporto host sia ufficiale, l’ecosistema delle immagini guest ARM64 ottimizzate per Proxmox è ancora in fase di stabilizzazione.

Implicazioni per l’Home Lab: requisiti UEFI/ACPI e compatibilità SBC

Il requisito più escludente per i homelabber è l’obbligo di boot tramite UEFI e la descrizione dell’hardware via ACPI. Molti Single Board Computers (SBC), incluso il popolare Raspberry Pi, utilizzano un device tree per descrivere l’hardware e non dispongono di un’implementazione UEFI/ACPI standard completa per il boot del sistema operativo host. Pertanto, il Raspberry Pi non è ufficialmente supportato.

La comunità ha tentato adattamenti e fork, ma questi non ricevono supporto ufficiale e possono rompersi con gli aggiornamenti. Per il homelab, questo significa che l’ingresso di Proxmox su ARM non è una democratizzazione immediata. È un’apertura verso server ARM economici ma “enterprise-lite” (come i sistemi basati su Ampere o i nuovi mini-PC ARM con UEFI), non verso il giocattolo da 50 Euro.

Per chi gestisce un’infrastruttura di edge computing, questo cambio di paradigma richiede una revisione dell’hardware. Se si vuole usare Proxmox ufficiale, bisogna investire in hardware che rispetti gli standard di boot moderni (UEFI/ACPI), il che spesso significa spendere di più rispetto a un SBC generico, ma ottenere in cambio la stabilità e il supporto ufficiale.

Installazione e configurazione delle VM guest su Arm64

Se disponete di hardware compatibile (UEFI/ACPI, ARMv8-A o superiore), l’installazione è sorprendentemente familiare. Si utilizza il ISO installer standard, e il processo è identico a quello x86. La complessità si sposta sulla configurazione delle VM guest.

È cruciale assicurarsi che tutte le immagini delle VM siano compatibili con ARM64. Non è possibile eseguire immagini x86_64 su un host Arm64 senza emulazione QEMU (che è lenta e inadatta alla produzione). La strategia di migrazione da x86 ad ARM non è una migrazione “lift and shift”; è una ricostruzione dell’ambiente software. Ogni servizio, ogni dipendenza, ogni script deve essere compilato o distribuito per l’architettura ARM.

La lezione operativa è chiara: il supporto ARM di Proxmox è un’opportunità per ottimizzare il rapporto costo-prestazioni in scenari specifici (come l’inference AI o i carichi web statici), ma non è un sostituto drop-in per l’infrastruttura x86 esistente. La migrazione richiede una pianificazione attenta della supply chain software e una verifica rigorosa della compatibilità delle immagini guest.

Conclusioni: il costo reale dell’architettura ibrida

L’aggiunta del supporto Arm64 ufficiale in Proxmox VE 9.2 è un passo maturo per la piattaforma, ma non è una rivoluzione per l’utente medio di homelab. È una validazione per i data center che cercano alternative ARM ad alte prestazioni e per i professionisti che possono investire in hardware compatibile UEFI/ACPI.

Per il CTO o l’ingegnere DevOps, la decisione di adottare Proxmox su ARM deve essere guidata da una valutazione TCO (Total Cost of Ownership) che includa il costo dell’hardware compatibile e lo sforzo di riadattamento delle immagini guest. La sovranità dell’architettura è interessante, ma la stabilità operativa è prioritaria. Fino a quando l’ecosistema delle immagini ARM64 non sarà maturo quanto quello x86, la coesistenza di cluster omogenei (x86 da una parte, ARM dall’altra) rimarrà la strategia più sicura.

State valutando l’adozione di hardware ARM per il vostro cluster Proxmox? Quali sono i vincoli di compatibilità che vi hanno fermato? La maturità dell’hardware UEFI/ACPI ARM è sufficiente per la vostra infrastruttura, o siete ancora bloccati dai limiti dei SBC tradizionali?