Broadcom 移除了 VMware 迁移与退出所广泛依赖的 Virtual Disk Development Kit (VDDK) ，却未发布任何公告
VMware Virtual Disk Development Kit（VDDK）大约于 8 月 25 日从 Broadcom 的开发者网站上消失。我们自行检查了所有三个有文档记录的 URL 以及 SDK 目录：44 个 SDK 仍然可以正常访问，而 VDDK 在所有路径上都返回 404，并且在任何地方都没有列出。
Broadcom 移除了 VMware 迁移与退出所广泛依赖的 Virtual Disk Development Kit (VDDK) ，却未发布任何公告
原文作者：The WJS Desk，来自 https://whatjustshipped.com/broadcom-vddk-downloads-pulled/
译者主页：sysin.org
- VMware Virtual Disk Development Kit (VDDK) 7.0U3
- VMware Virtual Disk Development Kit (VDDK) 8.0U3
- VMware Virtual Disk Development Kit (VDDK) 9.1
VMware Virtual Disk Development Kit（VDDK）大约于 8 月 25 日从 Broadcom 的开发者网站上消失。我们自行检查了所有三个有文档记录的 URL 以及 SDK 目录：44 个 SDK 仍然可以正常访问，而 VDDK 在所有路径上都返回 404，并且在任何地方都没有列出。
大约在 2026 年 8 月 25 日，VMware Virtual Disk Development Kit 的下载页面停止存在。没有博客文章，没有弃用通知，也没有生命周期结束（EOL）公告。Broadcom 的 Customer Care 只告诉一位 Platform9 客户：“为了确保最高标准的安全性、可靠性和产品功能，Virtual Disk Development Kit（VDDK）已不再提供使用或下载。”
我们想确认这究竟是链接损坏还是内容被删除，因此没有仅仅相信截图，而是亲自进行了检查。9 月 8 日，我们请求了 ShapeBlue 记录的、此前可以正常使用的所有 VDDK 路径，以及 VDDK 原来所在的 SDK 目录。三个 VDDK URL 全部返回 404。SDK 目录返回 200，并列出了另外 44 个 SDK，我们随机抽查了其中四个。每一个都可以正常访问。
我们测到了什么
| developer.broadcom.com 上的路径 | 状态 |
|---|---|
| /sdks（目录索引，列出 44 个 SDK） | 200 |
| /sdks/pyvmomi/latest/ | 200 |
| /sdks/vcenter-converter-sdk/latest/ | 200 |
| /sdks/vsphere-automation-sdk-for-python/latest/ | 200 |
| /sdks/vsan-management-sdk-for-java/latest/ | 200 |
| /sdks/vmware-virtual-disk-development-kit-vddk | 404 |
| /sdks/vmware-virtual-disk-development-kit-vddk/8.0 | 404 |
| /sdks/vmware-virtual-disk-development-kit-vddk/9.0 | 404 |
我们还搜索了 SDK 目录页面自身的 HTML 标记中的字符串。在 179,670 字节的 HTML 中，VDDK 出现次数为零。它并不是在该页面上隐藏在登录墙后，也没有被标记为已弃用，而是根本不存在于目录中。作为前后对比，Internet Archive 保存了 2024 年 5 月 VDDK 6.0 和 6.5 页面返回 200 状态的存档 (sysin)，而这些页面使用的正是如今已经返回 404 的同一 URL 前缀。
对于我们的检查，有一个需要诚实说明的限制：公共路径返回 404 并不能证明 Broadcom 内部已经不存在这些二进制文件，我们也无法看到经过身份验证的合作伙伴能够访问什么。我们能够确认的是，所有下游厂商文档中记录的公共访问路径已经失效，而且这个问题是 VDDK 特有的，而不是整个网站出现了故障。
为什么一个磁盘库会成为承重结构
VDDK 并不是什么可有可无的工具。它是一个 C 库，使 ESXi 外部的软件能够打开 VMDK 并读取其中的数据块，包括变更块跟踪（Changed Block Tracking，CBT）功能，而增量备份正是通过这一功能知道哪些数据发生了变化。如果你想把一台正在运行的虚拟机从 VMware 复制到其他平台，VDDK 就是最快的路径。
目前正在使用它的工具列表，实际上也就是人们当前离开 VMware 的各种路径：
- Microsoft Azure Migrate，该工具后来已经在其文档中加入了有关 VDDK 访问问题的警告
- Red Hat Migration Toolkit for Virtualization，这是进入 OpenShift Virtualization 的迁移路径
- Nutanix Move，社区帖子报告无法获取 VDDK 7.0.3.1 和 8.0.3.2
- virt-v2v 和 nbdkit，开源 KVM 转换路径
- 大多数 VMware 备份产品，而这一部分的影响目前还没有人完全算清楚
Red Hat 于 8 月 27 日发布了一篇支持文章，确认客户无法获取 VDDK 镜像。它无法通过直接提供该库来解决问题：VDDK 是 Broadcom 的专有代码，Red Hat 没有权利再分发，因此其建议是去找 Broadcom。
如果你运行 VMware 备份，请现在就检查你的构建主机。任何已经安装的软件都不会因此突然停止工作。真正的风险在于下一次全新安装、容器重新构建或版本升级——这些操作可能需要重新获取 VDDK，而最终得到的却是 404。这个故障最终会表现为一个备份任务失败，而不是一个“下载失败”的错误，而且它很可能会在最糟糕的时间出现。
哪些方案仍然有效，以及代价是什么
出口并没有被完全封死，只是变慢了。ShapeBlue 在欧洲以及美国、巴西、芬兰和日本的出口节点验证了这次故障，并列出了三种完全不依赖 VDDK 的路径：OVF 导出——ShapeBlue 将其描述为“速度更慢，而且非常消耗暂存存储”；通过共享 NFS 上由源 VMDK 支撑的 qcow2 overlay，这需要 CloudStack 4.22.1 或更高版本；以及直接读取磁盘，因为 qemu-img 和 virt-v2v 的若干输入模式根本不需要这个库。ShapeBlue 自己的总结是，基于 VDDK 的方法速度最快、灵活性最高，而这也正好说明了替代方案需要付出什么代价。
Platform9 针对自己的工具也列出了类似方案：通过 iSCSI 或 Fibre Channel 进行存储辅助的冷迁移，但目前不支持 NFS 数据存储；以及通过代理 VM 进行复制。值得注意的是，VMware 到 Proxmox 的迁移不受影响，因为这条路径从来没有使用 VDDK。
因此，实际情况可以概括为：冷迁移仍然可以正常进行，热迁移和增量迁移变得更加困难，而任何依赖变更块跟踪的方案都会失去其高效实现方式。
这些讨论帖实际上说了什么
截至我们 9 月 8 日最后一次查看时，Hacker News 上的相关讨论有 228 个积分和 111 条评论，而真正有价值的评论并不是那些愤怒的帖子。WokeUp420 从一次正在进行的迁移中描述了实际情况：
“我正在进行一次大规模 Azure Local 迁移，发现 VDDK 已经无法获取。幸好我保存了自己的副本，但我完全不知道 Microsoft 今后要如何处理 Azure Migrate。”
最尖锐的问题来自 vrighter。这位用户曾参与备份软件开发，他简单地问道：
“那么现在 VM 备份到底应该怎么做？”
讨论帖中没有人给出答案，我们也没有。
最有价值的不同意见来自 anonymousiam。他指出 qemu-img 完全可以转换 VMDK，并询问除了转换 VMDK 以及重新构建虚拟硬件配置之外，迁移还需要做些什么。对于少量冷迁移 VM 来说，这个观点基本正确 (sysin)；但在大规模集群环境下则严重低估了问题，因为 VDDK 的全部价值之一就在于能够让 VM 保持运行，同时读取其磁盘。
而 dare944 用一句话说出了背后的战略逻辑：
“他们正在给你建一个笼子。你为什么还要留下来？”
与此相对，firesteelrain 则表达了能够让 VMware 收入继续维持下去的那一类观点：一家大型企业正在使用 VMware Cloud Foundation，对其感到满意，有现有协议覆盖，也没有兴趣转向 Proxmox。这两个人都准确地描述了各自真实的处境。
这一变化符合怎样的趋势
自 2023 年收购以来，Broadcom 已经取消永久许可证、重组合作伙伴计划，并提高价格——Platform9 给出的涨幅为 300% 至 1,500%。这些都属于你可以在续约时争论的定价决策。
但这一次在性质上有所不同：它移除了一项技术能力，而且没有发布公告，而它唯一明确影响到的，是那些已经决定离开的客户。
Broadcom 给出的理由是安全性和可靠性。我们找不到任何安全公告、CVE，也没有发现同一页面上提供任何替代 SDK；相反，Broadcom 自己的声明指向的是“获得授权的技术联盟合作伙伴”。
这是一项披着安全外衣的分发决策。
一个悬而未决的问题是：你已经信任的软件接下来会怎么样。
VDDK tarball 的非官方镜像已经出现，并且还附带校验和存档。我们不会提供这些链接，因为从第三方安装 Broadcom 的专有库，很容易让你在迁移截止日期之外，再额外承担一次供应链安全事故的风险。
如果你的组织拥有合法取得的 VDDK 副本，请今天就把它放入制品存储（artifact storage），并记录它的来源。这是一条不怎么光鲜亮丽的建议，但也是我们真正愿意给出的唯一建议。
如果你原本计划在 2027 年离开 VMware，那么现在真正发生变化的是：离开的成本，有一部分已经由你的供应商决定了。
请围绕冷副本和暂存存储来规划迁移，或者现在就开始与 Broadcom 沟通合作伙伴访问权限。毕竟，两周过去仍然没有官方说明，这表明 Broadcom 目前似乎并不急于澄清此事。
浙公网安备 33010602011771号