KubeVirt RWO 云盘 Volume Migration 实测
KubeVirt RWO 云盘 Volume Migration 实测
本文验证 KubeVirt 的 Volume Migration：VM 运行时，把数据盘从一个静态 RWO PVC 迁移到另一个静态 RWO PVC。
这里没有把 NFS 伪装成 Ceph。测试集群没有 Ceph CSI/RBD，因此用两个 NFS 导出目录模拟源、目标后端，重点验证 KubeVirt 的卷迁移流程，以及迁移后数据和 PVC 状态是否正确。
结论先放在前面：迁移成功，目标 PVC 仍然是 RWO。Volume Migration 复制数据并切换 VM 的卷引用，不会把 RWO 自动变成 RWX。迁移完成后，VM 仍不能进行普通的共享存储热迁移。
Volume Migration 做什么
KubeVirt 的 Volume Migration 用于在 VM 运行时更换存储。源卷和目标卷需要提前准备好，KubeVirt 负责复制数据并更新 VM 的卷引用，不负责创建目标 PVC 或目标存储。
本次实验的关系是：
flowchart LR
A["VM 运行<br/>source PVC: RWO"] --> B["更新 datadisk<br/>claimName"]
B --> C["KubeVirt Volume Migration<br/>VMIM Succeeded"]
C --> D["target PVC: RWO"]
D --> E["disk.img 哈希一致"]
D -.-> F["普通 Live Migration 仍受限"]
测试环境
只记录本次用到的软件版本：
| 软件 | 版本 |
|---|---|
| kind | v0.31.0 |
| Kubernetes | v1.35.0 |
| KubeVirt | v1.9.0 |
| CDI | v1.66.0 |
| Kube-OVN | v1.14.3 |
源、目标 PV 都是静态 PV，配置如下：
accessModes: ReadWriteOncevolumeMode: FilesystempersistentVolumeReclaimPolicy: Retain- 源、目标 PVC 分别绑定固定的 PV
- 源、目标 PV 使用不同的 NFS 导出路径，并通过节点亲和性固定到不同 worker
NFS Deployment 使用 emptyDir 保存后端数据，只适合实验。它证明的是 KubeVirt 能否完成这条 Volume Migration 控制链，不证明 Ceph CSI/RBD 的 attach、detach 或 RBD image 语义。真实云盘环境还需要用实际 CSI 驱动单独验证。
实验文件已经提交到 k8sdev 0337aacd。
前置配置
Volume Migration 依赖 KubeVirt 的 LiveUpdate 和 LiveMigrate 配置。实验配置如下：
这个配置是 KubeVirt CR 的集群级配置，只应在专用实验集群或确认影响范围后应用。
相对于没有启用卷在线更新的 KubeVirt CR，关键新增项如下：
| |
这是迁移前置条件，不是源 PVC 到目标 PVC 的数据切换本身。
先准备 NFS 模拟后端：
准备静态 RWO PV/PVC：
在目标集群中执行：
| |
确认两组对象都是 Bound、ReadWriteOnce、Filesystem 后再启动 VM。不要只看 PVC 是不是 Bound，还要核对 PV/PVC 的 access mode、volume mode 和 reclaim policy。
真正改了什么
这次不是修改 PVC 的 accessModes，也不是修改 PV。真正触发 Volume Migration 的改动只有 VM 数据盘的 PVC 引用：
| |
这段差异里，- 是迁移前的源 PVC，+ 是迁移后的目标 PVC。updateVolumesStrategy: Migration 在两个 VM 文件中都存在，并不是这次切换时才新增的字段。
可以按下面三层理解：
| 配置位置 | 作用 | 是否是本次切换的差异 |
|---|---|---|
| KubeVirt CR | 开启 LiveUpdate 和 LiveMigrate | 前置配置 |
VM updateVolumesStrategy | 指定卷引用变化使用 Volume Migration | 源、目标文件都必须保留 |
VM datadisk.claimName | 从源 PVC 改为目标 PVC | 真正触发迁移的改动 |
因此，04-vm-source.yaml 和 05-vm-target.yaml 大部分内容相同，重点只看 datadisk 对应的 claimName。目标 PVC 必须提前创建并处于 Bound，KubeVirt 不会因为这个字段变化自动创建目标卷。
先验证源 PVC
源 PVC 先由一次性 Pod 挂载并写入一个文件：
| |
这个 Pod 的作用是提前确认静态 PVC 能被节点挂载和写入，并不是给 VM 生成业务数据。RWO PVC 不能长期被这个 Pod 占用，所以检查完成后要删除它。
还有一个容易误判的地方：这里的 PVC 是 Filesystem，KubeVirt 会在挂载目录中使用 disk.img 作为 VM 数据盘。上面写入的 sentinel.txt 位于挂载目录根部，不等于 guest 文件系统里的文件，因此不能直接拿它作为迁移后的 VM 数据证明。最终校验比较 disk.img 的哈希。
启动 VM 并迁移数据盘
源卷版本的 VM：
| |
此时 VM 使用 volume-migration-source。把 VM 清单中的数据盘改为目标 PVC：
| |
需要看到 VMIM 进入 Succeeded，并检查 VM.status.volumeUpdateState：
| |
本次实测结果：
- VMIM
kubevirt-workload-update-xbp7h进入Succeeded。 - VM 仍在运行，VMI 从源节点切换到目标节点。
VM.status.volumeUpdateState.volumeMigrationState.migratedVolumes记录了volume-migration-source到volume-migration-target的切换。- 源、目标 PVC 的
accessModes都是ReadWriteOnce，volumeMode都是Filesystem。
不要把“生成了 VMIM”当成完成证据。VMIM 还要等到 Succeeded，并且要继续检查目标卷中的数据。
校验目标数据
先停止 VM，让目标 RWO PVC 可以被检查 Pod 单独挂载：
| |
目标校验 Pod：
| |
输出中的目标文件为 disk.img，本次 SHA-256 是：
| |
源、目标 disk.img 的哈希一致，说明这次迁移复制出的数据与源端一致。
迁移后的访问模式
最后再次检查 PV/PVC：
| |
结果仍然是：
| |
VM 的 LiveMigratable 条件为 False，原因是目标 PVC 仍然不是共享卷：
| |
所以，Volume Migration 和 RWO 转 RWX 是两件事：
- Volume Migration：运行中的 VM 从旧 PVC 迁移到已准备好的新 PVC。
- RWO 转 RWX：需要后端数据复用和 PV/PVC 对象重建，访问模式由
ReadWriteOnce改为ReadWriteMany。
如果目标是让 VM 后续支持普通热迁移，目标存储必须真正支持共享访问，并且目标 PV/PVC 要按 RWX 创建。只修改 PVC 的 accessModes 不会改变后端存储能力。
这次实验的注意事项
- 目标 PVC 必须先存在。Volume Migration 不会替你创建目标卷，也不会替你把 RWO 改成 RWX。
LiveUpdate和LiveMigrate是必要前置条件。缺少时，更新 VM 的卷引用可能只停留在VolumesChange=True，看不到有效的 VMIM。- 如果一次更新没有生成 VMIM，先把 VM 恢复到源 PVC，等待
VolumesChangeCancellation完成，再重新更新到目标 PVC。不要在状态未收敛时连续覆盖 VM 清单。 - NFS 后端在这个实验中可以被多个节点访问，但 PV 仍声明为 RWO。因此它不能验证真实云盘的独占挂载、CSI attach/detach 或 RBD image 行为。
- 生产环境删除 PV 前，要确认
Retain和后端资产的关系，并保存volumeHandle、存储池、集群标识、volumeMode、挂载参数及 Secret 引用。重建对象时漏掉 CSI 字段，PVC 可能仍是Bound，实际挂载却会失败。 - 验证结果至少要同时包含 VMIM 终态、VMI/VM 的卷迁移状态、目标卷数据和 PV/PVC 状态。
PVC Bound、HTTP 成功或 VMIM 创建都只是中间状态。