Proxmox
Proxmox: perché la CPU può bloccare la migrazione di una VM
Due nodi possono appartenere allo stesso cluster ma offrire funzioni CPU differenti. Il modello assegnato alla macchina virtuale determina quanta portabilità resta disponibile.
La CPU virtuale è un contratto con il sistema ospite
Una macchina virtuale non vede necessariamente tutte le caratteristiche del processore fisico. QEMU presenta al sistema operativo ospite un modello CPU con un insieme preciso di funzioni, chiamate anche flag. Questa scelta influenza compatibilità, prestazioni e possibilità di spostare la VM. Alla data del 2 novembre 2026, Proxmox VE 9.2 è la versione ISO corrente indicata dal produttore e include una gestione più granulare dei modelli CPU personalizzati. L’aspetto decisivo, però, resta indipendente dal numero di versione: il nodo di destinazione deve poter offrire ciò che la VM sta già utilizzando.
Il modello host privilegia l’aderenza all’hardware
Se per la VM viene scelto il tipo CPU host, QEMU espone molte caratteristiche del processore reale, salvo quelle che la virtualizzazione non può rendere disponibili. È utile quando un’applicazione beneficia di istruzioni specifiche oppure quando la VM resterà su un solo server. Il rovescio della medaglia è la portabilità: passando a un nodo con una CPU meno recente o con flag differenti, l’ambiente di destinazione potrebbe non riprodurre lo stesso processore virtuale. La documentazione QEMU considera quindi il passthrough host non sicuro per la migrazione live tra host eterogenei.
Un modello comune riduce le sorprese
I modelli CPU nominati presentano alla VM un profilo definito anziché l’intero processore del nodo. In un cluster con hardware di generazioni diverse, QEMU raccomanda di scegliere il modello più recente supportato da tutti gli host sui quali la VM dovrà migrare. Non significa selezionare automaticamente il profilo più vecchio disponibile: un modello troppo limitato può nascondere istruzioni utili e ridurre le prestazioni. Il punto di partenza è un inventario delle CPU reali e delle funzionalità comuni, seguito da prove sulle applicazioni. Proxmox consente inoltre modelli personalizzati, ma richiedono progettazione e manutenzione consapevoli.
Spegnere la VM non elimina ogni incompatibilità
La migrazione offline evita di trasferire lo stato della CPU mentre la macchina è in esecuzione, ma il sistema ospite dovrà comunque avviarsi sul processore virtuale disponibile a destinazione. Un’applicazione compilata o configurata per istruzioni non più presenti può non funzionare correttamente. La migrazione live è più esigente perché deve mantenere coerenti registri, memoria e stato del dispositivo virtuale durante il passaggio. Prima di considerare compatibile una coppia di nodi bisogna quindi provare sia lo spostamento sia il riavvio della VM, senza assumere che lo spegnimento risolva automaticamente ogni differenza.
Un esempio con due generazioni di server
Immaginiamo un cluster con un server recente e uno precedente. Una VM gestionale configurata come host viene avviata sul nodo nuovo e riceve istruzioni che il vecchio processore non possiede. Quando arriva la manutenzione, la migrazione live verso il nodo precedente fallisce oppure non può essere considerata affidabile. Il responsabile individua un modello CPU comune, lo prova su una copia isolata della VM, verifica avvio e applicazione, quindi pianifica la modifica con backup e finestra di fermo. È un esempio ipotetico: non descrive un intervento svolto da System & Software né garantisce compatibilità per ogni software.
La CPU è soltanto uno dei requisiti
Anche con un modello compatibile, la migrazione dipende da rete, storage, versioni dei nodi e dispositivi assegnati alla VM. Lo storage condiviso consente di spostare una macchina in esecuzione senza copiare l’intera immagine del disco; con dischi locali, tempi e traffico cambiano. Dispositivi PCI pass-through, configurazioni particolari o risorse disponibili solo su un nodo possono impedire lo spostamento. La rete dedicata alla migrazione deve avere banda sufficiente e non deve interferire con la comunicazione di cluster sensibile alla latenza. Il test deve riprodurre il percorso reale, non soltanto confrontare i nomi dei processori.
Limiti e metodo prudente
Cambiare il modello CPU di una VM in produzione è una modifica del suo hardware virtuale e non va trattata come un semplice interruttore. Occorre verificare requisiti del sistema operativo e delle applicazioni, licenze eventualmente legate all’hardware, cifratura, prestazioni e possibilità di ripristino. Prima dell’intervento servono backup verificato, documentazione del valore precedente e piano di ritorno. In un cluster destinato alla migrazione frequente, il profilo comune dovrebbe essere definito prima di creare le VM; quando entra un nuovo nodo, va verificato contro quel profilo. La compatibilità si dimostra con prove controllate, non con la sola appartenenza allo stesso cluster.
Fonti e riferimenti
Fonti consultate il 02/11/2026.