VMware vCenter Site Recovery Manager 5.0.2 | 2012 年 12 月 20 日 | 内部版本 919478

上次更新时间:2016 年 3 月 9 日

请查看发行说明以了解新增内容及更新。

发行说明内容

本发行说明包含以下主题:

新增功能

VMware vCenter Site Recovery Manager 5.0.2 提供以下改进功能:

  • vSphere Replication 管理服务器接受 MD5 证书。请参见 局限声明和限制
  • 为提高安全性,已将 OpenSSL 0.9.8m 升级到 0.9.8t。这解决了 2012 年 1 月为 OpenSSL 发布的安全建议中的问题。
  • 自动生成的证书将使用位数为 2048 的 RSA 密钥。
  • 已解决的问题中说明了缺陷修复。

本地化

VMware vCenter Site Recovery Manager 5.0.2 提供以下语言的版本:

  • 英语
  • 法语
  • 德语
  • 日语
  • 简体中文

兼容性

SRM 兼容性列表

有关当前互操作性和产品兼容性信息,请参见 VMware vCenter Site Recovery Manager 的兼容性列表

兼容的存储阵列和存储复制适配器

有关受支持的兼容存储阵列和 SRA 的当前列表,请参见 《VMware 兼容性指南》

VMware VSA 支持

SRM 5.0.2 可以使用 vSphere Replication 保护位于 vSphere Storage Appliance (VSA) 上的虚拟机。VSA 不要求存储复制适配器 (SRA) 与 SRM 5.0.2 配合使用。

安装和升级

仅当使用基于阵列的复制时,SRM 5.0.2 才能与 ESXi Server 4.0 和 4.1 以及 Virtual Infrastructure 3.5 一起运行。如果使用 vSphere Replication,无论是单独使用还是与基于阵列的复制一起使用,都必须在升级过程中将 ESXi Server 主机升级到版本 5.0、5.0 Update 1 或 5.0 Update 2。

要不升级早期版本而安装 SRM 5.0.2,请参见 《Site Recovery Manager 管理指南》  中的“安装和更新 Site Recovery Manager”  

将 SRM 5.0 或 5.0.1 升级到 SRM 5.0.2

您可以将 SRM 5.0 或 5.0.1 对位升级到 SRM 5.0.2。VMware 建议进行对位升级而不是全新安装,因为这样可保留所有历史记录报告、恢复计划、保护组和恢复计划的自定义。必须对受保护站点和恢复站点都执行升级过程。

  1. 登录到受保护站点上运行 SRM Server 的计算机。
  2. 使用数据库软件提供的工具备份 SRM 数据库。
  3. 下载并运行 VMware-srm-5.00.2-919478.exe
  4. 当系统提示您确认要升级 SRM 时,单击 [是]
  5. 单击 [下一步] 以使用之前的 SRM 安装中的设置安装 SRM 5.0.2。
  6. 单击 [是] 确认已备份 SRM 数据库。
  7. 安装完成后,请单击 [完成]
  8. 在恢复站点上重复升级过程。

升级 SRM Server 之后,必须重新安装 SRM 客户端插件。

  1. 卸载 SRM 5.0 或 5.0.1 客户端插件。
  2. 登录到 vSphere Client 实例并连接到与 SRM Server 连接的 vCenter Server。
  3. 选择 [插件] > [管理插件]
  4. 单击 [下载并安装] 以安装 SRM 5.0.2 客户端插件。
  5. 插件安装完成后,登录到 SRM 并确认早期版本中的配置已保留。
  6. 对用于连接到 SRM Server 的所有 vSphere Client 实例重复此过程。

注意:Microsoft 发布了一项安全更新,该更新使 Windows 拒绝 RSA 密钥位数小于 1024 的证书。请参见 http://support.microsoft.com/kb/2661254。这一标准将于 2013 年底提高到 2048 位。为此,SRM 5.0.2 将自动生成 RSA 密钥位数为 2048 的证书。SRM 5.0 和 5.0.1 将自动生成 RSA 密钥位数为 512 的证书。从 SRM 5.0 或 5.0.1 升级到 5.0.2 时,SRM 将保留前一次安装中的证书。因此,如果安装 Microsoft 安全更新,必须同时升级 SRM 证书,以便使用位数至少为 1024(最好使用位数为 2048)的 RSA 密钥。

  • 如果您使用的是 SRM 5.0 或 5.0.1 自动生成的证书,则升级到 SRM 5.0.2 后,可以通过以修改模式再次运行 SRM 5.0.2 安装程序,然后选择生成一个新的 2048 位证书的选项来升级证书。
  • 如果您在 SRM 5.0 或 5.0.1 中使用的证书是由证书颁发机构签署的,则必须手动升级和导入证书,从而确保这些证书使用至少 1024 位(或最好使用 2048 位)的 RSA 密钥。

将 vSphere Replication 1.0 或 1.0.1 升级到 vSphere Replication 1.0.2

SRM 5.0 中包含 vSphere Replication 1.0。SRM 5.0.1 中包含 vSphere Replication 1.0.1。SRM 5.0.2 中包含 vSphere Replication 1.0.2。将 SRM 5.0 或 5.0.1 升级到 SRM 5.0.2 不会使 vSphere Replication 1.0 或 1.0.1 自动升级到 vSphere Replication 1.0.2。vSphere Replication 1.0.2 在功能上与 vSphere Replication 1.0 和 1.0.1 相同,但修复了一些缺陷。您可以使用 vSphere Update Manager 更新 VRM 服务器和 VR 服务器。或者,您也可以使用虚拟设备管理界面 (VAMI) 来对 VRM 服务器和 VR 服务器执行更新。

重要信息:请不要选择 VAMI 中 [更新] > [设置] 下的选项来自动更新 vSphere Replication。如果选择自动更新,则 VAMI 会将 vSphere Replication 更新至最新的 5.x 版本,而该版本与 SRM 和 vCenter Server 5.0.x 不兼容。请将更新设置继续设置为 [无自动更新]

要使用 VAMI 更新 VRM 服务器,请执行以下操作:

  1. 将 SRM 服务器和客户端升级到 SRM 5.0.2。
  2. 转到 VRM 服务器配置界面,网址为 https:// VRM_server_address:8080。
  3. 以 root 用户身份登录到 VRM 服务器配置界面。
  4. 单击 更新选项卡。
  5. 单击 设置
  6. 选择 [使用指定存储库] 并将更新 URL 粘贴到 [存储库 URL] 文本框中:
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/05d561bc-f3c8-4115-bd9d-22baf13f7178/1.0.2.0
  7. 单击 状态
  8. 单击 检查更新。更新检查程序显示 1.0.2.0 版本可用。
    注意:无法将 VRM 服务器 5.1.0.1 与 SRM 5.0.2 配合使用。
  9. 单击 [安装更新] ,然后单击 [确定]
  10. 更新完成后,选择 [VRM] 选项卡,单击 [配置],然后单击 [重新启动] 以重新启动 VRM 服务器。
  11. 为恢复站点上的 VRM 服务器重复该过程。

要使用 VAMI 更新 VR 服务器,请执行以下操作:

  1. 升级 VRM 服务器。
  2. 转到 VR 服务器配置界面,网址为 https:// VR_address:5480。
  3. 以 root 用户身份登录到 VR 服务器配置界面。
  4. 单击 更新选项卡。
  5. 单击 设置
  6. 选择 [使用指定存储库] 并将更新 URL 粘贴到 [存储库 URL] 文本框中:
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/9f73d994-d8b5-11df-ace9-18a9053dae02/1.0.2.2957
  7. 单击 状态
  8. 单击 检查更新。更新检查程序显示 1.0.2 版本可用。
  9. 单击 [安装更新] ,然后单击 [确定]
  10. 更新完成后,选择 [系统] 选项卡,单击 [信息],然后单击 [重新引导] 以重新启动 VR 服务器。
  11. 为受保护的站点和恢复站点上的所有 VR 服务器重复该过程。

将 SRM 4.1.2 升级到 SRM 5.0.2

您可以将 SRM 4.1.2 对位升级到 SRM 5.0.2。VMware 建议进行对位升级而不是全新安装,因为这样可保留所有历史记录报告、恢复计划、保护组和恢复计划的自定义。要将 SRM 客户端升级到 5.0.2,必须首先卸载 SRM 4.1.2 客户端。

注意:不支持从 SRM 4.1 或 SRM 4.1.1 升级到 SRM 5.0.2。

要从 SRM 4.1.2 升级到 SRM 5.0.2,请遵循 《Site Recovery Manager 管理指南》 的“升级 SRM” 中从 SRM 4.1 或 4.1.1 升级到 SRM 5.0 的步骤。另请参见 《SRM 5 升级过程》 博客。

开放源组件

可从 SRM 下载站点获取适用于 vCenter Site Recovery Manager 5.0.2 中分发的开源软件组件的版权声明和许可证。您还可以下载 vCenter Site Recovery Manager 最新通用版本的所有 GPL、LGPL 或者其他要求公开源代码或源代码修改的类似许可证的源文件。

局限声明和限制

  • vCenter Server 5.0u2 支持将 Windows Server 2012 作为主机操作系统。SRM 5.0.2 不支持将 Windows Server 2012 作为 SRM Server 的主机操作系统。

  • 与 Storage vMotion 和存储 DRS 的互操作性
    在某些特定限制情况下,存储移动期间的可恢复性可能会受到影响,因此不支持 Site Recovery Manager 5.0.2 与 Storage vMotion (SVmotion) 或 Storage Distributed Resource Scheduler (SDRS) 配合使用,包括使用数据存储群集。如果使用 SVMotion 将受保护的虚拟机从位于保护组中的数据存储移动到未受保护的数据存储,则必须手动重新配置虚拟机保护。

  • SRM 不支持网络地址转换 (NAT)
    配置 vSphere Replication 时,必须使用对于受保护的 vSphere Replication 管理服务器(VRM 服务器)和恢复 VRM 服务器均可见的 IP 地址配置 vSphere Replication 服务器(VR 服务器)。

  • 与 vCloud Director 的互操作性
    Site Recovery Manager 5.0.2 为 vCloud Director 环境提供有限的支持。不支持使用 SRM 保护 vCloud 资源池内的虚拟机(部署到一个组织的虚拟机)。支持使用 SRM 保护 vCD 的管理结构。有关如何使用 SRM 保护 vCD Server 实例、vCenter Server 实例以及提供 vCloud Director 管理基础架构的数据库的信息,请参见 《VMware vCloud Director Infrastructure Resiliency 案例研究》

  • vSphere Replication 不支持重新保护和自动故障恢复
    仅已复制阵列的虚拟机支持重新保护和自动故障恢复。配置了 vSphere Replication 的虚拟机无法使用现有恢复计划自动故障恢复到原始站点。

  • vSphere Replication 不支持某些 vSphere 功能和 RDM
    您无法将 vSphere Replication 与 vSphere Fault Tolerance、虚拟机模板、链接克隆或物理裸磁盘映射 (RDM) 配合使用。

  • 与 vSphere Replication 的互操作性
    vSphere Replication 支持的最大磁盘大小为 2032GB。

  • 使用内存状况快照保护和恢复虚拟机
    使用内存状况快照保护虚拟机时,位于保护站点和恢复站点上的 ESX 主机必须具有兼容的 CPU,如 VMware 知识库文章 《Intel 处理器的 vMotion CPU 兼容性要求》《AMD 处理器的 vMotion CPU 兼容性要求》中所定义。主机也必须启用相同的 BIOS 功能。如果服务器的 BIOS 配置不匹配,则即使其他配置均相同,服务器仍会出现兼容性错误消息。要检查的两个最常见的功能为 Non-Execute Memory Protection (NX/XD) 和 Virtualization Technology (VT/AMD-V)。有关使用快照保护和恢复虚拟机的更多限制,请参见 《Site Recovery Manager 管理指南》 中的 “对保护和恢复虚拟机的限制”

  • 每个 SRM Server 实例的最大恢复计划数
    您可以为每个 SRM Server 实例创建的最大恢复计划数如下:

    • 基于阵列的复制:150 个恢复计划
    • vSphere Replication:250 个恢复计划

    有关您可同时运行的恢复计划数以及其他 SRM 操作限制的信息,请参见 《Site Recovery Manager 管理指南》

  • 将 MD5 证书与 vSphere Replication 管理服务器配合使用
    借助 SRM 5.0.2 和 vSphere Replication 1.0.2,您可以配置 vSphere Replication 管理服务器以使用 MD5 证书。但是,由于 MD5 证书签名算法存在易受攻击的漏洞,因此,如有可能,应至少使用 SHA-1 作为证书签名算法。可以将 MD5 证书与 SRM 5.0.2 和 vSphere Replication 1.0.2 配合使用,但应开始转换您的基础架构,以便尽快做到至少使用 SHA-1 作为证书签名算法。

已解决的问题

已在 SRM 5.0.2 中解决以下问题。

  • 在客户机操作系统自定义过程中未应用网卡属性设置

    如果在给定 MAC 地址内有 2 个适配器的情况下运行测试恢复或实际恢复并配置网卡属性,则恢复的虚拟机中的网卡属性不会更新。如果具有给定 MAC 地址的网卡拥有防病毒微型端口适配器以及物理适配器,通常会出现此问题。该问题已解决。

  • vCenter 服务状态对于 VR 管理服务显示红色警示

    向 vCenter Server 成功注册 vSphere Replication 管理服务器(VRM 服务器)后, [主页] > [vCenter 服务状态] 视图对于 VR 管理服务显示红色警示,并显示错误消息,指明 vCenter Server 无法从 VRM 服务器获取运行状况信息。该问题已解决。

  • 配置存储时,测试恢复有时会失败

    SRM 配置存储时,竞争状况可能导致测试恢复失败。测试计划显示恢复已中断,但您无法取消或移除该测试计划。如 知识库文章 2020532 中所述,如果使用多个共享裸磁盘映射 (RDM) 设备,可能出现此问题。该问题已解决。

  • 移除包含多个数据存储的保护组时,SRM 会失败

    如果您接连删除多个保护组,SRM 有时会失败。重新启动 SRM 后,SRM 会在同一位置失败。日志显示消息 Panic:Assert Failed:"1 == count" @ path/datastoreGroupData.cpp:398。该问题已解决。

  • 在受保护的站点上准备虚拟机进行迁移时,SRM 会在恢复过程中失败

    如果受保护的虚拟机所在的数据存储在多个主机之间共享,并且这些主机位于不同的数据中心,则在恢复过程中的 [准备受保护站点虚拟机进行迁移] 步骤中,SRM 可能失败。日志显示消息 SRM Panic:Assert Failed:"ok" @ path/deactivateStorage.cpp:1170。该问题已解决。

  • SRM 无限期等待连接至已恢复的虚拟机,以便在客户机操作系统上执行打开电源后脚本

    以往,如果 SRM 无法连接至已恢复的虚拟机,以便尝试在该虚拟机打开电源后在其客户机操作系统上运行脚本,则 SRM 将无限期等待。现在,SRM 不会再无限期等待连接至已恢复的虚拟机。在经过默认的 20 秒后,该请求将超时。如果该超时期限导致测试恢复失败,并显示错误: 操作超时:20 秒 (Operation timed out: 20 seconds),您可以提高该超时期限。

    1. 使用文本编辑器打开文件 C:\Program Files\VMware\VMware Site Recovery Manager\config\vmware-dr.xml
    2. 添加一个 vixOpenVmTimeout 节点,以及一个新的超时期限(以秒为单位)。例如:
      <connections>
      <vixOpenVmTimeout>30</vixOpenVmTimeout>
      </connections>
                          
    3. 重新启动 SRM 服务。
    4. 在另一端的 SRM 服务器上重复执行此配置。

  • 如果在初始安装期间对 SRM 服务器使用了 IPv6 地址,则无法修改 SRM 安装。

    如果在安装 SRM 服务器时使用了 IPv6 地址,然后尝试以修改模式运行 SRM 安装程序来修改此安装,则此修改将失败,并显示错误: VMware vCenter Site Recovery Manager 安装错误 (VMware vCenter Site Recovery Manager Setup Error)。该问题已解决。

已知问题

下列已知问题是通过严格测试而发现的,可帮助您了解在此版本中可能遇到的某些行为。

  • glibc 库中的漏洞允许执行远程代码

    glibc 中允许执行远程代码的漏洞可能会影响到 vSphere Replication 设备。

    解决办法:有关解决此问题的详细信息,请参见 http://kb.vmware.com/kb/2144289

  • 大型磁盘执行不必要的完全同步

    使用 vSphere Replication (VR) 保护的磁盘大于 256 GB 时,任何导致虚拟磁盘设备内部重新启动的操作都会致使磁盘完成完全同步。内部重新启动在以下情况下发生:

    • 重新启动虚拟机
    • 对虚拟机执行 vMotion
    • 重新配置虚拟机
    • 获取虚拟机的快照
    • 暂停并恢复复制

    完全同步由 ESX 启动,且对此问题的任何解决均涉及到 ESX 的更新。这些同步涉及到对受保护站点磁盘和恢复站点磁盘的其他 I/O,这通常需要多于恢复点目标 (RPO) 的时间,从而导致丢失 RPO 目标。ESXi Server 5.0 中存在此问题,但 ESXi Server 5.0 Update 1 中已进行修复。

    解决办法:将 ESXi Server 升级到版本 5.0 Update 1。

  • 在测试故障切换之后,LVM.enableResignature 仍保留设置为 1

    SRM 不支持其中 LVM.enableResignature 标记设置为 0 的 ESX 环境。在测试故障切换或实际故障切换期间,如果该标记尚未设置,则 SRM 会自动将 LVM.enableResignature 设置为 1。SRM 会将该标记设置为对快照卷重新签名,并将其挂载到 ESX 主机进行恢复。操作完成后,该标记仍设置为 1。有关信息,请参见 知识库文章 2010051

  • 配置过程中收到 提交事务时出现错误 (Error committing the transaction) 后,无法在虚拟机上重新配置 vSphere Replication

    在虚拟机上配置复制的过程中如果收到消息 提交事务时出现错误 (Error committing the transaction),则在虚拟机上对配置的任何重新配置尝试都会失败。出现此问题是由于在配置尝试之后,vSphere Replication 未能正确清理配置数据。因此,虚拟机复制看起来已经配置为 vSphere Replication,但事实并非如此。

    解决办法:要正确清理配置数据,请在命令行禁用虚拟机复制。

    1. 登录 ESXi 控制台。
    2. 运行命令以查找 ESXi 主机中虚拟机的 ID。
      # vim-cmd vmsvc/getallvms | grep 
      virtual_machine_name 
                          
      虚拟机 ID 是指第一列中的编号。
    3. 运行命令以禁用在上一步中找到的 ID 所对应虚拟机的复制。
      # vim-cmd hbrsvc/vmreplica.disable 
      virtual_machine_ID
                          
  • 恢复为计划的迁移之后,[强制的故障切换] 复选框仍保持选中状态

    如果在选中 [强制的故障切换] 选项的情况下运行恢复计划,然后通过选择 [计划的迁移] 恢复为计划的迁移,则在 [运行恢复计划] 向导中,[强制的故障切换] 复选框仍保持选中并处于灰显状态。此问题只会影响用户界面,SRM 的行为不会出错。

    解决办法:在取消选择 [强制的故障切换] 选项之后,关闭然后重新打开 [运行恢复计划] 向导。

  • 如果占位数据存储对于受保护群集内的所有主机不可见,则恢复或迁移操作会失败

    在恢复和迁移期间,占位虚拟机将被替换为已恢复虚拟机。如果群集内有多个主机位于恢复站点,则所有占位数据存储必须可用于群集内的所有主机。否则,交换虚拟机会失败。SRM 不会阻止您选择对于群集内所有主机不可用的占位数据存储。如果占位数据存储对于所有主机不可见,则恢复计划会失败,并出现错误 错误 - 无法访问文件 [datastore]" 无法访问文件 [datastore] 无法取消注册受保护虚拟机 (Error - Unable to access file [datastore]" Unable to access file [datastore] Failed to unregister protected VMs)。主机必须具有对同时包含占位虚拟机和已恢复虚拟机的数据存储的访问权限。

    解决办法:手动检查占位虚拟机和已恢复虚拟机的数据存储是否对受保护群集内的所有主机都可见。

  • 在升级后,VRM 服务器和 VR 服务器版本信息未在虚拟机摘要中更新

    如果将 vSphere Replication 管理服务器(VRM 服务器)设备的现有安装从 1.0 版升级到 1.0.1 版,则在虚拟机 [摘要] 选项卡中不会更新 VRM 服务器和 VR 服务器的版本号。在 vCenter Server 清单中选择 VRM 服务器或 VR 服务器时,[摘要] 选项卡仍显示版本 1.0.0.0,即使 VRM 服务器已更新至 1.0.1。如果重新安装 VRM 服务器 1.0.1 版,则 [摘要] 选项卡会显示正确的版本号。

    解决办法:在 VRM 服务器虚拟设备管理界面中检查版本号:

    1. 登录到 https:// VRM_server_IP_address:8080。
    2. 选择 [更新] 选项卡。
    3. 单击 状态。版本号为 1.0.1.0。

    或者,您可以在 vSphere Client 中的 VRM 服务器或 VR 服务器控制台中查看正确版本号。

  • vSphere Replication 管理服务器可以使用不支持的数据库

    可以将 vSphere Replication 管理服务器(VRM 服务器)配置为使用不支持的数据库,VRM 服务器配置将成功完成而不会出现任何关于数据库支持的警告。不过,使用不受支持的数据库会导致不可预知的行为。以下数据库已经过完全测试并支持与 VRM 服务器一起使用:

    • SQL Server 2005 SP4 64 位
    • SQL Server 2008 R2 SP1 64 位
    • SQL Server 2008 R2 64 位

  • 一些 SRA 在故障切换过程中错误地处理特定时区

    测试故障切换和实际故障切换可能停止,并显示以下错误: 无法使用阵列对“array-pair-999”为组“protection-group-999”创建副本设备的快照: Vmacore::SystemException“参数错误。" (87) (Failed to create snapshots of replica devices for group 'protection-group-999' using array pair 'array-pair-999': Vmacore::SystemException "The parameter is incorrect. " (87))。出现此错误是因为存储阵列返回到 SRA 的时区处理不当。1970 年 1 月 1 日之前的所有时间戳都将遇到此问题。有关详细信息和解决办法,请参见 知识库文章 2018597

  • 从 SRM 4.1.2 升级到 SRM 5.0.2 的过程中, srm-migration importConfig 命令因数据存储对象 ID 更改而失败

    SRM 5.0.2 升级过程顺利完成,vCenter Server 会重新启动,并且主机、客户机和存储会全部联机,并且与 vCenter Server 服务停止时所处的状态相同。但是,SRM 迁移过程中,保护组导入会失败,并显示以下错误:

    正在跳过对组 ( group) 中所有虚拟机的虚拟机保护,原因是出现错误: 一个或多个数据存储已在其他组中得到保护或当前未复制(Skipping VM protection for all VMs in group ( group) due to an error: One or more datastores are either already protected in a different group or not currently replicated)。

    SRM exportConfig.xml 文件中列出的数据存储对象 ID 与 MOB 浏览器中显示的相同数据存储对象 ID 不同。此问题与 知识库文章 2007404 中所述的问题相关。

    解决办法:编辑 exportConfig.xml 以使用 MOB 浏览器中的数据存储对象 ID 并重新运行 srm-migration importConfig 命令。

  • 韩语操作系统中事件显示错误

    vSphere Client 启动时,会确定运行时所用的区域设置,然后根据区域设置选择要显示的消息集。在韩语操作系统中安装 vSphere Client 时,客户端会从 vCenter Server 安装的 ko文件夹请求消息,因为 vCenter Server 和 vSphere Client 已本地化为韩语。尽管 vCenter Server 和 vSphere Client 已本地化为韩语,但 SRM 尚未本地化。因此,会显示 XXX消息,而不是 SRM Server 消息。要解决此问题,请为 C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\中的 en文件夹创建副本。将该文件夹从 en重命名为 ko,然后重新启动 vCenter Server 和 SRM 服务。

  • SRM UI 中 [阵列管理器] 视图的 [设备] 选项卡中显示重复卷

    某个 LUN 的目标编号与其他 LUN 的源编号相同时,会出现此问题。这是 UI 问题,不会影响测试恢复或实际恢复。

  • 虚拟机的恢复或测试工作流失败,并出现以下错误: 错误 - 与 ESX 或客户机虚拟机通信时出现意外错误“3008”:无法连接到虚拟机 (Error - Unexpected error '3008' when communicating with ESX or guest VM: Cannot connect to the virtual machine)。

    在极少数情况下,当配置 IP 自定义或虚拟机在客户机内的标注时,如果恢复站点群集处于全自动 DRS 模式,则会出现该错误。意外的 vMotion 可能会导致与虚拟机的通信暂时失败,从而出现自定义脚本错误。

    解决办法:重新运行恢复计划。如果该错误仍然存在,请将恢复站点群集 DRS 配置为手动模式,然后再重新运行恢复计划。

  • 恢复失败并显示以下错误消息: 为组创建测试泡状映像时出错... (Error creating test bubble image for group...)详细的异常为: 为数据存储获取主机挂载时出错: managed-object-id... (Error while getting host mounts for datastore: managed-object-id...)此对象已被删除或尚未完全创建 (The object has already been deleted or has not been completely created)。

    如果您正在运行测试恢复或计划的恢复,而该恢复计划失败并出现特定异常,则表示用于存储复制数据的 LUN 已临时与 ESXi 断开连接。重新连接后,复制将继续照常运行,并且不会丢失任何复制数据。在以下情形下将发生此异常:

    • vSphere Replication 找不到 LUN,因为此 LUN 已更改其内部 ID。
    • 如果将包含目标数据存储的主机从 vCenter 清单中移除并稍后添加它,则该目标数据存储内部 ID 将发生更改。

    您必须手动重新配置复制以刷新此新 ID。

    解决办法:如果主站点不再可用,请联系 VMware 技术支持以获取有关使用新的数据存储受管对象 ID 手动更新 VRMS 数据库的说明。如果主站点仍然可用,请执行以下操作:

    1. 在已失败的恢复计划上执行清理操作。
    2. 在 vSphere Replication 视图的 [虚拟机] 选项卡中,右键单击一个虚拟机,然后选择 [配置复制]
    3. 单击 [下一步],然后单击 [浏览] 更改已断开但随后又重新连接的数据存储上的文件位置,并像往常一样选择相同的数据存储和文件夹位置。
    4. 重用现有磁盘并重新配置虚拟机的复制。vSphere Replication 管理服务器会发现 vCenter Server 中已更改的数据存储标识(受管对象 ID)。
    5. 等待初始同步完成。此同步将使用现有磁盘并检查数据一致性。