不靠 VDDK 的迁移桥
VMware 迁移突然失去 VDDK 时，从虚拟机内部生成开放镜像，并在目标环境自动启动影子副本验收。
Broadcom 停止提供 VDDK 下载后，原本准备迁出 VMware 的团队会突然失去宿主侧导出路径。管理员先在迁移台登记一批待迁虚拟机、目标环境和可接受的停机时长，再挑一台非关键机器做影子迁移。产品明确显示每台机器缺少的凭据、可用的客体系统权限，以及迁移前必须完成的应用检查。
轻量代理安装在虚拟机内部，由客体系统冻结应用写入、采集磁盘内容和启动配置，再生成开放镜像。它把网卡、磁盘挂载和启动参数转换为 KVM、Proxmox 或指定云环境可识别的配置。数据库等有一致性要求的服务，必须先接入团队提供的停写脚本；没有脚本时，页面会把这台机器留在待处理队列。
镜像传到目标环境后，产品自动拉起隔离副本，保存启动画面并探测关键端口、服务进程和抽样数据。迁移负责人看到的是一份逐项对照的报告：哪些服务已启动，哪些配置仍需人工改写，原机与副本的数据校验是否一致。首个可用版本先覆盖 Linux 虚拟机迁往 KVM 和 Proxmox，让团队先验证小批机器，再安排生产切换。
为什么是现在
8 月 25 日起，VDDK 多个下载路径被记录为不可用；9 月 7 日的报道把这一变化带到更多迁移团队面前。S1 截至 9 月 8 日 00:33，相关 Hacker News 条目位于第 9 位，记录为 67 points 和 28 comments，管理员此时更可能发现原定的无代理迁移流程无法继续。S2
目标用户
对象是准备把一批 Linux 工作负载迁出 VMware 的平台团队。宿主侧下载或接口突然不可用时，他们必须重新判断迁移路径。此时最需要的不是另一份格式转换教程，而是先找出哪些机器具备客体权限、能形成一致镜像，并能在目标环境提前启动验收。
最小切入点
首版限定为使用 LVM、ext4 或 XFS 的 Linux 虚拟机。代理先检查 root 权限、卷布局、剩余空间和启动模式。应用脚本通过停写、`fsfreeze` 与 LVM 快照形成稳定读取点；条件不满足就阻止导出。磁盘按稀疏块流式传输，落地为 raw 或 qcow2。目标侧分别接入 libvirt 和 Proxmox REST API。S4 启动后采集控制台画面、端口、systemd 服务和用户指定校验命令，不在首版处理 Windows、vTPM 与跨数据库自动一致性。
以小博大
第一批用户可从 Proxmox、KVM 和自建云社区里的迁移求助者获得。发布一个免费的只读检查器，输出卷布局、启动方式和缺失条件，让管理员先判断机器能否迁移。再公开几组匿名化迁移报告模板，展示启动、端口和数据校验结果。还可向独立虚拟化顾问提供批次工作区，让他们在客户项目中直接带入工具。
竞品与缝隙
怎么赚钱
按迁移批次收费，基础套餐包含一定数量的 Linux 虚拟机、镜像暂存和影子验证。超过数量后按每台机器加收费用。企业版再提供私有部署、审计日志和迁移报告留存。
反方视角
客体侧导出首先受磁盘布局限制。没有 LVM 快照空间的机器，很难在持续写入时取得稳定镜像。数据库停写脚本还要由应用负责人维护，协调成本会随服务数量上升。整盘传输会占用生产网络，并拉长影子迁移时间。启动修复还会碰到 UEFI、VirtIO、网卡命名和加密卷。隔离网络若配置错误，副本可能连接生产依赖或产生地址冲突。端口存活也不等于业务正确，错误验收会让团队在正式切换时失去信任。