Al voltant del 25 d'agost de 2026 van desaparèixer les descàrregues públiques del VDDK de VMware, i la lectura que va córrer va ser que Broadcom havia tancat la porta de sortida. Vam anar a mirar de quina porta parlàvem. Hi ha rutes de migració que llegeixen els discos a través d'aquella biblioteca i rutes que no la toquen en cap moment; la de l'importador d'ESXi de Proxmox és de les segones. Comprovar-ho costa tres minuts i té trampa, perquè la prova que tothom faria servir —obrir les dependències del paquet— és justament la que no demostra res.
D'això ja en vam escriure al setembre, quan la notícia era recent, i llavors vam sostenir que el primer que es trenca no és la teva migració, és el teu backup: l'urgent no era la migració sinó la cadena de còpies. Aquest post és l'altra meitat, la que allà vam deixar sense resoldre. Si el programari que llegeix discos de VMware des de fora depèn d'una biblioteca que ja no es descarrega, la pregunta que queda és quina de les rutes de sortida hi passa. Aquesta es respon obrint fitxers, no opinant.
Què es va retirar, exactament
El VDDK (Virtual Disk Development Kit) és el kit amb què un programa extern obre un disc virtual de VMware i el llegeix bloc a bloc sense passar pel sistema operatiu convidat. Convé separar dues coses que sovint es confonen: la llista de quins blocs han canviat des de la passada anterior es demana a l'API de vSphere, amb QueryChangedDiskAreas, que continua sent pública; el que aporta el VDDK és la lectura d'aquells blocs. Al disc és un fitxer amb nom propi i versionat, libvixDiskLib.so.N, que viatja dins del paquet vmware-vix-disklib-distrib. Durant anys es baixava del web de desenvolupadors sense més tràmit que un compte, i a sobre s'hi va construir bona part del programari de backup, de replicació i de migració que toca VMware.
Aquelles pàgines van deixar de respondre al voltant del 25 d'agost de 2026, sense avís previ ni anunci públic, segons la cronologia que va publicar heise el 22 de setembre. Broadcom ho va confirmar el 9 de setembre en els termes més secs possibles: «el cas d'ús aprovat del VDDK segons la llicència de l'SDK ha estat sempre el de les solucions de backup i recuperació dels nostres socis TAP, i aquest canvi simplement reforça aquells termes». És a dir: no ho presenten com una retirada, sinó com l'aplicació d'una llicència que ja deia això. La biblioteca continua existint per als membres seleccionats del Technology Alliance Program; el que ha desaparegut és la descàrrega oberta.
Comprovat el 2 de novembre de 2026, abans de publicar això: /sdks/vmware-virtual-disk-development-kit-vddk, la seva variant sense vmware i la mateixa amb /latest retornen 404 a developer.broadcom.com; la de l'SDK de pyvmomi, al mateix domini, retorna 200. I ara la part honesta, que ens va costar una estona acceptar: aquell 404 no demostra per si sol que s'hagi retirat res. Vam provar un identificador inventat per nosaltres i retorna exactament el mateix, i també ho fa /sdks/vsphere-web-services-sdk/latest, d'un SDK que continua existint. El que sosté la retirada és el reportatge i la confirmació del mateix fabricant, no el nostre curl. Ho deixem aquí perquè la data de la nostra comprovació sí que val: a dia d'avui, per aquella porta no s'hi entra.
El que diuen les dependències de l'importador de Proxmox
L'assistent d'importació d'ESXi de Proxmox VE viu en un paquet anomenat pve-esxi-import-tools. Vam anar a l'índex del repositori pve-no-subscription de Debian trixie i el vam copiar tal com ve, amb les seves restriccions de versió. Versió 1.0.1:
Package: pve-esxi-import-tools
Version: 1.0.1
Depends: python3, python3-pyvmomi, libc6 (>= 2.34),
libfuse3-4 (>= 3.17.2), libgcc-s1 (>= 4.2),
libssl3t64 (>= 3.0.0), libzstd1 (>= 1.5.5)
Description: Tools to allow importing VMs from ESXi hosts
Provides a FUSE file system to access files on ESXi hosts and a python utility
to query the list of VMs and datastores.
Allà no hi ha cap VDDK. Hi ha python3-pyvmomi, que és l'SDK de Python per a l'API de vSphere —codi obert amb llicència Apache, versió 9.1.1.0 publicada a PyPI el 3 de setembre de 2026, descarregable per qualsevol ara mateix— i hi ha libfuse3, perquè el paquet munta el datastore de l'ESXi com un sistema de fitxers i hi llegeix els .vmdk, parlant amb el host directament.
I aquí hi ha la trampa que anunciàvem, perquè aquella absència demostra molt menys del que sembla. El VDDK no es pot redistribuir: la seva llicència no ho permet. Per tant cap paquet de Debian pot declarar-lo a Depends, el faci servir o no. L'absència és una certesa estructural, no una prova.
El contraexemple és a mà i el vam comprovar el mateix dia: nbdkit-plugin-vddk (versió 1.48.1-1 a la secció contrib de Debian) llegeix els discos a través del VDDK —és, literalment, el connector del VDDK— i el seu camp de dependències diu libc6, nbdkit. Res més. Carrega la biblioteca en calent, des d'una ruta que hi poses tu. Així que qui es quedi només amb el Depends es pot equivocar en tots dos sentits.
Aleshores, què sí que prova alguna cosa? Tres coses, i en aquest ordre de pes. La més fluixa és la que acabem d'ensenyar. La segona: la wiki oficial de Proxmox descriu el procediment sencer sense anomenar el VDDK ni una sola vegada, i el que descriu és un component propi parlant amb l'API del host ESXi. La tercera i bona s'executa a la màquina, perquè allà ja no hi ha declaracions que valguin: o la biblioteca hi és, o no hi és.
apt-cache show pve-esxi-import-tools | grep -E '^(Version|Depends)' dpkg -L pve-esxi-import-tools find / -name 'libvixDiskLib.so*' 2>/dev/null
La tercera ordre és la que val, i no només a Proxmox: passa-la per cada màquina que participi en el teu pla de sortida o en la teva cadena de còpies. Si retorna alguna cosa, aquella peça llegeix els discos per VDDK i acabes de trobar una dependència d'un fitxer que ja no es descarrega en obert. Si no retorna res, no ho celebris encara: la biblioteca pot viatjar encastada dins del contenidor o de l'instal·lador del teu proveïdor, que és precisament la via que Broadcom deixa oberta als seus socis. Per això al comercial de torn cal preguntar-li una altra cosa: si el seu producte inclou la biblioteca o espera que la posis tu, i d'on va sortir la que porta.
Quines rutes llegeixen per VDDK i quines no
El que segueix són declaracions de cada fabricant sobre la seva pròpia eina, no la nostra interpretació. Amb un avís que ShapeBlue es posa a si mateix i que repetim perquè és just: la seva secció sobre el seu producte cal llegir-la «com el fullet de fabricant que és».
| Ruta de sortida | Llegeix per VDDK? | Qui ho diu |
|---|---|---|
| Importador ESXi de Proxmox VE | No | Dependències del paquet 1.0.1: pyvmomi + FUSE |
| Migration Toolkit for Virtualization (Red Hat) | Opcional, però recomanat | «És molt recomanable crear una imatge VDDK»: «accelera la migració i redueix el risc que un pla falli»; si falla sense ella, «torna-ho a provar amb VDDK instal·lat» |
| MTV sobre discos a vSAN | Imprescindible | «Les migracions no funcionen sense VDDK quan la VM està sustentada per vSAN» |
| Mètodes directe i CBT de ShapeBlue Migrate | Sí | «Dues de les quatre llegeixen avui a través del VDDK» |
| Els seus mètodes d'overlay i OVF | No | «Dues de les rutes no necessiten la biblioteca en absolut» |
La tercera fila és la que convé llegir dues vegades. En discos sobre vSAN, la ruta de Red Hat sense VDDK no migra. I l'importador de Proxmox, que no fa servir VDDK en absolut, tampoc no toca vSAN: ho diu la seva wiki, per un motiu tècnic diferent i amb el mateix resultat per a qui hi té les VMs. Dues rutes oposades, la mateixa paret, i aquella paret no és la biblioteca retirada. És vSAN, que fa anys que és on és i no ha sortit en cap titular d'agost.
La lletra petita de la ruta que sí que funciona
Quedar-se amb que «Proxmox importa sense VDDK» és la manera ràpida d'endur-se un disgust a mitja finestra de manteniment. La seva documentació enumera sis coses que l'importador no fa, i totes sis es llegeixen millor abans de prometre una data que no pas després:
- ✗«Importar una VM amb discos sustentats per un emmagatzematge VMware vSAN no funciona.» Una frase, sense condicionals ni matisos: si els teus discos són a vSAN, aquesta ruta s'ha acabat aquí.
- ✗Discos xifrats, no. «Els discos de VM xifrats, per exemple mitjançant una Storage Policy, no es poden importar.»
- ✗Amb snapshots, lent. «Importar una VM des de VMware ESXi pot ser significativament més lent si la VM té snapshots.» Consolidar aquella cadena de delta-disks forma part de la preparació, no de la finestra.
- ✗Per vCenter, pitjor. «Tot i que també es pot importar a través d'una instància de vCenter, fer-ho reduirà dràsticament el rendiment.» Convé apuntar directament al host ESXi.
- ✗Provat fins a ESXi 8.0. «La importació es va provar des de la versió 6.5 d'ESXi fins a la 8.0.» Si ja estàs en una branca posterior, estàs en territori no declarat: prova-ho amb una VM d'usar i llençar abans de prometre dates.
- ✗I no, no hi ha zero aturada. Hi ha importació en viu —la VM arrenca a Proxmox mentre es copien les dades—, però la mateixa documentació aclareix que «la VM a l'ESXi continua apagada, així que hi haurà una certa aturada». La finestra existeix; el que canvia és la seva mida.
A aquella llista hi afegim la nostra, la de les migracions que hem fet: el disc arriba bé gairebé sempre i el convidat és el que es queixa. Windows arrencant sobre una controladora que no coneix és el cas clàssic, i ho expliquem amb detall a el disc arriba sencer i Windows no arrenca. L'assistent et porta el bloc; l'arrencada continua sent el teu problema.
El risc que ningú no va titular
La via que queda per aconseguir la biblioteca pel teu compte passa pel portal de suport. ShapeBlue ho formula així al seu avís del 25 d'agost: els clients amb drets de VMware actius haurien de revisar el seu accés al portal de suport de Broadcom i demanar al seu contacte una via de descàrrega autoritzada. La condició va davant del consell, i és la part que importa.
Una eina de sortida que exigeix continuar dins té una data de caducitat que no decideixes tu. Durant la migració no molesta, perquè el suport encara es paga. Molesta divuit mesos després, quan algú demana recuperar un fitxer d'una còpia de 2025 desada en format VMware i el contracte fa un any que està tancat. Això ja no s'arregla al departament de compres: és una restauració que no es pot fer, i viu al mateix calaix que la resta de dependències de tercers que ningú no va inventariar.
La ruta de sortida és una decisió d'arquitectura i es pren per escrit abans de signar, amb la mateixa cura amb què s'escull l'emmagatzematge. Que un proveïdor canviï les regles del seu SDK sense avisar entra dins del previsible: la fallada és inevitable. Que això et deixi sense poder llegir els teus propis discos ja és una decisió de disseny, i la vas signar tu.
Les cinc comprovacions que fem abans de donar una data
- 1On viu cada disc. VMFS, NFS, vSAN o xifrat per política. Si apareix vSAN o xifrat, la ruta de l'importador cau i cal resoldre-ho abans de parlar de calendari.
- 2Quina biblioteca fa servir cada eina. El
findd'abans en tot el que participi, i la pregunta per escrit al proveïdor sobre si encasta el VDDK o l'espera de tu. - 3Una VM real, cronometrada. No una de prova buida: una amb la seva mida de disc de debò, per mesurar la finestra amb l'ample de banda que tens, no amb el que promet el fullet.
- 4Les còpies antigues. Decidir avui com es llegirà dins de dos anys una còpia en format VMware, suposant que el contracte ja no hi sigui. Si la resposta depèn d'un portal de suport, no és una resposta.
- 5La tornada enrere. Què es fa si al cap de dues hores la VM no arrenca i hi ha gent esperant. Ho escrivim abans de començar, i ho tenim desenvolupat a el pla de tornada enrere d'una migració a Proxmox.
El que de debò decideix qui surt i qui no
Broadcom ha tancat una porta concreta, la del programari que llegeix discos de VMware des de fora, i l'ha deixada oberta per als seus socis. Qui anava a sortir amb l'importador de Proxmox no hi va passar mai. Qui anava a sortir amb una eina que llegeix per VDDK té ara un problema de contracte disfressat de problema tècnic. I per sota dels dos grups hi ha el que de debò decideix la data: on viuen els discos. A vSAN s'estavellen les dues rutes, la que fa servir la biblioteca i la que no, i això no ho arregla cap portal de descàrregues.
A everyWAN això cau a migració de VMware a Proxmox i, quan la pregunta és si convé moure's o aguantar, a consultoria. Operem Proxmox VE amb Ceph en producció des de la branca 3.x i hem migrat empreses; també hem recomanat quedar-se a VMware quan el compte sortia a favor de quedar-se. No som resellers de cap de les dues plataformes, així que la recomanació no ens canvia la factura.
Fonts. Retirada de les descàrregues i cronologia (25-ago-2026, sense anunci públic) — heise, 22-set-2026. Confirmació i citació de Broadcom sobre els socis TAP, i declaració de Platform9 (Nicole Silva, vicepresidenta de la companyia: «en restringir l'accés públicament, sense avís, Broadcom va interrompre moltes migracions que ja estaven en curs»; convé saber que Platform9 ven migracions fora de VMware) —TechTarget, 09-set-2026. Rutes que depenen o no del VDDK i via del portal de suport — ShapeBlue, 25-ago-2026. Recomanació d'imatge VDDK i cas vSAN — documentació de Red Hat MTV 2.8. Limitacions de l'importador, versions provades i nota d'importació en viu — wiki de Proxmox VE. Versió i dependències de pve-esxi-import-tools 1.0.1 — índex de paquets de download.proxmox.com, consultat el 02-nov-2026. Versió 9.1.1.0 de pyvmomi (Apache 2.0, 03-set-2026) — PyPI. Nom i ubicació de libvixDiskLib.so — manual de nbdkit-vddk-plugin. Els codis 404 i 200 són comprovacions nostres del 02-nov-2026; les citacions de fabricants estan traduïdes de l'anglès original.
Saps per quina biblioteca llegeix el teu pla de sortida de VMware?
Ho revisem amb tu: on viu cada disc, quina eina depèn de què, quant dura la finestra real i què es fa si no arrenca. I si el compte surt a favor de quedar-te, t'ho direm.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN