Da quando Broadcom ha ridisegnato il listino VMware, la domanda che riceviamo più spesso dai CIO italiani è sempre la stessa: esiste un’alternativa credibile, meglio se con radici europee? SUSE Virtualization, il nome commerciale con cui SUSE ha inglobato il progetto Harvester (HCI basata su Kubernetes, KubeVirt e Longhorn, orchestrata da Rancher), è oggi il candidato più citato. Dopo averlo portato in produzione, la risposta onesta è: sì, è una vera alternativa, ma con qualche limitazione in più rispetto a ciò che il marketing lascia intendere.
Dove si è rotto qualcosa che la documentazione non anticipava
La migrazione da VMware o da un cluster esistente non è del tutto indolore. La documentazione ti accompagna bene sullo happy path, ma la realtà di produzione è un’altra cosa. I tre punti dove abbiamo sudato di più:
- Longhorn sotto carico. È il tallone d’Achille dello stack. Longhorn è elegante, cloud-native e ben integrato, ma quando lo metti sotto I/O intenso (database transazionali, VM con molte scritture random) mostra latenze e comportamenti di rebuild delle repliche che non ti aspetti. La sincronizzazione a tre repliche via rete significa che ogni scrittura viaggia sul data plane: se il networking non è dimensionato bene, la VM se ne accorge. La nostra soluzione in produzione è stata duplice: da un lato isolare il traffico storage su rete dedicata a 25GbE, dall’altro — sui workload davvero critici — non affidarci a Longhorn ma appoggiarci a storage esterno di classe enterprise (StorWorks/Pure Storage via CSI). Questa è, a nostro avviso, la strada corretta per chi ha workload I/O-bound.
- Live migration. Funziona, ma è più fragile del vMotion a cui il team era abituato. Migrazioni di VM con dischi grandi o alta attività possono fallire o allungarsi sensibilmente se la banda di replica è satura. Abbiamo dovuto schedulare le migrazioni fuori dai picchi e verificare sempre lo stato di salute delle repliche Longhorn prima di svuotare un nodo.
- Networking VLAN e bonding. Qui la curva è ripida. La gestione delle VLAN passa attraverso i Cluster Network e i NetworkAttachmentDefinition di Multus: chi arriva da un vDS VMware trova un paradigma diverso. Un bonding LACP configurato male a livello di host si traduce in comportamenti intermittenti difficili da diagnosticare, perché il problema è a cavallo tra il layer host (Elemental/SLE Micro) e il layer Kubernetes. La regola che ci siamo dati: congelare e validare la configurazione di rete host prima ancora di creare la prima VM, non dopo.
Il trade-off reale: HCI Kubernetes-native vs Proxmox vs VMware
Chi valuta SUSE Virtualization deve capire che sta comprando un paradigma, non solo un hypervisor. Sotto c’è Kubernetes, e questo è insieme il suo punto di forza e il suo costo nascosto.
- Performance I/O: con Longhorn interno sei un gradino sotto un VMware con SAN dedicata o un Proxmox con Ceph ben tunato su workload pesanti. Con CSI verso storage esterno il gap si chiude quasi del tutto.
- Overhead operativo: più alto di Proxmox nel day-2. Aggiornamenti, gestione delle repliche, troubleshooting dello stack Kubernetes sottostante richiedono competenze che un team classico di sistemisti VMware non ha già in casa.
- Curva di apprendimento: è il fattore decisivo. Se il team ragiona già in termini di container, Rancher e kubectl, l’adozione è naturale e paga. Se il team è puro “vSphere e datastore”, preparatevi a mesi di formazione prima di poterlo gestire H24 con serenità.
La collocazione onesta è questa: SUSE Virtualization gioca nello stesso campionato di Proxmox come alternativa seria a VMware, con in più una vocazione container-native e un supporto enterprise europeo, ma con qualche limitazione operativa aggiuntiva soprattutto sul fronte storage.
A chi diciamo “vai su SUSE” e a chi no
Al cliente enterprise italiano che oggi guarda il rinnovo Broadcom con preoccupazione, la linea la tracciamo così:
- Vai su SUSE se: hai già (o vuoi costruire) una strategia Kubernetes, cerchi sovranità digitale e supporto europeo, gestisci un parco di alcune decine di nodi con workload misti non estremi, e sei disposto ad affiancare a Longhorn uno storage esterno enterprise per i carichi I/O-critici. In questo scenario il TCO rispetto a Broadcom diventa molto interessante.
- Sconsiglialo apertamente se: hai pochi nodi (2-3) e un team senza competenze Kubernetes, dove Proxmox rende la vita più semplice; oppure all’estremo opposto se hai centinaia di VM legacy I/O-intensive, dipendenze forti da funzionalità vSphere avanzate e SLA che non ammettono una curva di apprendimento. Lì il salto è troppo rischioso oggi.
La soglia pratica che usiamo: sotto i ~4 nodi e senza cultura cloud-native, il gioco non vale la candela. Sopra, con team formato e storage esterno per i workload critici, SUSE Virtualization regge il confronto.
Verdetto: conviene muoversi
Il nostro verdetto è 1: conviene iniziare a muoversi, ma con lucidità. SUSE Virtualization non è la promessa vuota di un ennesimo clone: è una piattaforma reale, con supporto europeo e un percorso di migrazione che — pur non essendo indolore — porta a destinazione. Non aspettatevi la sostituzione a costo zero di vSphere: aspettatevi un cambio di paradigma che premia chi ha (o vuole) competenze Kubernetes, che va accompagnato da storage esterno per i carichi pesanti e da una fase di validazione seria su rete e live migration. Chi parte adesso con un PoC su un’isola di produzione controllata arriverà al prossimo rinnovo Broadcom con una carta vera da giocare. Chi aspetta, la giocherà comunque, ma sotto pressione.