Metodologia a 4 fasi tipica: (1) Audit e dimensionamento cluster target — 1-2 settimane; (2) Cluster Proxmox in parallelo + pilot con 1-2 VM non critiche — 2-4 settimane; (3) Migrazione VM progressiva con virt-v2v o import OVF (downtime per VM: pochi minuti con live migration, 30min-2h per VM grandi con snapshot-and-move) — variabile in base a n.VM; (4) Decommission VMware quando il cliente è tranquillo — dopo 30-60 giorni. Gli strumenti sono rodati: virt-v2v, Proxmox OVF import, ZFS send/receive per storage. Niente magia, solo pipeline operativa.
01Perché la migrazione è il tema caldo del 2025-2026
Dopo l'acquisizione di VMware da parte di Broadcom (novembre 2023), il mercato virtualizzazione italiano si è spostato rapidamente. Le tre pressioni che vediamo arrivare dai clienti sono sempre le stesse: fine del licensing perpetuo (ora solo sottoscrizione annuale), consolidamento in bundle con minimi per-core che penalizzano le configurazioni medio-piccole, aumenti di prezzo nell'ordine del 5-10× rispetto ai contratti precedenti.
Il risultato: chi ha cluster in scadenza 2024-2026 sta facendo conti reali. Non è ideologia, è matematica di bilancio. Molti preventivi di rinnovo arrivano sul tavolo del CFO e tornano indietro con scritto "trovate un'alternativa". La nostra pipeline progetti Proxmox, di conseguenza, negli ultimi 18 mesi è cambiata composizione: prima erano principalmente nuovi cluster, oggi una buona fetta sono migrazioni da VMware esistente.
Buona notizia per chi si trova in questa finestra: il lavoro non lo stai facendo per primo. La procedura è rodata, gli strumenti di conversione sono maturi, i problemi ricorrenti li abbiamo già incontrati e documentati.
02Fase 1 · Audit e dimensionamento
Durata tipica: 1-2 settimane. È la fase più importante — se sbagli qui, paghi per tutto il progetto. Non si parte a migrare finché l'audit non è chiuso.
Cosa mappiamo concretamente:
- Inventario VM: numero totale, dimensioni (vCPU, RAM, disco), OS, versione VMware Tools, eventuali snapshot attivi da ripulire prima della migrazione.
- Dipendenze applicative: quali VM parlano con quali (DB/app server, AD/member server, reverse proxy/backend). Si migra per gruppi coerenti, non per ordine alfabetico.
- Storage: tipo (VMFS, vSAN, NFS, iSCSI), IOPS osservati, pattern di accesso. Definisce se il target è ZFS locale con repliche o Ceph distribuito.
- Network: VLAN, port group, eventuali NSX (se c'è, è un capitolo a parte — vedi sezione 05), firewall rules distributed se usate.
- Hardware speciale: GPU passthrough, USB passthrough, dongle di licenza, vTPM. Tutto ciò che lega una VM a un host fisico specifico.
- Backup esistenti: Veeam, Nakivo, soluzioni custom — vanno ri-puntati o sostituiti con Proxmox Backup Server.
- RTO/RPO attesi: senza questi numeri non puoi dimensionare HA, repliche e finestre di downtime accettabili.
L'output dell'audit è un documento con il dimensionamento del cluster target (quanti nodi, che CPU, quanta RAM, che storage), la strategia di migrazione proposta e un piano di cutover realistico. Il cliente lo firma prima che si tocchi un cavo.
03Fase 2 · Cluster Proxmox target in parallelo
Durata tipica: 2-4 settimane. Il nuovo cluster Proxmox viene allestito accanto a quello VMware esistente, non al suo posto. Nessuno spegne nulla in questa fase.
Decisioni tecniche che prendiamo in questo momento:
- Dimensionamento CPU/RAM: sovradimensionamento del 20-30% rispetto al picco osservato su VMware, per assorbire il rebalancing durante la migrazione e la crescita a 12 mesi.
- Storage: ZFS locale con replica asincrona se il cluster è piccolo (3-5 nodi) e i dataset stanno su singolo nodo; Ceph se serve storage distribuito, crescita orizzontale o la scala lo giustifica. Non mettiamo Ceph "perché fa figo" — ha un TCO operativo reale.
- HA e fencing: cluster a 3+ nodi con quorum device configurato correttamente. Il fencing fatto male è la prima causa di split-brain nelle installazioni Proxmox in casa.
- Rete: ricreazione delle VLAN e dei bridge corrispondenti ai port group VMware. Linux bridge o OVS a seconda della complessità.
Chiudiamo la fase con un pilot: 1-2 VM non critiche (tipicamente server di staging o servizi interni) vengono migrate e tenute in osservazione per 7-14 giorni. Serve a validare la pipeline end-to-end, a scovare sorprese su driver o performance, a dare fiducia al cliente prima di toccare le VM di produzione.
04Fase 3 · Migrazione vera
Durata: variabile, in funzione del numero di VM e delle finestre di manutenzione disponibili. Un cluster da 30 VM medie si fa tipicamente in 2-3 settimane di calendario con migrazioni notturne e nei weekend.
Gli strumenti operativi sono tre, scelti caso per caso:
- virt-v2v (Red Hat): converte la VM da formato VMware (VMDK) a formato Proxmox (qcow2/raw), sistema i driver (rimuove VMware Tools, installa virtio), adatta il bootloader. Funziona bene per la maggior parte dei guest Linux e Windows moderni.
- Proxmox OVF import: esporti la VM da vCenter come OVF, la importi in Proxmox via
qm importovf. Più semplice ma meno automazione sui driver — a volte richiede intervento manuale post-import. - ZFS send/receive: per il trasferimento dello storage di dataset grandi, staging incrementale. Riduce drasticamente la finestra di downtime finale: fai la prima sync a caldo, poi al cutover fai solo il delta.
Downtime atteso per VM:
- VM piccole-medie (<200 GB disco, servizi stateless): pochi minuti, talvolta quasi impercettibile se usi replica staging + cutover breve.
- VM grandi (1-5 TB disco, DB transazionali): 30 minuti - 2 ore di finestra, con approccio snapshot-and-move e replica incrementale la sera prima.
- VM con hardware passthrough (GPU, dongle): richiedono riconfigurazione del passthrough sul nodo Proxmox target. Downtime paragonabile alle VM grandi, più qualche ora di test funzionale post-migrazione.
Regola operativa: una VM alla volta, verifica post-cutover prima di passare alla successiva. La tentazione di parallelizzare per chiudere prima è il modo migliore per trovarsi con problemi difficili da imputare.
05Cosa va a mano, senza strumenti automatici
Per onestà — non tutto si migra con un click. Le cose che richiedono lavoro manuale o soluzioni alternative:
- Soluzioni con agent VMware-specifici: alcuni prodotti di sicurezza, backup o monitoring hanno agent che parlano con vCenter via API VMware. Vanno sostituiti con equivalenti compatibili KVM/Proxmox.
- Integrazione Veeam enterprise: Veeam Backup for VMware funziona diversamente su Proxmox. O si passa a Proxmox Backup Server (la strada che consigliamo quasi sempre) o si valuta Veeam Kasten/altri prodotti che supportano KVM.
- NSX: se il cliente usa davvero NSX per microsegmentazione distribuita, il passaggio è meno diretto. Proxmox SDN copre molti casi d'uso ma non l'intero stack NSX. Se NSX è strategico, la valutazione va fatta con attenzione.
- vRealize Automation / Aria: automazione di provisioning. Si ricostruisce con Terraform + provider Proxmox, o Ansible. Non è un "import", è un riscrivere il codice — ma resta codice più semplice e portabile.
06Fase 4 · Decommission controllato
Durata: 30-60 giorni dopo il cutover. Non si spegne VMware il giorno dopo l'ultima migrazione. È una regola che applichiamo sempre, anche quando il cliente vorrebbe risparmiare subito sul contratto in scadenza.
Il cluster VMware resta acceso, le VM migrate restano spente ma presenti, i backup Veeam del passato rimangono accessibili. Per 30-60 giorni verifichiamo: nessun servizio ha dipendenze nascoste, le performance su Proxmox sono in linea, il backup con PBS ha ciclato correttamente e un restore test è andato a buon fine.
Solo a quel punto si procede al decommission vero: export finale degli snapshot VMware come archivio freddo, spegnimento host ESXi, disdetta della sottoscrizione Broadcom. Il cliente firma un verbale di chiusura migrazione.
07Strategie di migrazione a confronto
Non c'è un unico modo di migrare. I tre approcci principali che valutiamo in audit:
| Strategia | Pro | Contro | Downtime atteso |
|---|---|---|---|
| In-place (stesso hardware) | Zero costo hardware nuovo, riuso completo | Downtime lungo, rischio rollback complicato, niente pilot parallelo | Giorni (per cluster intero) |
| Parallel cluster (consigliato) | Rollback sempre possibile, pilot reale, cutover per singola VM | Costo hardware temporaneo o nuovo, più complessità rete | Minuti-ore per singola VM |
| Lift & shift cloud ibrido | Nessun hardware on-prem, scale elastico | TCO cloud a regime spesso superiore on-prem, lock-in, latenza | Minuti per VM, settimane per assestamento |
Nel 90% dei nostri progetti usiamo il parallel cluster. Il downtime minimo e la possibilità di rollback per singola VM ripagano il costo temporaneo dell'hardware aggiuntivo — spesso noleggio o hardware del cluster futuro acquistato in anticipo.
08Esempio realistico: 30 VM medie
Profilo tipico: azienda manifatturiera, cluster vSphere 3 nodi, 30 VM tra application server, DB, file server, domain controller. Dimensioni totali: circa 15 TB di storage utilizzato.
Tempistica end-to-end: 6 settimane. Breakdown realistico: 1.5 settimane audit e documentazione, 2.5 settimane allestimento cluster target + pilot, 1.5 settimane migrazione VM (3-5 VM per finestra notturna), 0.5 settimane assestamento e handover. Downtime cumulato osservato: 4-8 ore totali distribuite su più finestre notturne, mai più di 2 ore consecutive su una singola VM.
Costi tipici su questo profilo: il progetto di migrazione chiavi in mano si colloca in una fascia a 5 cifre, che si ripaga in genere entro 12-18 mesi confrontando il nuovo canone Proxmox + gestione con il rinnovo VMware post-Broadcom che il cliente avrebbe dovuto firmare. I numeri esatti li facciamo sempre in audit — non vendiamo stime da brochure.
09Il conto vero: cosa si risparmia, cosa si spende
Tre voci da tenere insieme, non separate:
- Licensing risparmiato: differenza tra rinnovo VMware post-Broadcom e sottoscrizione Proxmox enterprise (opzionale). Spesso 10-20k €/anno su cluster medi.
- Costo una-tantum migrazione: audit + progetto + esecuzione + assistenza post-cutover. Dipende dal numero di VM e dalla complessità rete/storage.
- Gestione a regime: canone di manutenzione continuativa, monitoring, backup, reperibilità. Voce che non scompare migrando — cambia solo tecnologia e fornitore.
Il break-even onesto lo calcoliamo sempre in audit, con i numeri reali del cliente. In assenza di sorprese (VM con passthrough complessi, NSX pesante, compliance stringenti) il ritorno è tipicamente a 12-24 mesi. Se l'audit dice che il break-even è a 5 anni, lo diciamo — e a quel punto la valutazione cambia.