Caricamento...
Caricamento...
Ogni migrazione VMware che va storta lo fa per una delle stesse ragioni. Dopo aver gestito decine di progetti di migrazione — a Proxmox, ad altri cluster VMware, al cloud — abbiamo imparato a riconoscere gli errori prima che causino danni. Eccoli tutti, con le relative soluzioni.
Perché le migrazioni VMware falliscono? Quasi mai per problemi tecnici irrisolvibili. Quasi sempre per mancanza di pianificazione, testing inadeguato e sottovalutazione delle dipendenze. Questa guida raccoglie gli errori reali visti in campo — leggi prima di iniziare qualsiasi migrazione.
Il primo errore è partire senza sapere esattamente cosa stai migrando. Quante VM ci sono? Quali dipendenze hanno tra loro? Quali applicazioni girano su ogni VM? Senza un inventory dettagliato, ti troverai a scoprire VM 'fantasma', applicazioni dimenticate e dipendenze nascoste a metà migrazione — nel peggiore dei momenti.
Conseguenza
VM dimenticate, applicazioni che smettono di funzionare senza causa apparente
Soluzione
Usa RVTools o vRealize Operations per esportare un inventory completo. Mappa le dipendenze applicative con strumenti come vRealize Network Insight o Turbonomic.
Errore banale ma frequentissimo: non avere un backup completo e verificato prima di iniziare. Un backup 'di cui sei sicuro' che non hai mai testato il restore non è un backup. Durante la migrazione, qualcosa può sempre andare storto — e senza backup testato, non c'è ritorno.
Conseguenza
Perdita di dati, ripristino impossibile, downtime prolungato
Soluzione
Esegui un backup completo di tutte le VM con Veeam o il tuo tool preferito. Testa il restore di almeno 3-5 VM campione su un ambiente separato PRIMA di iniziare la migrazione.
Le applicazioni aziendali non vivono in isolamento. Il gestionale si connette al database su una VM diversa, che si connette all'SMTP relay su un'altra VM, che dipende dall'AD. Se migri queste VM in ordine sbagliato o con indirizzi IP diversi, le applicazioni si rompono anche se ogni singola VM è perfettamente migrata.
Conseguenza
Applicazioni non funzionanti nonostante VM migrate correttamente
Soluzione
Crea una mappa delle dipendenze applicative prima di iniziare. Migra gruppi di VM correlate insieme. Verifica che le configurazioni di rete (IP, DNS, hostname) siano identiche post-migrazione.
Su VMware hai un host con 64GB RAM e 10 VM. Sul nuovo hypervisor, metti 10 VM con la stessa configurazione ma l'host ha 48GB. Risultato: memory overcommitment eccessivo, swap su disco e performance crollate. Oppure il contrario: hai un host molto più potente ma non ottimizzi il dimensionamento delle VM e sprechi risorse.
Conseguenza
Performance degradate, swap eccessivo, host instabile
Soluzione
Prima della migrazione, analizza l'utilizzo reale di CPU e RAM su ogni VM con vRealize o Perfmon. Ridimensiona le VM in base all'utilizzo reale, non alla configurazione nominale. Una VM con 8 vCPU che ne usa 1 è inefficiente.
Active Directory Domain Controller è la VM più critica dell'infrastruttura. Un ADDC migrato male può causare problemi di autenticazione per tutti gli utenti, replication error tra DC, o — nel caso peggiore — un rollback del database AD a un punto precedente con perdita di account e policy.
Conseguenza
Autenticazione non funzionante, utenti bloccati, policy di gruppo perse
Soluzione
I ADDC non si migrano 'a caldo' come le altre VM. La procedura corretta: promuovi un nuovo ADDC sul nuovo hypervisor, sincronizzalo, trasferisci i ruoli FSMO, abbassa il vecchio. Mai fare snapshot di un DC e ripristinarlo — può causare USN rollback.
VMware Tools installa driver speciali nelle VM (VMXNET3 per la rete, PVSCSI per lo storage) ottimizzati per l'hypervisor. Quando migri su un altro hypervisor, questi driver non funzionano — e senza le istruzioni corrette, la VM si avvia ma la rete non funziona o il disco non viene rilevato.
Conseguenza
VM che si avvia ma è irraggiungibile in rete o non trova il disco
Soluzione
Prima della migrazione: rimuovi VMware Tools e installa i driver virtIO (per Linux) o VirtIO-win (per Windows). Su Proxmox: converti le VM con virtio-win ISO prima del primo avvio. Testa sempre su una VM non critica prima.
La migrazione va benissimo nel 80% dei casi. Nell'altro 20%, qualcosa va storto e hai bisogno di tornare indietro. Se non hai pianificato il rollback — come riattivare le VM originali su VMware, come ripristinare la rete originale, come comunicare agli utenti — il 20% dei casi diventa un'emergenza.
Conseguenza
Impossibilità di tornare indietro, downtime prolungato
Soluzione
Mantieni l'ambiente VMware originale attivo e accessibile per almeno 30 giorni dopo la migrazione. Non spegnere i vecchi host, non deallocare le licenze, non eliminare i backup. Documenta il piano di rollback step-by-step prima di iniziare.
La configurazione di rete su VMware (distributed switches, port groups, VLAN tag) non si trasferisce automaticamente al nuovo hypervisor. Se dimentichi di ricreare le stesse VLAN e regole firewall, le VM migrate non comunicano correttamente — con conseguenze di sicurezza e operatività.
Conseguenza
VM isolate o esposte erroneamente su reti sbagliate
Soluzione
Documenta tutta la configurazione di rete VMware prima di iniziare (screenshot, esportazioni). Ricrea la stessa struttura di VLAN e bridge sul nuovo hypervisor PRIMA di avviare le VM migrate. Verifica le regole firewall North-South e East-West.
Molte applicazioni enterprise (Windows Server, SQL Server, alcune ERP) basano l'attivazione sull'hardware: MAC address, UUID della VM, o identificativo dell'host fisico. Dopo la migrazione, questi identificatori cambiano e l'applicazione può disattivarsi o smettere di funzionare.
Conseguenza
Applicazioni che smettono di funzionare per scadenza licenza
Soluzione
Prima della migrazione: identifica tutte le applicazioni con licenza hardware-bound. Contatta i vendor per verificare la procedura di riatttivazione post-migrazione. Per Windows Server e SQL Server, pianifica la riattivazione con KMS o MAK.
La migrazione tecnica delle VM è solo la metà del lavoro. Il vero test è che gli utenti possano lavorare normalmente, che i backup girino correttamente, che i monitoring alert funzionino sul nuovo ambiente. Dichiarare conclusa la migrazione prima di questo testing completo significa scoprire i problemi rimanenti in produzione, quando costano molto di più.
Conseguenza
Problemi scoperti in produzione invece che in fase di test
Soluzione
Dedica almeno 1-2 settimane di monitoring attivo post-migrazione. Coinvolgi i key user di ogni applicazione per il testing funzionale. Verifica backup, monitoring, alert, performance. Solo dopo questo periodo considera la migrazione completata.
I tempi dipendono dalla complessità dell'ambiente. Una migrazione semplice (5-10 VM, infrastruttura piccola) richiede 2-4 settimane tra pianificazione, test e esecuzione. Un ambiente medio-complesso (20-50 VM, dipendenze applicative, database critici) richiede 6-12 settimane. Un ambiente enterprise (100+ VM, cluster multipli, integrazione con SAN e Active Directory) può richiedere 3-6 mesi. La regola pratica: pianifica il doppio del tempo stimato inizialmente.
Sì, con la pianificazione giusta. Le tecnologie di live migration (vSphere vMotion tra ambienti, replica continua con tool come Zerto o Veeam) permettono migrazioni a caldo per la maggior parte delle VM. I database e le applicazioni stateful richiedono sempre una breve finestra di manutenzione (tipicamente 15-60 minuti) per garantire la consistenza dei dati. Per ambienti critici 24/7, si usa la replica asincrona con cutover programmato nelle ore di basso traffico.
Le VM più complesse da migrare sono: database SQL Server con Always On AG (richiedono pianificazione specifica del failover), Active Directory Domain Controller (molto delicato — un ADDC migrato male può compromettere l'intera infrastruttura), Exchange Server on-premise (sempre più raro ma complesso), applicazioni con licenze legate all'hardware (spesso si perdono le attivazioni dopo la migrazione), e applicazioni legacy a 32-bit che potrebbero non essere compatibili con hypervisor più recenti.
Dopo l'acquisizione di VMware da parte di Broadcom e le conseguenti modifiche alla politica di licenze (2024), molte PMI stanno valutando Proxmox come alternativa. Il risparmio può essere significativo: VMware vSphere Essentials+ ora costa 4.000-8.000€/anno per cluster piccoli, contro zero costo licenza per Proxmox (open source, supporto opzionale). Il costo della migrazione (5.000-20.000€ dipende dalla complessità) si ammortizza in 1-2 anni. BullTech ha eseguito decine di migrazioni VMware→Proxmox.
Il testing post-migrazione deve coprire: (1) verifica che tutte le VM si avviino correttamente e rispondano al ping; (2) test delle applicazioni da parte degli utenti finali (non solo il tecnico IT); (3) verifica dei backup: che l'agente backup veda le nuove VM e che un restore di test funzioni; (4) verifica delle performance: CPU, RAM, I/O disco e rete comparate con i valori pre-migrazione; (5) verifica della rete: VLAN, firewall rules, routing; (6) verifica dei servizi automatici che partono all'avvio. Piano di rollback pronto per almeno 30 giorni post-migrazione.
BullTech esegue migrazioni VMware per PMI di Lombardia e Piacenza con metodologia testata: inventory, pianificazione, esecuzione e testing post-migrazione. Zero sorprese, zero downtime non pianificato.
Il team di esperti IT di BullTech Informatica condivide analisi, guide e best practice per la sicurezza e la gestione IT aziendale.