L’11 settembre 2026 Broadcom ha rimosso l’accesso pubblico al Virtual Disk Development Kit, la libreria nota come VDDK. Nessun preavviso, nessun annuncio. La notizia è stata ripresa da Edge9 di Hardware Upgrade. Riguarda da vicino chiunque abbia in corso o in preventivo una migrazione da VMware verso un’altra piattaforma.
Non è un cambio di listino e non tocca le macchine in produzione. Tocca gli strumenti con cui quelle macchine si spostano altrove, quindi il cuore operativo di ogni migrazione da VMware.
Che cos’è il VDDK e perché ogni migrazione da VMware ci passa
Il Virtual Disk Development Kit è una raccolta di librerie C, esempi di codice e documentazione. Serve a creare e leggere i dischi virtuali VMware. La descrizione ufficiale parla di applicazioni che accedono ai dischi e li manipolano, con interfacce per backup e ripristino, clonazione e altre operazioni.
Il caso d’uso dichiarato è sempre stato la protezione del dato. Nella pratica, però, una libreria che legge i dischi virtuali è esattamente ciò che serve anche per copiarli su un’altra piattaforma. Negli anni il VDDK è diventato un componente diffuso negli strumenti di migrazione. Red Hat ne raccomanda l’uso nei passaggi verso OpenShift, e vi si appoggiano anche strumenti di altri produttori, compresi quelli di Nutanix.
Questo spiega la portata della decisione. In una migrazione da VMware nessuno usa il VDDK per scelta: lo si usa perché è il modo documentato e stabile di leggere quei dischi.
La posizione di Broadcom e i due punti che restano aperti
La linea dell’azienda è stata comunicata a The Register in termini netti. L’accesso al VDDK resta disponibile tramite alcuni Technology Alliance Partner selezionati, per quello che Broadcom definisce il suo caso d’uso ufficiale: backup e ripristino. Chi ha bisogno di proteggere i dati può scegliere tra le soluzioni approvate già disponibili presso quei partner. Il VDDK, aggiunge l’azienda, non è un elemento dovuto ai clienti: è un kit di sviluppo coperto da una licenza propria, mai incluso nell’acquisto del software.
Sul piano contrattuale la posizione è difendibile. Restano però due elementi di fatto che chi gestisce un progetto deve mettere in conto.
Il primo è il tempismo. L’uso del VDDK nelle migrazioni è pubblico e documentato da anni, e fino a oggi nessuno era intervenuto. Il cambiamento arriva ora, nel momento di massima uscita dalla piattaforma.
Il secondo riguarda i progetti già avviati. Esistono altre strade tecniche per spostare una macchina virtuale, ma gli strumenti che oggi si appoggiano al VDDK hanno bisogno di tempo per adottarle. In quella finestra una migrazione da VMware già pianificata può rallentare.
Migrazione da VMware in corso: le domande da porre questa settimana
- Quale strumento di migrazione è previsto nel progetto, e se la versione in uso si appoggia al VDDK.
- Se la libreria è già installata sull’ambiente di lavoro, perché una copia locale continua a funzionare anche quando il portale non la distribuisce più.
- Quali ondate di macchine sono già state replicate e quali devono ancora partire, con le date di cutover fissate.
- Che cosa risponde per iscritto il produttore dello strumento su tempi e modalità del percorso alternativo.
- Se il fornitore di backup in uso rientra tra i partner che mantengono l’accesso alla libreria per il caso d’uso ufficiale.
- Quale parte del progetto non dipende dagli strumenti e può procedere comunque: raccolta dati, dimensionamento, ripulitura dell’inventario, scelta dell’hardware.
Che cosa cambia secondo il punto in cui si trova il progetto
| Situazione | Effetto del ritiro | Che cosa conviene fare ora |
|---|---|---|
| Migrazione già in corso, strumento installato | Le repliche impostate proseguono; una nuova installazione non trova più la libreria | Congelare le versioni in uso e chiudere le ondate già pianificate senza ricostruire l’ambiente di lavoro |
| Migrazione pianificata nei prossimi mesi | Il percorso tecnico va confermato con il produttore dello strumento | Chiedere la roadmap per iscritto e tenere due date di cutover, una principale e una di riserva |
| Nessuna migrazione in programma | Nessun effetto immediato sull’esercizio | Anticipare raccolta dati e dimensionamento, che non dipendono da alcuna libreria |
| Backup e ripristino | Il caso d’uso ufficiale resta coperto dai partner selezionati | Verificare che il proprio fornitore rientri in quell’elenco e farselo confermare |
Il costo di rinviare una migrazione da VMware, misurato su un progetto reale
Un service provider italiano aveva avviato la migrazione da VMware del proprio datacenter dopo il cambio delle condizioni di licenza. Tre nodi fisici eterogenei, storage esterno, una cinquantina di macchine virtuali con i gestionali dei clienti finali. Dimensionamento fatto, configurazione scelta, quotazione emessa.
Poi il progetto si è fermato per cambiamenti societari interni.
Alla ripresa, oltre un anno dopo, la macchina quotata era uscita di produzione. La configurazione è stata rifatta sulla generazione successiva, con una scelta diversa sui dischi e una riquotazione completa. Il tempo perso non era rimasto fermo ad aspettare: aveva cambiato il mercato dell’hardware attorno al progetto.
C’è un secondo episodio che vale come avvertimento. In un’altra azienda il referente IT non era al corrente del nuovo regime di licenza. Il system integrator non gliene aveva parlato, perché non era previsto alcun aggiornamento di versione. La notizia è arrivata quando la decisione era ormai vicina alla scadenza contrattuale.
Insight. Il ritiro della libreria non ferma nessuna migrazione da VMware già decisa. Rende però più costoso rinviarla, perché sposta la variabile dal prezzo delle licenze alla disponibilità degli strumenti, e quella variabile non si negozia.
Le strade che restano aperte per una migrazione da VMware
Sul piano tecnico la lettura dei dischi virtuali non passa solo dal VDDK. Gli strumenti di migrazione possono lavorare a livello di sistema operativo ospite, replicando il contenuto della macchina invece del file del disco. In alternativa si appoggiano alle interfacce di gestione della piattaforma. Sono percorsi già usati in altri scenari e i produttori li stanno portando avanti.
Sul piano di progetto, la parte che vale di più resta accessibile da subito. Raccogliere una settimana di dati reali, separare il consumato dall’assegnato, ripulire l’inventario dalle macchine che non verranno migrate, decidere il margine per funzionare con un nodo in meno. Nulla di tutto questo dipende da una libreria. Chi arriva al passaggio con quei numeri in mano recupera le settimane che l’indisponibilità dello strumento può costare.
Vale infine una considerazione sul modello di gestione. Un’infrastruttura seguita con continuità intercetta un cambiamento come questo nel giro di ore, non alla prossima riunione trimestrale. È la differenza descritta parlando di IT gestito a canone rispetto al break-fix. Lo stesso vale per la responsabilità sui dati e sulle piattaforme, affrontata a proposito del cloud gestito.
Le domande arrivate in queste ore
Chi ha già installato il VDDK deve disinstallarlo?
No. La decisione riguarda la distribuzione del kit, non le copie già in uso presso chi le ha scaricate secondo la licenza di sviluppo applicabile al momento. Chi sta lavorando su un ambiente configurato può completare le ondate previste. Conviene però evitare di ricostruire da zero la macchina che ospita lo strumento di migrazione finché il progetto è aperto.
Le copie di backup delle macchine VMware sono a rischio?
Il backup è il caso d’uso che Broadcom dichiara esplicitamente coperto, attraverso i partner selezionati. I prodotti di protezione dati più diffusi rientrano in quel perimetro e continuano a funzionare. La verifica da fare è una sola: chiedere al proprio fornitore conferma scritta di essere tra i partner con accesso mantenuto.
Conviene accelerare la migrazione da VMware per anticipare altre restrizioni?
Accelerare l’esecuzione senza aver chiuso il dimensionamento è il modo più rapido per comprare l’infrastruttura sbagliata. Conviene invece anticipare tutto ciò che precede il passaggio: raccolta dati, scelta della configurazione, ordine dell’hardware. I tempi di consegna, oggi, si contano in mesi. Il cutover si esegue quando gli strumenti sono pronti, e a quel punto sarà l’unica cosa rimasta da fare.
Un cluster a nodo singolo o a due nodi è una scorciatoia percorribile?
È una scelta che va fatta con gli occhi aperti. Sotto i tre nodi il cluster non si espande a caldo: nasce con la dimensione che ha, e per crescere va svuotato e ricostruito. Per una sede remota o un carico circoscritto resta una configurazione sensata; per il datacenter principale di un’azienda che prevede di crescere raramente lo è.
Che cosa chiedere al fornitore in fase di offerta, dopo questa notizia?
Tre impegni scritti: quale strumento verrà usato per spostare le macchine, quale percorso tecnico adotta se la libreria non è disponibile, e quale finestra di fermo è prevista per ogni ondata. Un’offerta che descrive solo hardware e licenze lascia scoperta proprio la parte diventata incerta.
Parliamone
Il ritiro del VDDK racconta qualcosa che va oltre la singola libreria. Quando la strategia di un produttore cambia direzione, cambiano anche gli strumenti che davamo per acquisiti, e il preavviso non è garantito. La difesa è di metodo più che tecnica. Sapere che cosa è in esercizio sulla propria infrastruttura, avere i dati di consumo aggiornati, tenere le decisioni davanti alle scadenze contrattuali invece che dietro. Aesir Srl è Partner Professional Nutanix e gestisce datacenter Tier IV proprietari in Unione Europea con replica. Segue progetti di migrazione in tutta Italia come MSP e MSSP, nello stesso perimetro contrattuale. Se desidera approfondire il tema o valutare la situazione della sua azienda, può compilare la form in fondo alla pagina oppure scrivere a support@aesir-tech.it: prenotiamo una consulenza gratuita e partiamo dai suoi numeri.