Broadcom retira el VDDK: el primer que es trenca no és la teva migració, és el teu backup

A finals d'agost, una URL del portal de desenvolupadors de Broadcom va deixar de funcionar. Sense anunci, sense avís d'obsolescència, sense una línia en unes notes de versió: una pàgina de descàrrega que un dia hi era i l'endemà retornava un 404. Darrere d'aquella URL hi havia una llibreria que fora d'un departament de sistemes ningú no sabria anomenar, i de la qual depenen alhora dues coses que gairebé mai es pensen juntes: el teu pla per sortir de VMware algun dia, i la còpia de seguretat que es va fer ahir a la nit.

Què és el VDDK, en una frase

El Virtual Disk Development Kit és la llibreria que permet a un programa que corre fora de l'hipervisor llegir i escriure discos virtuals de VMware. La seva part visible es diu VixDiskLib, i per sota implementa els modes de transport amb què aquell programa arriba fins a les dades: per xarxa (NBD i NBDSSL), enganxant el disc a una màquina auxiliar (HotAdd) o llegint directament de la cabina (SAN). Fa gairebé dues dècades que és la via per defecte per a tot allò que necessita tocar un .vmdk sense ser el mateix ESXi.

Això inclou, pràcticament, tot l'ecosistema de backup, recuperació davant desastres i migració. I també inclou un detall de llicència que explica per què això és un problema i no una molèstia: el VDDK no es pot redistribuir lliurement. Un fabricant sense acord signat amb VMware no el pot posar dins del seu instal·lador. La conseqüència pràctica des del 2008 va ser que moltes eines et demanaven que fossis tu qui se'l baixés del portal. Aquesta pàgina és la que ja no hi és.

La paraula que gairebé ningú ha llegit

Quan els clients van preguntar, la resposta que va circular des d'atenció al client de Broadcom va ser aquesta: «To ensure the highest standard of security, reliability, and product features, the Virtual Disk Development Kit (VDDK) is no longer available for use or download». I afegia que Broadcom continua mantenint APIs i SDKs perquè els «authorized technology alliance partners» construeixin solucions de còpia i recuperació.

Aquí va la nostra reserva, i la posem abans de continuar, i no al final: aquesta frase prové de respostes de suport reproduïdes per usuaris afectats i recollides després per diverses publicacions del sector. No l'hem vista en un comunicat formal de Broadcom, perquè no n'hi ha hagut. No som advocats i no et direm què significa jurídicament per al teu contracte. El que sí que diem és que hi ha una distància enorme entre «no te'l pots baixar» i «no el pots fer servir», que aquesta distància cau justament damunt de sistemes que són en producció, i que de tot el que hem llegit aquests dies ningú no s'hi ha aturat.

Sí, sortir costa més. Depèn d'on vagis

El titular que ha corregut és que sortir de VMware acaba de posar-se més difícil. És veritat, i és incomplet, perquè no s'ha posat més difícil igual per a tothom. Depèn de quina eina facis servir per copiar els discos, i això depèn d'on vagis.

Del costat dels qui sí que ho noten:

• Migration Toolkit for Virtualization, de Red Hat. Red Hat va publicar un article de suport reconeixent que els clients es troben errors de «no trobat» o «accés denegat» en anar a buscar el VDDK, i va dir una cosa important: no el pot allotjar ni redistribuir, perquè és programari propietari de Broadcom, així que remet a suport de Broadcom mentre la seva enginyeria busca una sortida a llarg termini.
• Azure Migrate, de Microsoft, en el seu mode sense agent: la documentació t'envia a baixar el VDDK 8.0 o 9.0 del portal de Broadcom, i l'enllaç ja no porta enlloc. Que la dependència és real i no una interpretació es llegeix a la mateixa matriu de suport de Microsoft, on tres dels permisos que cal donar a vCenter es justifiquen textualment «per llegir el disc fent servir el VDDK». L'alternativa que queda és la migració basada en agent —l'altre mètode que la mateixa pàgina documenta— i és una altra cosa, amb un altre cost operatiu: cal instal·lar el servei de mobilitat dins de cada màquina.
• virt-v2v i el plugin VDDK de nbdkit, que és la maquinària que hi ha sota bona part de les conversions de VMware a KVM, i Apache CloudStack, que el fa servir com a ruta optimitzada.

I de l'altre costat, la dada que la cobertura ha esmentat de passada i que a nosaltres ens sembla la més útil de totes: l'importador d'ESXi de Proxmox VE no depèn del VDDK. El wiki oficial de migració no l'anomena enlloc —ho hem comprovat buscant la paraula a la pàgina, i no hi surt ni una vegada—; el que descriu és un component propi, esxi-folder-fuse, que fa d'interfície entre Proxmox VE i ESXi parlant amb l'API del host. El wiki arriba a dir fins on estreny: aquell servei «limita les connexions paral·leles a quatre i serialitza els reintents» justament per no saturar una API d'ESXi que, quan es passa de voltes, bloqueja els clients uns trenta segons. Les seves limitacions documentades van per una altra banda —vSAN no suportat, discos xifrats per Storage Policy tampoc, molt més lent amb instantànies, i una caiguda de rendiment seriosa si importes via vCenter en lloc de contra el host— però cap d'elles té a veure amb una llibreria que Broadcom hagi deixat de publicar.

Això no és un argument per triar hipervisor, i seria deshonest vendre-ho com a tal. És una dada de cost que ahir no era a la taula comparativa i avui sí, i que a més pot desaparèixer demà si Broadcom recupera la descàrrega. Prendre una decisió d'arquitectura a cinc anys per una URL trencada seria exactament el tipus de decisió que després es paga. Nosaltres hem escrit amb calma sobre quan no migrar de VMware a Proxmox i sobre per què l'èxode massiu que es va anunciar no es va arribar a produir. Res d'això canvia per un 404.

Una migració té data. El backup és un dimarts qualsevol

Aquí és on creiem que el focus està mal posat. Una migració és un projecte: té data, té amo, té una reunió de planificació. Si el VDDK et complica la migració, te n'assabentes en aquella reunió, amb temps, i busques una altra ruta. És un problema car i molest, però és un problema visible.

El backup no té reunió. El backup és un procés que corre cada nit i del qual només te'n recordes dues vegades: quan falla i quan el necessites. I aquí és on aquesta llibreria fa gairebé vint anys que treballa sense que ningú la miri. A Veeam, per exemple, la mateixa guia de bones pràctiques situa el VDDK dins del servei de transport i descriu els modes que el fan servir —Direct SAN, el mode hot-add de màquina virtual auxiliar i NBD—, anotant a més que en alguns escenaris s'omet a favor del seu propi Advanced Data Fetcher. Treballem amb Veeam i amb Proxmox Backup Server. Convé dir-ho clar per no alimentar l'alarma: el que està instal·lat continua instal·lat, i continua funcionant. Retirar una descàrrega no apaga una còpia que ja corre.

És la forma de fallada que més vegades hem vist de prop operant infraestructura aliena: un sistema que fa anys que funciona perfectament i que ningú no ha tornat a instal·lar des de zero des del dia que es va muntar. Funciona perquè ningú no l'ha tocat, no perquè es pugui reposar. Hi ha una frase que diem molt i que avui admet una volta de rosca: un backup sense provar no és un backup, és un amulet. La prova de sempre és restaurar un fitxer. La prova que gairebé ningú fa és reconstruir la màquina que fa la còpia, amb el que avui tens a mà, sense obrir el portal de ningú.

Tres preguntes que sí que pots contestar aquesta setmana

No et donarem una llista de deu punts. Amb tres n'hi ha prou, i les tres es contesten sense comprar res.

1. Què hi ha dins de la teva còpia? Concretament: si el teu backup de VMware és sense agent, fa servir el VDDK, quina versió té instal·lada i d'on va sortir aquella versió —de l'instal·lador del fabricant o d'una descàrrega manual que algú va fer fa anys—? Aquesta última part és la que decideix si la pots reposar tu sol.
2. Sobreviu a una reconstrucció? La prova es fa avui, en horari d'oficina, sense tocar el sistema de producció: aixeca un proxy de backup nou, des de zero, i comprova que arriba a copiar una màquina. Si en algun pas cal obrir un portal de descàrregues, ja tens la resposta.
3. I si un dia et mous? No cal que decideixis res avui. N'hi ha prou amb saber si l'eina amb què sortiries depèn d'aquesta llibreria o no, perquè això ha canviat de preu aquesta setmana i convé que ho sàpigues abans de la reunió, no durant.

La segona és la que més gent es salta i l'única que dona una resposta que no és una opinió. És la mateixa idea que explicàvem parlant de per què un disc arriba sencer de VMware i després Windows no arrenca: la feina que salva la nit del dissabte és la que es fa un dimarts al matí, amb les màquines enceses i amb tornada enrere còmoda.

Quan això no va amb tu

Si no tens VMware, això no et toca gens i pots tancar la pestanya amb la consciència tranquil·la. Si la teva còpia de seguretat es fa amb agent dins del sistema convidat, tampoc: aquest camí no passa pel VDDK. I si tens VMware, un backup sense agent que funciona i cap intenció de tocar res en any i mig, la resposta honesta és que avui no tens una emergència. Tens un risc ajornat, que és diferent d'un risc inexistent. I fins quan es pot ajornar depèn d'una sola cosa: de si saps reposar la peça tu sol.

Tampoc no sabem —i ho diem perquè ningú no ho sap— si Broadcom revertirà això, si l'accés tornarà per una altra porta, quins són els criteris per entrar en aquell programa de partners autoritzats ni quant es triga. Qualsevol que et digui avui com acaba aquesta història s'ho està inventant.

El que sí que es pot dir és el que la frase de Broadcom descriu amb precisió, es vulgui o no: que la capacitat de llegir els teus propis discos —per copiar-los o per emportar-te'ls— ha passat a viure dins del catàleg de socis d'una altra empresa. Des del punt de vista de Broadcom és una decisió perfectament raonable. Des del punt de vista de qui ha de restaurar demà, és una dependència que fins al 25 d'agost no apareixia en cap inventari perquè no calia que hi aparegués.

Nota de fonts

La retirada de les pàgines públiques de descàrrega del VDDK i la data del 25 d'agost de 2026 provenen de l'anàlisi de ShapeBlue «Broadcom Removes VDDK Pages Without Explanation», publicat aquell mateix 25 d'agost, que és qui va documentar primer les rutes en 404, i de Platform9, que és qui situa la retirada en aquella data; van ser recollides després per, It's FOSS i Virtualization Howto; de ShapeBlue surten també les rutes concretes que retornen 404, l'observació que la llicència del VDDK no permet la redistribució general i les alternatives sense VDDK a CloudStack (exportació OVF i lectura directa per NFS). La frase de Broadcom que citem en el seu anglès original —«To ensure the highest standard of security, reliability, and product features, the Virtual Disk Development Kit (VDDK) is no longer available for use or download»— i l'esment als «authorized technology alliance partners» provenen de respostes del servei d'atenció al client de Broadcom reproduïdes per usuaris afectats i publicades per Platform9 i It's FOSS; no hi ha hagut comunicat formal de Broadcom, i per això ho atribuïm així i no com a nota oficial. Que Red Hat va publicar un article de suport sobre la impossibilitat de descarregar el VDDK per al Migration Toolkit for Virtualization, que no el pot allotjar ni redistribuir per ser programari propietari i que la seva enginyeria busca una alternativa a llarg termini, prové d'aquella mateixa cobertura, igual que la dependència d'Azure Migrate en mode sense agent respecte al VDDK 8.0 o 9.0; els tres permisos de vCenter justificats «per llegir el disc fent servir el VDDK» i l'existència de la migració basada en agent amb el seu servei de mobilitat dins de cada màquina els hem comprovat directament a la matriu de suport de Microsoft Learn per a migració de VMware vSphere. També són d'aquella mateixa cobertura les dependències de virt-v2v, el plugin VDDK de nbdkit i Apache CloudStack. La descripció del VDDK i dels seus transports (NBD, NBDSSL, HotAdd i SAN) és documentació pública de VMware de sempre. Que el VDDK viu dins del servei de transport de Veeam, la llista de modes que el fan servir i l'apunt que en alguns escenaris s'omet a favor de l'Advanced Data Fetcher surten de la guia pública de bones pràctiques de Veeam per a vSphere. Que l'importador d'ESXi de Proxmox VE no anomena el VDDK, que empra el component esxi-folder-fuse i les seves limitacions documentades (vSAN, discos xifrats per Storage Policy, lentitud amb instantànies, caiguda de rendiment via vCenter) surten del wiki oficial Migrate to Proxmox VE. Les cites en castellà i català són traducció nostra de l'original anglès. És lectura NOSTRA, i no de cap de les fonts citades: la distinció entre «use» i «download» i la seva conseqüència; que el focus de la cobertura està mal posat perquè la migració és un projecte visible i el backup no; i que un backup amb aquesta dependència no falla el dia de la retirada sinó el dia en què cal reconstruir-lo. No donem terminis, ni percentatges d'eines afectades, ni interpretació jurídica de la llicència, perquè no els tenim ancorats i preferim dir-ho. Que operem Proxmox VE amb Ceph en producció, que treballem amb Veeam i amb Proxmox Backup Server, que hem migrat empreses de VMware a Proxmox i també recomanat quedar-se, i que no som resellers de cap de les dues plataformes, és informació pròpia d'everyWAN. Comprova-ho al teu entorn abans de fiar-te de res d'això. La fotografia de portada és «IBM TS3500 LTO-6 Tape drive cabling», de vaxomatic, publicada a Wikimedia Commons amb llicència CC BY 2.0.