Quando gestisci un cluster Proxmox, pensi sempre che la parte difficile sia l’hardware, i dischi, la rete… e invece a volte il problema arriva da dove meno te lo aspetti 😄. È quello che è successo a me qualche giorno fa, quando una semplice migrazione live ha iniziato a comportarsi in modo strano. Tutto sembrava procedere bene: la RAM veniva trasferita, il tunnel era attivo, nessun errore evidente. Poi, proprio al momento del passaggio finale, boom… “resume failed – client closed connection”. La VM si spegneva sul nodo di destinazione come se qualcuno avesse tirato la spina 😑.
All’inizio ho pensato a un problema di rete, poi a un bug, poi a qualche servizio bloccato. Ho controllato conntrack, dbus‑vmstate, log di QEMU, journal… niente. Tutto sembrava in ordine. Eppure la migrazione continuava a fallire, sempre verso lo stesso nodo. Una cosa che ti fa grattare la testa e dire “ma che diavolo sta succedendo” 🤨.
La svolta è arrivata quando ho iniziato a guardare non i log, non la rete, ma l’hardware. I miei tre nodi non erano affatto gemelli: uno montava un Intel i5, gli altri due erano Xeon, ma di modelli diversi. E lì ho avuto l’illuminazione 💡. Anche se sono tutte CPU Intel, non condividono lo stesso set di istruzioni. Alcune hanno AVX2, altre no. Alcune hanno AES‑NI, altre lo gestiscono in modo diverso. E quando una VM è configurata con “cpu: host”, Proxmox espone al guest tutte le istruzioni della CPU fisica del nodo sorgente. Se il nodo di destinazione non le supporta, la migrazione live non può funzionare. È come cercare di far ripartire un motore diesel su un’auto a benzina… non succederà mai 😅.
A quel punto tutto aveva senso. QEMU provava a ripristinare lo stato della CPU sul nodo target, trovava un’istruzione non supportata e chiudeva la connessione. Da qui l’errore “resume failed”. Una cosa che sembra misteriosa finché non guardi il quadro completo.
La soluzione, alla fine, è stata sorprendentemente semplice 😊. Ho cambiato il modello CPU della VM da “host” a “x86‑64‑v2”, un modello più portabile che espone solo le istruzioni comuni a tutte le CPU moderne. In pratica, un linguaggio CPU che tutti i nodi del cluster capiscono senza problemi. Dopo aver applicato questa modifica, la migrazione live ha iniziato a funzionare immediatamente, senza errori, senza spegnimenti improvvisi, senza sorprese. Una sensazione di sollievo incredibile 😌.
Se tutti i nodi supportano AES‑NI, si può anche usare “x86‑64‑v2‑AES”, che offre un piccolo vantaggio prestazionale. Chi vuole mantenere performance elevate può provare “host‑model”, che è più compatibile di “host” ma comunque non perfetto in cluster molto diversi. “qemu64” resta l’opzione più portabile in assoluto, ma oggi è troppo limitante per la maggior parte dei carichi.
Alla fine, questa esperienza mi ha ricordato una cosa importante: in un cluster eterogeneo, la compatibilità CPU è fondamentale. Se incontri errori di migrazione live come “resume failed”, non farti ingannare da log strani o messaggi fuorvianti. A volte la risposta è molto più semplice: i nodi parlano lingue diverse, e basta scegliere un modello CPU che tutti capiscono per riportare la pace nel cluster 🚀.