解决将 VMware VM 或物理计算机故障转移到 Azure 时出现的错误

Artículo
10/28/2024

在执行从虚拟机到 Azure 的故障转移时，可能会收到以下错误之一。若要解决错误，请为每个错误条件使用所述步骤。

故障转移失败，错误 ID 为 28031

Site Recovery 无法在 Azure 中创建故障转移的虚拟机。以下其中一个原因也可能导致此情况的发生：

没有足够的配额可用于创建虚拟机：可以通过转到“订阅”->“使用情况 + 配额”来检查可用配额。可以打开新的支持请求来增加此配额。
尝试在同一个可用性集内故障转移不同大小系列的虚拟机。确保在同一个可用性集中选择相同大小系列的所有虚拟机。可以转到虚拟机的“计算”设置来更改大小，然后重试故障转移。
订阅上有一个阻止创建虚拟机的策略。请更改此策略以允许创建虚拟机，然后重试故障转移。

故障转移失败，错误 ID 为 28092

Site Recovery 无法为故障转移的虚拟机创建网络接口。请确保订阅中有足够的配额来创建网络接口。可以通过转到“订阅”>“使用情况 + 配额”来检查可用配额。可以打开新的支持请求来增加此配额。如果你拥有足够的配额，则这可能是一个间歇性的问题，请重试该操作。如果即使在重试后问题仍然存在，请在本文档结尾处留下注释。

故障转移失败，错误 ID 为 70038

Site Recovery 无法在 Azure 中创建故障转移的经典虚拟机。这可能是因为：

创建虚拟机所需的其中一个资源（如虚拟网络）不存在。在虚拟机的“网络”设置下创建虚拟网络，或者将设置修改为已经存在的虚拟网络，然后重试故障转移。

故障转移失败，错误 ID 为 170010

Site Recovery 无法在 Azure 中创建故障转移的虚拟机。发生此情况可能是因为本地虚拟机上执行的混合的一个内部活动失败。

若要启动 Azure 中的任何计算机，Azure 环境需要某些驱动程序处于引导启动状态，并要求 DHCP 之类的服务处于自动启动状态。因此，在进行故障转移时，混合活动会将 atapi、intelide、storflt、vmbus 和 storvsc 驱动程序的启动类型转换为引导启动。它还会将 DHCP 之类的一些服务的启动类型转换为自动启动。此活动可能会由于环境特定问题而失败。

若要手动更改 Windows 来宾 OS 的驱动程序的启动类型，请执行以下步骤：

下载“非混合”脚本并如下所述运行脚本。此脚本检查 VM 是否需要混合。

.\Script-no-hydration.ps1

如果需要混合，则它提供以下结果：
```
REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0

This system doesn't meet no-hydration requirement.
```
如果 VM 满足“非混合”要求，则脚本会提供结果“此系统满足‘非混合’要求”。在此情况下，所有驱动程序和服务都处于 Azure 所需的状态，并且在 VM 上进行混合是非必需的。

如果 VM 不满足“非混合”要求，则按下面所述运行“非混合”脚本。

.\Script-no-hydration.ps1 -set

这将转换驱动程序的启动类型并提供如下所示的结果：

REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0

Updating registry:  REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc   start =  0

This system is now no-hydration compatible.

故障转移失败并出现一条错误，其中指出虚拟机网络适配器的副本 IP 地址无效

如果未正确清理先前的测试故障转移操作，则计算机的测试故障转移或故障转移操作可能会失败，并显示错误“虚拟机网络适配器的一个或多个副本 IP 地址无效”。因此，测试计算机可能仍存在于 Azure 环境中，并且可能使用相同的 IP 地址。它会导致虚拟机的目标配置变得至关重要。

若要解决此问题，请确保已执行完整的测试故障转移清理，以便故障转移或测试故障转移操作成功。

由于虚拟机上的“连接”按钮已灰显，无法连接/通过 RDP/SSH 连接到已故障转移的虚拟机

有关 RDP 问题的详细故障排除说明，请参阅此处的文档。

有关 SSH 问题的详细故障排除说明，请参阅此处的文档。

如果 Azure 中故障转移后的 VM 上的“连接”按钮灰显，并且你未通过 Express Route 或站点到站点 VPN 连接来连接到 Azure，则执行以下操作：

转到“虚拟机”>“网络”，单击所需网络接口的名称。
导航到“IP 配置”，然后选择所需 IP 配置的名称字段。
若要启用公共 IP 地址，请选择“启用”。
单击“配置所需设置”>“新建”。
输入公共地址的名称，选择“SKU”和“分配”的默认选项，然后选择“确定”。
现在，选择“保存”以保存所做的更改。
关闭面板并导航到虚拟机的“概述”部分以进行连接/通过 RDP 连接。

无法连接/RDP/SSH - VM“连接”按钮不可用

如果 Azure 中已故障转移的 VM 的“连接”按钮可用（未灰显），则请检查虚拟机上的“启动诊断”，查看是否有此文中所列的错误。

如果虚拟机尚未启动，请尝试故障转移到以前的恢复点。
如果虚拟机中的应用程序未启动，请尝试故障转移到应用一致的恢复点。
如果虚拟机已加入域，请确保域控制器正确运行。可以按照下面给出的步骤执行此操作：

a. 在同一网络中创建新的虚拟机。

b. 确保它能够加入到应出现已故障转移的虚拟机的同一域。

c. 如果域控制器未正确运行，请尝试使用本地管理员帐户登录到故障转移的虚拟机。
如果使用自定义 DNS 服务器，请确保可以访问该服务器。可以按照下面给出的步骤执行此操作：

a. 在同一网络中创建新的虚拟机；

b. 检查虚拟机是否能够使用自定义 DNS 服务器解析名称

注意

启用除“启动诊断”以外的任何设置，都需要在故障转移之前在虚拟机中安装 Azure VM 代理

将基于 UEFI 的计算机故障转移到 Azure 后无法打开串行控制台

如果可以使用 RDP 连接到计算机，但无法打开串行控制台，请执行以下步骤：

如果计算机操作系统是 Red Hat 或 Oracle Linux 7.*/8.0，请在具有根权限的故障转移 Azure 虚拟机上运行以下命令。在执行命令后重启 VM。
```
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
```

意外关闭消息（事件 ID 6008）

在故障转移后启动 Windows VM 时，如果在恢复后的 VM 上收到意外的关闭消息，则表明在用于故障转移的恢复点中未捕获 VM 关闭状态。当恢复到 VM 未完全关闭的时间点时会发生此情况。

对于计划外故障转移，这通常不需要担心，通常可以忽略。如果已计划故障转移，请确保在故障转移之前 VM 正常关闭，并提供足够的时间让待发送的本地复制数据发送到 Azure。然后使用“故障转移”屏幕上的“最新”选项，将 Azure 上的任何待处理数据处理到一个恢复点中，随后用于 VM 故障转移。

无法选择数据存储

如果在尝试重新保护已经历故障转移的虚拟机时在 Azure 门户中看不到数据存储，则表明存在此问题。这是因为主目标在添加到 Azure Site Recovery 的 vCenter 下未识别为虚拟机。

有关重新保护虚拟机的详细信息，请参阅故障转移到 Azure 后，将计算机重新保护并故障回复到本地站点。

若要解决问题，请执行以下操作：

在 vCenter 中手动创建管理源计算机的主目标。数据存储将在执行后续 vCenter 发现和刷新结构操作后可用。

注意

发现和刷新结构操作可能需要最多 30 分钟才能完成。

在 CS 上注册 Linux 主目标失败，出现 TLS 错误 35

由于在主目标上启用了“经过身份验证的代理”，因此在配置服务器上注册 Azure Site Recovery 主目标失败。

安装日志中的以下字符串指示了此错误：

RegisterHostStaticInfo encountered exception config/talwrapper.cpp(107)[post] CurlWrapper Post failed : server : 10.38.229.221, port : 443, phpUrl : request_handler.php, secure : true, ignoreCurlPartialError : false with error: [at curlwrapperlib/curlwrapper.cpp:processCurlResponse:231]   failed to post request: (35) - SSL connect error.