VMware vCenter Site Recovery Manager 5.0.1 | 2012 年 3 月 15 日 | 内部版本 633117

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

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

发行说明内容

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

新增功能

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

  • 可用于在发生以下情况时恢复虚拟机的强制故障切换:存储阵列在受保护站点发生故障,从而导致受保护虚拟机难以管理且无法关闭、关闭电源或取消注册。
  • 已解决的问题中说明了缺陷修复。

本地化

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

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

兼容性

SRM 兼容性列表

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

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

有关受支持的兼容存储阵列和 SRA 的当前列表,请参见 Site Recovery Manager 存储合作伙伴兼容性列表

VMware VSA 支持

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

安装和升级

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

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

从 SRM 5.0 升级到 SRM 5.0.1

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

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

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

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

从 vSphere Replication 1.0 升级到 vSphere Replication 1.0.1

SRM 5.0 中包含 vSphere Replication 1.0。SRM 5.0.1 中包含 vSphere Replication 1.0.1。将 SRM 5.0 升级到 SRM 5.0.1 不会使 vSphere Replication 1.0 自动升级到 vSphere Replication 1.0.1。vSphere Replication 1.0.1 在功能上与 vSphere Replication 1.0 相同,但修复了一些缺陷。

您可以运行带有 vSphere Replication 1.0 的 SRM 5.0.1,也可以将 vSphere Replication 升级到 1.0.1 版本,以便从该版本的缺陷修复中受益。您可以单独升级 vSphere Replication Management Server (VRM Server) 和 vSphere Replication (VR) Server。

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

升级 VRM Server:

  1. 将 SRM Server 和客户端升级到 SRM 5.0.1。
  2. 转到 VRM Server 配置界面,地址为 https:// VRMS_IP_address:8080。
  3. 以 root 用户身份登录到 VRM Server 配置界面。
  4. 选择 [更新] 选项卡。
  5. 单击 检查更新。更新检查程序显示 1.0.1 版本可用。
  6. 单击 [安装 更新]
  7. 选择 [VRM] > [配置] 选项卡,然后单击 VRM Server 状态下的 [重新启动] 按钮来重新启动 VRM Server。
  8. 在恢复站点上为 VRM Server 重复该过程。

升级 VR Server:

  1. 升级 VRM Server。
  2. 转到 VR Server 配置界面,地址为 https:// VR_IP_address:5480。
  3. 以 root 用户身份登录到 VR Server 配置界面。
  4. 选择 [更新] 选项卡。
  5. 单击 检查更新。更新检查程序显示 1.0.1 版本可用。
  6. 单击 [安装 更新]
  7. 选择 [系统] > [信息] 选项卡,然后单击 [重新引导] 按钮重新启动 VR Server。
  8. 在恢复站点上为 VR Server 重复该过程。

从 SRM 4.1.2 升级到 SRM 5.0.1

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

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

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

开放源组件

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

局限声明和限制

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

  • SRM 不支持网络地址转换 (NAT)
    配置 vSphere Replication 时,必须使用对于受保护的 vSphere Replication Management Server (VRM Server) 和 Recovery VRM Server 均可见的 IP 地址配置 vSphere Replication Server (VR Server)。

  • 与 vCloud Director 的互操作性
    Site Recovery Manager 5.0.1 为 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) 配合使用。

  • 使用内存状况快照保护和恢复虚拟机
    使用内存状况快照保护虚拟机时,位于保护站点和恢复站点上的 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 管理指南》 中的 “对保护和恢复虚拟机的限制”

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

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

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

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

已解决的问题

  • 计划的迁移可能导致 ESX 主机速度下降

    在计划的迁移过程中,SRM 首先指示 ESX 主机卸载复制的数据存储,并分离备份这些数据存储的 LUN。接下来,SRM 指示存储阵列软件将已分离的 LUN 设为只读。此过程可帮助确保 ESX 主机上的设备不会遇到要迁移的数据存储和 LUN 的全部路径异常 (APD) 情况。迁移包含 RDM 的虚拟机可能导致 RDM LUN 进入 APD 情况。RDM 进入 APD 情况后,ESX 主机会继续重新尝试与丢失的 RDM LUN 建立连接。随着不可用的 RDM 数量的增加,ESX 主机尝试重新连接到丢失的 RDM 的次数也随之增加。如果这种情况继续出现,ESX 主机的响应速度可能会下降,最终 vCenter Server 可能会发现主机无响应。某些存储阵列更容易出现这种情况。例如,当 SRA 在每个 LUN 的 iSCSI 目标上支持 RDM 时,更容易出现这种情况。此问题现已修复。

  • SRM 任务清理过快导致 ManagedObjectNotFound 异常

    在 SRM 任务完成后一分钟会从 vmware-dr 服务移除此任务。如果 SRM 引用了已移除的任务对象,则会返回 ManagedObjectNotFound 异常,并显示错误消息 对象已删除或未完全创建 (The object has already been deleted or has not been completely created)。清理任务的默认时间是一分钟。如果遇到此问题,您可以通过设置 config.xml 文件中的 Topology.drTaskCleanupTime 参数来配置清理时间。

    <topology>
    <drTaskCleanupTime>300</drTaskCleanupTime>
    </topology>

  • 按 CPU 许可证计数错误

    购买了 SRM 1.x 和 SRM 4.0 的某些客户可能仍在使用按 CPU 分配的许可证。他们可以继续通过按 CPU 许可证来使用 SRM 5.0.1。在 SRM 5.0 中,用于计算使用的 CPU 许可证数目的公式极不严格。在这种情况下,该转换可能会向 SRM 5.0 错误授予过多的按 CPU 许可证。此问题已在 SRM 5.0.1 中修复,并对数量不足的许可证有更为严格的警告。

  • 在对跨两个磁盘分区的复制数据存储中的虚拟机进行保护时,导致 SRM 意外停止并无法重新启动

    如果对跨同一设备上两个磁盘分区的复制数据存储中所包含虚拟机进行保护,则在重新计算数据存储组时,SRM 会意外停止。SRM 日志显示错误 Panic:Assert Failed:"ok" @ d:\build\ob\bora-474459\srm\public\persistence/saveLoadUtils.h:329。然后 SRM Server 无法重新启动。该问题已解决。

  • 短时间的网络通信中断可能导致 SRM Server 永远处于等待状态

    如果受保护站点和恢复站点之间的网络通信中断时间小于五分钟,则 SRM Server 会变得无响应。之所以出现此问题,是因为 SRM 服务器缺少更新结果,而且在网络中断期间服务器端从远程站点调用 waitforupdate 超时。通过在 waitforupdate 调用中引入客户端超时值已解决该问题。默认的客户端超时值为 5 分钟。

  • 重新启用测试和恢复期间重复主机重新扫描

    SRM 4.1 提供了一个可配置的选项 storageProvider.hostRescanCnt,通过它可以在测试和恢复期间重复扫描主机。在 SRM 5.0 中不包含该选项,但在 SRM 5.0.1 的 [高级设置] 中又将其还原。在 [站点] 视图中右键单击站点,选择 [高级设置],然后选择 [storageProvider]。请参见 知识库文章 1008283

  • 自定义规范不会为 Red Hat Enterprise Linux 5.x 配置网关

    Red Hat Enterprise Linux 5.x 虚拟机的映像自定义不能正确配置网关。因此,如果在自定义过程中指定了一个新的网关来恢复 RHEL 5.x 虚拟机,则新的网关条目会附加到 /etc/sysconfig/network-scripts/route-ethX 文件。RHEL 网络服务会拾取上述文件的第一个条目,即保护站点上原有的网关设置,而不会拾取用户在自定义过程中指定的网关变更。该问题已解决。

  • 在因恢复计划位于错误的上下文中而暂停后,Recovery SRM Server 意外停止

    在受保护站点和恢复站点暂停后,恢复站点中的 SRM Server 在重新启动时会意外停止,并显示错误 Recovery Plan 计划上的 CreateRemoteSuspendVmListViewAndCallback 位于错误的上下文中 (CreateRemoteSuspendVmListViewAndCallback on plan Recovery Plan on wrong context)。该问题已解决。

  • 如果将区域设置为简体中文的 SRM 与 vCenter Server Appliance 配合使用,则在配置 vSphere Replication 时会导致无效区域设置错误

    如果将区域设置为简体中文的 SRM 与 vCenter Server Appliance 配合使用,则在虚拟机上尝试配置 vSphere Replication 时会失败,并出现无效区域设置错误。该问题已解决。

  • 在开始检查 CPU 许可证使用情况之后,SRM 在启动期间意外停止

    在某些情况下,SRM 在检查 CPU 许可证使用情况时会意外停止,并出现错误 结果中包含意外对象: vim.VirtualMachine (Unexpected Object in results: vim.VirtualMachine)。该问题已解决。

  • 在修复模式下运行 SRM 安装程序会删除 exportConfig.xml 文件

    在从 SRM 4.1.x 到 5.0.x 的对位升级过程中,SRM 会创建包含以下项的详细信息的 exportConfig.xml 文件:清单映射、数据存储映射、受保护的虚拟机和组、恢复计划等。在升级后,您可以使用该文件将数据迁移到 SRM 数据库。不过,如果在将数据迁移到数据库之前使用修复模式运行 SRM 安装程序,则安装程序会删除 exportConfig.xml。该问题已解决,在修复模式下运行安装程序不会删除 exportConfig.xml 文件。

  • 对虚拟机进行 IP 自定义失败,错误代码 14010

    尝试配置不是 VMware 特有的适配器时,对虚拟机进行 IP 自定义会失败,并出现错误 通信时出错,“错误代码: 14010”'14010'(There was an error in communication' Error Code: '14010')。该问题已解决,IP 自定义现在会忽略非默认网络适配器并且只配置物理适配器。

  • 如果 SRA 从多个存储设备获取重复的快照 ID,则测试恢复会失败

    运行测试恢复会失败,并出现错误 Panic:Assert Failed:"runtimeInfo._results != 0 (Missing results in plan:recovery-plan-10257)" @ d:/build/ob/bora-474459/srm/src/recovery/engine/manager.cpp:1300^M。出现该问题是由于存储复制适配器 (SRA) 允许不同的存储设备使用相同的快照 ID,而 SRM 要求快照 ID 必须是唯一的。该问题只影响测试恢复,而不影响实际恢复。该问题已解决,SRM 现在接受重复的快照 ID。

  • 当许多网络选项都可用时,无法向下滚动恢复计划的网络列表

    如果 SRM 环境中有超过 30 个网络可用,则在创建恢复计划时可供选择的可用网络完整列表将不可见。该问题已解决,现在您可以向下滚动完整列表。

已知问题

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

  • 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 Server 和 VR Server 版本信息未在虚拟机摘要中更新

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

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

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

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

  • 可以使用 vSphere Replication Management Server 不支持的数据库

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

    • 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.1 的过程中, srm-migration importConfig 命令因数据存储对象 ID 更改而失败。

    SRM 5.0.1 升级过程顺利完成,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 服务器消息。要解决此问题,请为 C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\中的 en文件夹创建副本。将该文件夹从 en重命名为 ko,然后重新启动 vCenter Server 和 SRM 服务。

  • 虚拟机的恢复或测试工作流失败,并出现以下错误: 错误 - 与 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. 等待初始同步完成。此同步将使用现有磁盘并检查数据一致性。