云原生【免费下载链接】kubevirtKubernetes Virtualization API and runtime in order to define and manage virtual machines.项目地址https://gitcode.com/gh_mirrors/ku/kubevirt点击查看免费下载KubeVirt 将虚拟机以 Kubernetes 原生对象VirtualMachine、VirtualMachineInstance、Pod、PVC 等的形式编排运行这给备份/灾难恢复DR解决方案带来了一个核心挑战如何把一个 VM 的所有关联 Kubernetes 资源完整、准确地识别并收集起来。本文面向为 KubeVirt 构建备份/恢复插件的开发者和运维工程师系统讲解官方docs/backup-restore-integration.md定义的集成规范从构建 KubeVirt 对象依赖图Object Graph开始到备份/恢复时的动作清单guest 文件系统 freeze/thaw、MAC 地址去冲突、DataVolume/PVC 注解再到与备份厂商做兼容性验证的标准测试场景。读完本文你将掌握一套可以直接指导实现的可操作集成方案并能在仓库源码中找到每一处规则的对应实现。一、备份/恢复解决方案的高层操作流程KubeVirt 官方文档将备份/恢复方案定义为两组高层操作。任何面向 KubeVirt 的备份软件本质上都是围绕这几步设计工作流的。1.1 备份流程Backup步骤操作是否在本文档范围内1构建依赖图找出 VM 关联的全部 Kubernetes 资源VirtualMachine、VMI、PVC、DataVolume、ConfigMap、Secret、ServiceAccount、ControllerRevision 等✅ 是核心内容2Quiesce冻结应用调用 guest 文件系统 freeze 钩子保证磁盘数据一致✅ 是通过 freeze 指南 说明3快照 PersistentVolumeClaim 数据对 PVC 做一致性快照❌ 超出本文档范围通常由 Velero、存储厂商等实现4Unquiesce解冻应用调用 unfreeze 恢复 guest 运行✅ 是5拷贝资源定义将所有 Kubernetes 资源定义拷贝到共享存储位置❌ 超出本文档范围备份工具自身职责6可选导出快照 PVC 数据到共享存储位置❌ 超出本文档范围可用 VirtualMachineExport API步骤 3、5、6 超出本文档范围因为它们依赖具体备份工具的存储后端能力而步骤 1、2、4 是 KubeVirt 侧需要配合的关键逻辑也是本文剩余部分要展开的内容。1.2 恢复流程Restore填充 PVC 数据把快照数据恢复到 PVC由备份工具/存储后端完成超出本文档范围清洗并应用资源定义对收集到的 Kubernetes 资源定义做“清洗”Sanitize——删除不该恢复的、补充必需的注解、消除 MAC 地址冲突——然后再 apply 到目标集群。需要特别注意的是恢复时的“清洗”并不是简单地把 YAML 原样放回去而是有一套明确规则见下文“恢复动作”一节例如由 VirtualMachine 管理的 VMI 和 virt-launcher Pod 不应恢复、DataVolume 需要加cdi.kubevirt.io/storage.prePopulated注解等。二、KubeVirt 现有的备份方案官方文档明确提到了两条社区/官方路径2.1 Velero 插件kubevirt-velero-pluginVelero 是 Kubernetes 集群备份/迁移的流行工具。KubeVirt 团队活跃维护着配套的 kubevirt-velero-plugin 插件该插件实现了本文档描述的大部分逻辑依赖图构建、资源收集、注解清洗等。如果你是备份厂商这个插件的实现是理解 KubeVirt 备份集成的最佳参考实现。2.2 VirtualMachineSnapshot VirtualMachineExport APIKubeVirt 内置了 VirtualMachineSnapshot API 和 VirtualMachineExport API可以方便地在集群内备份 VirtualMachine并把 VM 卷导出供远端拷贝。但官方文档明确指出单靠这两个 API 不适合离站备份offsite backup或灾难恢复——因为它们的目标是集群内快照与数据导出而不是跨集群的资源定义迁移。因此面向备份厂商的集成仍以对象图 Velero 插件模式为主。三、构建 KubeVirt 对象依赖图Object Graph对象依赖图是备份方案的第一步也是本文档篇幅最大的核心内容。官方给出的图示 backup-graph.png 展示了 VM → VMI → Pod 以及 VM → DataVolume → PVC 的典型依赖关系图中节点代表的是资源实例而非类型VirtualMachine testvm关联VirtualMachineInstance testvm后者再关联Pod virt-launcher-testvm-XXXX同时VirtualMachine testvm关联DataVolume testvm-fedoraDataVolume 再关联同名 PVCtestvm-fedora。对象图中每个节点用以下四元组表示(APIGroup, Kind, namespace, name)例如一个 VMI 节点写作(kubevirt.io, VirtualMachineInstance, ns1, vmi1)。备份程序按这个四元组就能在 Kubernetes API 中精确 GET 到对应资源。3.1 VirtualMachine 对象图根节点apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm1 namespace: ns1 ...对应节点(kubevirt.io, VirtualMachine, ns1, vm1)spec.instancetype实例类型引用... spec: instancetype: kind: VirtualMachineInstancetype name: small revisionName: vm1-small-XXXXX-1 ...对应节点instancetype 引用会展开为两个节点(instancetype.kubevirt.io, VirtualMachineInstancetype, ns1, small)(apps, controllerrevisions, ns1, vm1-small-XXXXX-1)revisionName指向的是 KubeVirt 为实例类型生成的ControllerRevisionapps/v1资源它是 instancetype 内容在某一时刻的不可变快照恢复时必须一并带上否则 VM 无法引用到正确的实例类型内容。spec.preference偏好设置引用... spec: preference: kind: VirtualMachinePreference name: windows revisionName: vm1-windows-XXXXX-1 ...对应节点(instancetype.kubevirt.io, VirtualMachinePreference, ns1, windows)(apps, controllerrevisions, ns1, vm1-windows-XXXXX-1)spec.templateVirtualMachine 的spec.template本质上是嵌入的 VirtualMachineInstance 模板其依赖图与下面的 VMI 对象图一致见 3.2 节。源码佐证上述展开逻辑在 pkg/virt-api/rest/objectgraph.go 中均有对应实现——objectGraphMap声明了 VM/VMI/instancetype/preference/DataVolume/ControllerRevision/PVC/ConfigMap/Secret/ServiceAccount/Pod/NetworkAttachmentDefinition 等所有可能入图的资源类型第 81–96 行buildChildrenFromVM在vm.Status.Created为 true 时追加 VMI 子节点第 271–281 行getInstanceTypeMatcherResource则把 matcher 展开为 instancetype/preference 节点并把statusRef.ControllerRevisionRef或 spec 中的RevisionName展开为 ControllerRevision 节点第 436–452 行。getInstanceTypeMatcherResource还支持VirtualMachineClusterInstancetype/VirtualMachineClusterPreference集群级namespace 为空它们在图节点上被标记为optional可选节点备份时可依据策略决定是否纳入。3.2 VirtualMachineInstance 对象图根节点与 virt-launcher PodapiVersion: kubevirt.io/v1 kind: VirtualMachineInstance metadata: name: vmi1 namespace: ns1 ...对应节点(kubevirt.io, VirtualMachineInstance, ns1, vmi1)(, Pod, ns1, virt-launcher-vmi1-XXXXX)** 每个 VMI 都有一个名字唯一的对应 Podvirt-launcher。备份流程可以通过kubevirt.io/created-byVMI 的 UID标签选择器查找这个 Pod 的名字。该标签在 staging/src/kubevirt.io/api/core/v1/types.go 的 API 类型中定义CreatedByLabel。从 pkg/virt-api/rest/objectgraph.go 的getLauncherPodNode第 389–408 行可以看出官方的对象图实现实际是通过 Pod 的 OwnerReferencesKind VirtualMachineInstance 且 Name 匹配定位 launcher Pod并回退检查kubevirt.io/domain注解两种定位手段互为补充。spec.volumes[*].persistentVolumeClaimPVC 卷... spec: volumes: - name: v1 persistentVolumeClaim: claimName: pvc1 ...对应节点(, PersistentVolumeClaim, ns1, pvc1)(cdi.kubevirt.io, DataVolume, ns1, pvc1)注意当 VMI 使用 PVC 卷且该 PVC 是由 DataVolume 创建同名时图里会出现 DataVolume 节点——因为需要备份 DataVolume 定义才能恢复出“受 CDI 管理”的 PVC带正确的 owner 关系与填充注解。spec.volumes[*].dataVolumeDataVolume 卷... spec: volumes: - name: v1 dataVolume: name: dv1 ...对应节点(, PersistentVolumeClaim, ns1, dv1)(cdi.kubevirt.io, DataVolume, ns1, dv1)这里 PVC 的名字与 DataVolume 同名CDI 约定 DV 与其产物 PVC 同名。spec.volumes[*].configMap... spec: volumes: - name: v1 configMap: name: cm1 ...对应节点(, ConfigMap, ns1, cm1)spec.volumes[*].secret... spec: volumes: - name: v1 secret: secretName: s1 ...对应节点(, Secret, ns1, s1)spec.volumes[*].serviceAccount... spec: volumes: - name: v1 serviceAccount: serviceAccountName: sa1 ...对应节点(, ServiceAccount, ns1, sa1)spec.volumes[*].memoryDump... spec: volumes: - name: v1 memoryDump: claimName: pvc1 ...对应节点(, PersistentVolumeClaim, ns1, pvc1)memoryDump 卷直接指向一个 PVC无需 DataVolume 节点。spec.accessCredentials[*].sshPublicKey... spec: accessCredentials: - sshPublicKey: source: secret: secretName: my-pub-key ...对应节点(, Secret, ns1, my-pub-key)spec.accessCredentials[*].userPassword... spec: accessCredentials: - userPassword: source: secret: secretName: my-user-password ...对应节点(, Secret, ns1, my-user-password)源码佐证getAccessCredentialNodespkg/virt-api/rest/objectgraph.go 第 410–420 行对accessCredentials数组逐个处理 SSHPublicKey 与 UserPassword 的 Secret 引用addVolumeGraph第 320–387 行对 DataVolume、PVC、ConfigMap、Secret、ServiceAccount 卷分别建节点还额外处理了 cloud-init 的cloudInitNoCloud/cloudInitConfigDrive中UserDataSecretRef与NetworkDataSecretRef引用的 Secret这些是官方文档未展开、但实现里已覆盖的细节handleNetworkNodes第 454–476 行对 Multus 网络的NetworkAttachmentDefinition建可选节点支持namespace/name跨命名空间形式。该文件头注释第 45–51 行还定义了节点标签kubevirt.io/dependency-type取值storage/network/compute/config供备份程序按依赖类型过滤。后端存储 PVCBackend Storage PVC / persistent state PVC用途后端存储 PVC也称persistent state PVC用于持久化 VirtualMachineInstance 在 guest 之外发生的变更包括EFI 固件设置如 EFI vars、自定义 secure boot 证书TPM 状态TPM 内部保存的信息。启用方式VM 或 VMI 必须显式开启以下字段之一或两者才会使用该 PVCspec.domain.firmware.bootloader.efi.persistentspec.domain.devices.tpm.persistent只要任一选项为true系统就会确保后端 PVC 被创建并挂载到 VMI。如何识别后端存储 PVC该 PVC 不会出现在 VMI/VM spec 中而是由控制器在 VMI 启动后创建并管理。识别它的方式是查找persistent-state-for标签其值等于关联 VMI 的名字apiVersion: v1 kind: PersistentVolumeClaim metadata: name: persistent-state-vmi1-XXXXX namespace: ns1 labels: persistent-state-for: vmi1 ...对应节点(, PersistentVolumeClaim, ns1, persistent-state-vmi1-XXXXX)源码佐证PVCPrefix persistent-state-for常量定义在 pkg/storage/backend-storage/backend-storage.go第 52 行该文件是后端存储 PVC 的创建与管理实现。备份程序在枚举 PVC 时应额外按此标签扫描这类“隐藏”的持久状态卷否则会遗漏 EFI/TPM 状态数据导致恢复后的 VM 丢失 secure boot 配置或 TPM 内容。相关测试覆盖于 pkg/storage/backend-storage/backend-storage_test.go。3.3 VirtualMachineInstanceReplicaSet 对象图apiVersion: kubevirt.io/v1 kind: VirtualMachineInstanceReplicaSet metadata: name: vmirs1 namespace: ns1 ...对应节点(kubevirt.io, VirtualMachineInstanceReplicaSet, ns1, vmirs1)(kubevirt.io, VirtualMachineInstance, ns1, vmirs1XXXX1)*(kubevirt.io, VirtualMachineInstance, ns1, vmirs1XXXX2)** 一个 VirtualMachineInstanceReplicaSet 通常对应多个VMI 实例。备份流程可以通过kubevirt.io/vmReplicaSetReplicaSet 名称标签选择器查找这些 VMI。其spec.template的依赖展开同样参见 3.2 节 VirtualMachineInstance 对象图。四、备份动作Backup Actions4.1 Guest 文件系统 freeze/thaw 钩子为了保证 PVC 快照步骤 3时磁盘内数据一致备份流程需要对对象图中遇到的每个VirtualMachineInstance 执行 freeze/thaw对所有 VMI 执行freeze冻结 guest 文件系统完成 PVC 快照后对所有 VMI 执行thaw解冻。官方文档指引读者参考 freeze 指南 获取执行方法。要点摘录如下与备份场景直接相关freeze 需要 guest 内运行qemu-guest-agent可通过 VMI 状态中的AgentConnected条件确认 agent 是否可用VMI 提供了freeze/unfreeze子资源 APIapis/subresources.kubevirt.io/v1alpha3/.../virtualmachineinstances/name/freeze也可用 client-go 调用virtClient.VirtualMachineInstance(namespace).Freeze(vmiName, unfreezeTimeout) virtClient.VirtualMachineInstance(namespace).Unfreeze(vmiName)Freeze的unfreezeTimeout参数表示自动解冻超时防止 VMI 卡死在冻结状态设为 0 可禁用自动解冻但不推荐对不依赖 KubeVirt REST API 的通用工具可在 virt-launcher Pod 内直接执行/usr/bin/virt-freezerkubectl exec virt-launcher-example-vm-v8vxz -n demo -- /usr/bin/virt-freezer --freeze --namespace demo --name example-vm --unfreezeTimeoutSeconds 60 kubectl exec virt-launcher-example-vm-v8vxz -n demo -- /usr/bin/virt-freezer --unfreeze --namespace demo --name example-vm可通过kubectl describe vmi ... | grep Freeze检查Fs Freeze Status: frozen来确认冻结生效。五、恢复动作Restore Actions恢复阶段需要在 apply 资源定义前完成一系列“清洗”Sanitize动作官方文档按资源类型给出明确规则5.1 VirtualMachine 恢复如果恢复到另一个集群且 VM 显式设置了MAC 地址或 BIOS 序列号必须确保目标集群内没有冲突。这两个值的位置/spec/template/spec/domain/devices/interfaces/index/macAddress /spec/template/spec/domain/firmware/serial备份/恢复程序应在恢复前检查这些字段必要时清空或改写以避免同网段 MAC 冲突、同序列号导致的标识混淆。5.2 VirtualMachineInstance 恢复关键规则如果一个 VMI归属于某个 VirtualMachine由 VM 拥有则不应恢复它——KubeVirt 控制器会根据 VirtualMachine 定义自动重建 VMI。否则独立 VMI可以备份/恢复但需与 VirtualMachine 相同的 MAC 地址/BIOS 序列号预防措施/spec/domain/devices/interfaces/index/macAddress /spec/domain/firmware/serial5.3 virt-launcher Pod 恢复带virt-launcher-前缀、且归属于 VirtualMachineInstance 的 Pod不应恢复。launcher Pod 是运行时产物由 VMI 的控制器重新创建直接恢复会导致 Pod 与 VMI 状态错乱。5.4 DataVolume 恢复Succeeded阶段status.phase的 DataVolume 必须在恢复时添加以下注解否则关联 PVC 可能被破坏CDI 会重复填充导致数据污染cdi.kubevirt.io/storage.prePopulated: datavolume name处于Succeeded之外任何阶段的 DataVolume 无需添加此注解例如ImportScheduled、CloneScheduled等尚未完成填充的 DV恢复后由 CDI 重新执行填充流程。源码佐证cdi.kubevirt.io/storage.prePopulated语义与 KubeVirt 内置快照恢复的实践一致——在 pkg/storage/snapshot/restore.go 第 536 行附近恢复流程会在 DV 恢复时标记 prePopulated 以防止 DV 与 PVC 恢复期间发生竞争和重复 reconcile第 1305 行newDataVolume.Annotations[cdiv1.AnnPrePopulated] true就是实际写入该注解的位置。5.5 PersistentVolumeClaim 恢复归属于 DataVolume 的 PVC必须在备份/恢复时添加以下注解cdi.kubevirt.io/storage.populatedFor: datavolume name源码佐证populatedForPVCAnnotation cdi.kubevirt.io/storage.populatedFor定义在 pkg/storage/snapshot/restore.go 第 63 行updatePVCPopulatedForAnnotation第 1100–1108 行与第 1564–1575 行展示了该注解的写入逻辑。该注解让 CDI 知道 PVC 的数据来源 DV从而维持 DV 与 PVC 之间的所有权/填充关系避免恢复后 DV 被判定为“孤儿”而重新填充。六、备份厂商兼容性验证Validate backup partner compatibility为了帮助备份厂商评估其方案与 KubeVirt 的兼容性官方文档定义了一组标准测试场景。前提条件集群中已安装 KubeVirt CDI且备份软件与存储已就绪。验证有两条路径6.1 自动化验证厂商可以填写一个预定义 API 的模板把自身备份/恢复实现接入后通过预设环境变量运行一组基础测试。详细信息参考 kubevirt-velero-plugin 仓库的 partner-compatibility-testing 文档该仓库是官方维护的参考实现。这是官方为生态厂商提供的最便捷的验证通道。6.2 手动验证所有测试清单位于 kubevirt-velero-plugin 仓库的tests/manifests目录。使用前需要把每个 YAML 里的storageClassName替换为集群实际的存储类$ kubectl get storageclass或者用下面的命令代替测试描述中的每个 apply$ cat YAML_PATH | sed s/{{KVP_STORAGE_CLASS}}/DESIRED_STORAGE_CLASS/g | kubectl create -f -n NAMESPACE -以下 7 个场景覆盖了 KubeVirt 备份/恢复的关键资源组合每个场景都遵循“建命名空间 → 部署资源 → 写入数据 → 备份 → 删除 → 恢复 → 校验”的闭环。场景 1已停止的 VMDataVolume DataVolumeTemplate# 1. 创建命名空间 $ kubectl create ns NAMESPACE # 2. 应用空白 DataVolume 并等待其进入 Succeeded $ kubectl apply -f -n NAMESPACE blank_datavolume.yaml # 3. 应用 VM带 DV 和 DVTemplate等待其 Running $ kubectl apply -f -n NAMESPACE vm_with_dv_and_dvtemplate.yaml # 4. 写入数据通过 VM 控制台 $ virtctl console test-vm-with-dv-and-dvtemplate # 在 guest 控制台内 $ echo testing test.txt # 5. 停止 VM等待其进入 Stopped $ virtctl stop test-vm-with-dv-and-dvtemplate # 6. 对命名空间做备份等待成功完成 # 7. 删除 VM 和 DataVolume $ kubectl delete -n NAMESPACE vm test-vm-with-dv-and-dvtemplate $ kubectl delete -n NAMESPACE datavolume test-dv # 8. 从备份恢复等待完成 # 9. 校验 # - DV 应立即进入 Succeeded 状态 # - VM 处于 Stopped 状态 # - 启动 VM等待 Running验证数据test.txt存在验证重点DV 恢复后直接到达 Succeeded依赖第 5.4 节 prePopulated 注解VM 以停止态恢复、启动后数据完好。场景 2运行中的 VM独立 PVC# 1. 创建命名空间 $ kubectl create ns NAMESPACE # 2. 创建 ImportVolumeSource导入源 $ kubectl apply -f -n NAMESPACE volume_import_source.yaml # 3. 创建由 ImportVolumeSource 填充的 PVC $ kubectl apply -f -n NAMESPACE import_populator_pvc.yaml # 4. 应用 VM使用 PVC等待 Running $ kubectl apply -f -n NAMESPACE vm_with_pvc.yaml # 5. 写入数据virtctl console test-vm-with-pvcguest 内 echo testing test.txt # 6. 对命名空间做备份等待成功完成 # 7. 删除命名空间 # 8. 从备份恢复等待完成 # 9. 校验PVC 存在且 BoundVM 存在且 Running数据完好验证重点独立 PVC非 DV 管理场景下 PVC 的恢复与绑定以及使用 PVC 卷的 VM 完整恢复。场景 3热插拔卷的 VMVM with hotplug# 1. 创建命名空间 $ kubectl create ns NAMESPACE # 2. 应用 VM可热插拔等待 Running $ kubectl apply -f -n NAMESPACE vm_for_hotplug.yaml # 3. 应用空白 DV等待 Succeeded $ kubectl apply -f -n NAMESPACE blank_datavolume.yaml # 4. 向运行中的 VM 动态挂载卷 $ virtctl addvolume test-vm-for-hotplug --volume-nametest-dv # 等待挂载卷出现在 VMI 的 volumes 和 disks 列表中 # vmi.Spec.Volumes、vmi.Spec.Domain.Devices.Disks # 5. 对命名空间做备份等待成功完成 # 6. 删除命名空间 # 7. 从备份恢复等待完成 # 8. 校验 # - DV test-dv 立即进入 Succeeded # - VM 到达 Running且热插拔卷仍出现在 VMI 的 volumes 和 disks 列表中验证重点热插拔卷在备份/恢复后仍然保留在 VMI 的卷与磁盘列表这是 KubeVirt 热插拔特性的关键集成点。场景 4已停止的 VMConfigMap、Secret 与 DVTemplate# 1. 创建命名空间 $ kubectl create ns NAMESPACE # 2. 应用 ConfigMap $ kubectl apply -f -n NAMESPACE configmap.yaml # 3. 应用 Secret $ kubectl apply -f -n NAMESPACE secret.yaml # 4. 应用 VM混合卷类型等待 Running $ kubectl apply -f -n NAMESPACE vm_with_different_volume_types.yaml # 5. 停止 VM等待 Stopped # 6. 对命名空间做备份等待成功完成 # 7. 删除命名空间 # 8. 从备份恢复等待完成 # 9. 校验DV 立即 SucceededConfigMap 与 Secret 存在VM 处于 Stopped # 启动 VM等待 Running验证重点对象图 3.1/3.2 节中 ConfigMap、Secret 节点依赖类型config被正确收集并恢复。场景 5运行中的 VMAccessCredential DVTemplate# 1. 创建命名空间 $ kubectl create ns NAMESPACE # 2. 应用 AccessCredentialSecret $ kubectl apply -f -n NAMESPACE accessCredentialsSecret.yaml # 3. 应用 VM带访问凭据等待 Running $ kubectl apply -f -n NAMESPACE vm_with_access_credentials.yaml # 4. 对命名空间做备份等待成功完成 # 5. 删除命名空间 # 6. 从备份恢复等待完成 # 7. 校验DV 立即 SucceededAccessCredential 存在VM Running验证重点spec.accessCredentials引用的 SecretsshPublicKey/userPassword被正确恢复VM 以运行态恢复。场景 6instancetype 与 preference 的 VM# 1. 创建命名空间 $ kubectl create ns NAMESPACE # 2. 应用 Instancetype $ kubectl apply -f -n NAMESPACE instancetype.yaml # 3. 应用 Preference $ kubectl apply -f -n NAMESPACE preference.yaml # 4. 应用 VM等待 Running $ kubectl apply -f -n NAMESPACE vm_with_instancetype_and_preference.yaml # 检查 VM spec 中的 revision 名已更新 # vm.Spec.Instancetype.RevisionName、vm.Spec.Preference.RevisionName # 5. 对命名空间做备份等待成功完成 # 6. 删除命名空间 # 7. 从备份恢复等待完成 # 8. 校验VM 到达 Running验证重点instancetype/preference 及其 ControllerRevision见 3.1 节的恢复保证恢复后 VM 仍能解析实例类型与偏好设置。场景 7独立 DV 的 VMIVMI with a standalone DV# 1. 创建命名空间 $ kubectl create ns NAMESPACE # 2. 应用 DV带 guest-agent 镜像等待 Succeeded $ kubectl apply -f -n NAMESPACE dv-with-guest-agent-image.yaml # 3. 应用 VMI等待 Running并确认 VMI 条件中出现 AgentConnected $ kubectl apply -f -n NAMESPACE vmi_with_dv.yaml # 4. 对命名空间做备份等待成功完成 # 5. 删除命名空间 # 6. 从备份恢复等待完成 # 7. 校验DV 立即 SucceededVMI 到达 Running验证重点独立 VMI非 VM 拥有的恢复路径以及 guest-agent 就绪状态在恢复后的复现。七、实现要点速查把本文全部规则浓缩为备份/恢复程序可直接对照的清单阶段资源类型规则备份所有 KubeVirt 对象用 (APIGroup, Kind, namespace, name) 四元组建依赖图launcher Pod 用kubevirt.io/created-byVMI UID查找备份后端存储 PVC按persistent-state-forVMI name标签扫描 EFI/TPM 持久状态卷备份每个 VMI执行 freeze带自动解冻超时→ 快照后 thaw恢复VM/VMI检查并消除/spec/.../interfaces/i/macAddress与/spec/.../firmware/serial冲突恢复VMI由 VM 拥有的 VMI不恢复控制器重建恢复virt-launcher Pod不恢复控制器重建恢复DataVolumeSucceeded添加cdi.kubevirt.io/storage.prePopulated: dv name恢复被 DV 拥有的 PVC添加cdi.kubevirt.io/storage.populatedFor: dv name配套的深入阅读入口均在当前仓库内对象图实现与测试pkg/virt-api/rest/objectgraph.go、pkg/virt-api/rest/objectgraph_test.go后者覆盖了IncludeOptionalNodesfalse时排除可选节点、按kubevirt.io/dependency-type标签做 LabelSelector 过滤等用例对象图 feature gateObjectGraph见 pkg/virt-config/feature-gates.go 第 142–143 行与对象图 API 入口第 119–122 行的 gate 校验后端存储 PVCpkg/storage/backend-storage/backend-storage.go注解写入参考快照恢复路径pkg/storage/snapshot/restore.goguest 文件系统冻结docs/freeze.md 与 cmd/virt-freezer/virt-freezer.goAPI 标签定义staging/src/kubevirt.io/api/core/v1/types.go。围绕以上依赖图构建规则、恢复清洗动作和兼容性测试场景即可实现一个与 KubeVirt 官方行为一致、可纳入官方生态验证流程的备份/恢复集成。赞分享云原生【免费下载链接】kubevirtKubernetes Virtualization API and runtime in order to define and manage virtual machines.项目地址https://gitcode.com/gh_mirrors/ku/kubevirt点击查看免费下载相关推荐Velero 前身 Heptio Ark v0.9.0 实战指南Kubernetes 集群备份、恢复与 restic 卷数据备份集成Velero 前身 Heptio Ark v0.9.0 实战指南Kubernetes 集群备份、恢复与 restic 卷数据备份集成 本文以仓库中 site/示例工程AI Agent人工智能AtlasOS 显卡性能优化实战指南3 步定位瓶颈平均帧率提升约 25%AtlasOS 显卡性能优化实战指南3 步定位瓶颈平均帧率提升约 25% 如果你装了 AtlasOS 之后还是觉得帧率没达到硬件应有的水平多半不是显卡不操作系统隐私合规容器数据零丢失listmonk存储卷备份与恢复实战指南容器数据零丢失listmonk存储卷备份与恢复实战指南 邮件列表数据是业务运营的核心资产容器化部署的listmonk若未做好存储卷管理可能因容器重建导致数后端企业应用上一篇ComfyUI-SUPIR模型加载失败3个核心关键词帮你快速定位问题下一篇SteamCleaner终极指南一键清理六大游戏平台冗余文件释放硬盘空间的完整方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考