通过水化为 Azure 准备本地磁盘

一些本地虚拟机（VM）需要在启动和连接 Azure 前更改配置。 Azure Site Recovery 可在测试、计划内或计划外故障切换期间，通过 hydration 过程进行这些更改。 Hydration 仅适用于符合条件的 Hyper-V-Azure 和 VMware to-Azure 保护机器及支持的操作系统版本。其他已为 Azure 做好准备的复制路径不会使用临时水合虚拟机。

是否需要水合取决于所选恢复点以及源虚拟机和目标虚拟机的配置。如果在故障转移前没有准备好不支持的操作系统，恢复的虚拟机可能无法启动或无法连接网络。

补水机制

Site Recovery解析所选恢复点，并准备该恢复点中磁盘的目标副本。根据复制方法的不同，准备工作可能包括复制和验证虚拟硬盘以及创建托管磁盘。在选择恢复点之后添加的磁盘，切换到那个旧点时不会被包含在内。
Site Recovery 创建临时辅助虚拟机，并将准备好的源磁盘作为数据磁盘附加。对于 Windows 系统，源 OS 磁盘通常处于已附加状态。对于Linux，通常会连接所有在所选恢复点的受保护磁盘。
Site Recovery 在附加磁盘上运行所需的操作系统准备。
Site Recovery 会分离已准备好的磁盘并尝试移除临时资源。
Site Recovery 通过使用准备好的磁盘创建最终恢复的虚拟机。辅助虚拟机是临时的，永远不会被转换成恢复的虚拟机。

为了托管辅助虚拟机，Site Recovery 可以在你的订阅中创建网络接口、虚拟网络、子网和网络安全组。如果 Azure Policy 阻止了这些网络资源的创建，Site Recovery 会尝试使用已配置为复制的目标虚拟网络和子网。虚拟网络必须允许目标区域的存储服务标签的出站访问。有关详细信息，请参阅可用服务标记。

临时辅助虚拟机和临时映像磁盘使用平台管理加密，不支持客户管理密钥（CMK）。此限制仅适用于临时水合产生的伪影。验证过的磁盘加密集和CMK设置仍适用于最终恢复磁盘。

关于辅助 VM 的大小要求和选择行为，请参见排查水化问题。

在混合过程中执行的更改

准备脚本根据要迁移的源 VM 的 OS 类型执行以下更改。还可以使用本部分作为指南，为不支持系统配置的操作系统版本手动准备 VM 以进行故障切换。

Windows 服务器
Linux 服务器

发现并准备 Windows OS 卷区。

在执行相关配置更改之前，准备好的脚本将验证选择的 OS 磁盘是否适合故障转移。准备脚本将查看系统可见的所有附加卷，并在 SYSTEM 注册表配置单元文件路径中查找源 OS 卷。

此步骤将执行以下操作：
- 在附加到临时 VM 的 OS 磁盘上装载每个分区。
- 装载分区后查找 \Windows\System32\Config\System 注册表文件。
- 如果找不到这些文件，则卸载该分区，并继续搜索正确的分区。
- 如果这些文件不在任何分区上，则可能表示选择了错误的 OS 磁盘，或者 OS 磁盘已损坏。 Azure Site Recovery 将在故障转移过程中失败，并出现相应的错误。
注释

如果您是手动准备服务器以进行故障转移，则不需要此步骤。
进行启动和连接相关的更改。

检测到源 OS 卷文件后，准备脚本会将 SYSTEM 注册表配置单元加载到临时 Azure VM 的注册表编辑器中，并执行以下更改以确保 VM 正常启动和连接。如果 OS 版本不支持混合，则需要手动配置这些设置。
1. 验证是否存在所需的驱动程序。
  
  确保所需的驱动程序已安装并设置为在引导启动时加载。这些 Windows 驱动程序允许服务器与硬件和其他连接设备进行通信。
  - IntelIde.sys
  - Atapi
  - Storflt
  - Storvsc
  - VMbus
2. 将存储区域网络（SAN）策略设置为“全部联机”。
  
  此操作可确保 Azure VM 中的 Windows 卷使用的驱动器号分配与本地 VM 相同。默认情况下，将为 Azure VM 分配驱动器 D: 用作临时存储。这种驱动器分配会导致所有其他附加存储驱动器分配递增一个字母。若要避免这种自动分配，并确保 Azure 将下一个可用驱动器号分配给其临时卷，请将存储区域网络 (SAN) 策略设置为“全部联机”。
  
  若要手动配置此设置，请执行以下操作：
  - 在本地服务器上，使用提升的权限打开命令提示符并输入 diskpart。
  - 输入 SAN。如果未保留来宾操作系统的驱动器号，则会返回 Offline All 或 Offline Shared。
  - 在 DISKPART 提示符下，输入 SAN Policy=OnlineAll。此设置可确保将磁盘联机，并确保可以读取和写入这两个磁盘。
设置 DHCP 启动类型。

准备脚本还会将 DHCP 服务启动类型设置为自动。这将使迁移的 VM 能够获取 IP 地址，并在故障转移后建立连接。请确保配置了 DHCP 服务，并且其状态为“正在运行”。

若要手动编辑 DHCP 启动设置，请在 Windows PowerShell 中运行以下示例：
```
Get-Service -Name Dhcp
Where-Object StartType -ne Automatic
Set-Service -StartupType Automatic
```
禁用 VMware 工具。

将 VMware 工具服务启动类型（如果存在）设置为“已禁用”，因为 Azure 中的 VM 不需要它们。

注释

若要连接到 Windows Server 2003 VM，必须在 Azure VM 上安装 Hyper-V 集成服务。 Windows Server 2003 计算机默认未安装此程序。请参阅本文进行安装和故障转移的准备。
安装 Azure 来宾代理。

注释

Windows Server 2008、2008 R2、2012 和 2012 R2 已达到支持终止（EOS）。相应地查看使用情况和计划 OS 升级和迁移。有关详细信息，请参阅对 [特定产品或服务] 的支持结束。

Azure Site Recovery 将尝试安装 Azure 虚拟机代理（VM 代理），这是一个安全的轻型进程，用于管理虚拟机（VM）与 Azure Fabric 控制器的交互。 VM 代理在启用和执行 Azure 虚拟机扩展方面起主要作用，这些扩展支持 VM 的部署后配置，例如安装和配置软件。 Azure Site Recovery 会自动在 Windows Server 2008 R2 及更高版本上安装 Windows VM 代理。

可以使用 Windows 安装程序包手动安装 Windows VM 代理。若要手动安装 Windows VM 代理，请下载 VM 代理安装程序。还可以在 GitHub Windows IaaS VM 代理版本中搜索特定版本。 VM 代理在 Windows Server 2008 (64 bit) 和更高版本上受支持。

若要检查 Azure VM 代理是否已成功安装，请打开任务管理器，选择“详细信息”选项卡，并查找名为 WindowsAzureGuestAgent.exe 的进程。存在该进程表示 VM 代理已安装。还可以使用 PowerShell 检测 VM 代理。

显示成功安装 Azure VM 代理的屏幕截图。

执行上述更改后，系统分区将被卸载。 VM 现已准备好进行故障转移。详细了解 Windows 服务器的更改。

发现并装载 Linux OS 分区。

在执行相关配置更改之前，准备好的脚本将验证选择的 OS 磁盘是否适合故障转移。脚本将收集有关所有分区、其 UUID 和装入点的信息。脚本将在所有这些可见分区中查找 /boot 和 /root 分区。

此步骤将执行以下操作：
- 发现 /root 分区：
  - 装载每个可见分区并查找 etc/fstab。
  - 如果找不到 fstab 文件，则卸载该分区，并继续搜索正确的分区。
  - 如果找到 fstab 文件，则读取 fstab 内容以识别根设备，并将其装载为基本装入点。
- 发现 /boot 和其他系统分区：
  - 使用 fstab 内容确定 /boot 是否是单独的分区。如果是单独的分区，则从 fstab 内容中获取引导分区设备名称，或查找具有引导标志的分区。
  - 脚本将继续在“/mnt/azure_sms_root”上发现并装载 /boot 和其他必要的分区，以生成 chroot jail 所需的根文件系统树。其他必要的分区包括：/boot/grub/menu.lst、/boot/grub/grub.conf、/boot/grub2/grub.cfg、/boot/grub/grub.cfg、/boot/efi（用于 UEFI 引导）、/var、/lib、/etc、/usr 等。
检测操作系统版本。

一旦发现根分区，脚本就会使用以下文件来确定 Linux 操作系统的分发版和版本。
- RHEL：etc/redhat-release
- OL：etc/oracle-release
- SLES：etc/SuSE-release
- Ubuntu：etc/lsb-release
- Debian：etc/debian_version
安装 Hyper-V Linux Integration Services 并重新生成内核映像。

下一步是检查内核映像并重新生成 Linux init 映像，使其在初始 ramdisk 上包含必要的 Hyper-V 驱动程序（hv_vmbus、hv_storvsc、hv_netvsc）。重新生成 init 映像可以确保 VM 在 Azure 中启动。

Azure 在 Hyper-V 虚拟机监控程序上运行。因此，Linux 需要某些内核模块才能在 Azure 中运行。若要准备 Linux 映像，你需要重新生成 initrd，使初始 ramdisk 上至少包含 hv_vmbus 和 hv_storvsc 内核模块。重新生成 initrd 或 initramfs 映像的机制可能会因分发而有所不同。查阅分发的文档或相应过程的支持。以下示例演示了如何使用 mkinitrd 实用工具重新生成 initrd：
1. 查找系统上安装的内核列表（/lib/modules）。
2. 对于每个模块，检查是否已包含 Hyper-V 驱动程序。
3. 如果缺少这些驱动程序中的任何一个，请添加所需的驱动程序，并为相应的内核版本重新生成映像。
  
  注释
  
  此步骤可能不适用于 Ubuntu 和 Debian VM，因为默认情况下内置 Hyper-V 驱动程序。了解有关更改的详细信息。
  
  用于重新生成 initrd 的演示示例：
  - 备份现有 initrd 映像。
```
 cd /boot
 sudo cp initrd-`uname -r`.img  initrd-`uname -r`.img.bak
```
  - 使用 hv_vmbus 和 hv_storvsc 内核模块重新生成 initrd：
```
   sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-`uname -r`.img `uname -r`
```
默认情况下，大多数最新版本的 Linux 分发版已包含此服务。如果不包含，请使用上述步骤为所有版本（以上所示版本除外）手动安装此映像。
启用 Azure 串行控制台日志记录。

之后，脚本将进行更改，以启用 Azure 串行控制台日志记录。启用控制台日志记录有助于排查 Azure VM 上的问题。详细了解适用于 Linux 的 Azure 串行控制台 - 虚拟机 | Microsoft Docs。

修改 GRUB 或 GRUB2 中的内核引导行并包含以下参数，以便将所有控制台消息发送到第一个串行端口。这些消息可以协助 Azure 支持人员调试任何问题。
```
 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300
```
我们还建议删除以下参数（如果存在）。
```
rhgb quiet crashkernel=auto
```
有关特定更改，请参阅本文。
用于连接的网络更改。

根据 OS 版本，脚本将执行所需的网络更改，以连接到迁移后的 VM。更改包括：
1. 移动（或删除）udev 规则，以避免产生以太网接口的静态规则。在 Azure 中克隆虚拟机时，这些规则会引发问题。
  
  RedHat 服务器的演示示例：
```
   sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules
   sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
```
2. 必要时删除网络管理器。网络管理器可能会干扰一些 OS 版本的 Azure Linux 代理。建议对运行 RedHat 和 Ubuntu 分发版的服务器进行这些更改。
3. 运行以下命令卸载此包：
  
  RedHat 服务器的演示示例：
```
   sudo rpm -e --nodeps NetworkManager
```
4. 备份现有 NIC 设置，并使用 DHCP 设置创建 eth0 NIC 配置文件。为此，脚本将创建或编辑 /etc/sysconfig/network-scripts/ifcfg-eth0 文件，并添加以下文本：
  
  RedHat 服务器的演示示例：
```
   DEVICE=eth0
   ONBOOT=yes
   BOOTPROTO=dhcp
   TYPE=Ethernet
   USERCTL=no
   PEERDNS=yes
   IPV6INIT=no
   PERSISTENT_DHCLIENT=yes
   NM_CONTROLLED=yes
```
5. 按下面所示重置 etc/sysconfig/network 文件：
  
  RedHat 服务器的演示示例：
```
   NETWORKING=yes
   HOSTNAME=localhost.localdomain
```
Fstab 验证。

Azure Site Recovery 将验证 fstab 文件的条目，并根据需要将 fstab 条目替换为永久性卷标识符 UUID。此操作可确保无论附加到哪个系统，驱动器/分区名称都保持不变。
- 如果设备名称是标准设备名称（比如 /dev/sdb1），则：
  - 如果它是根分区或启动分区，则将其替换为 UUID。
  - 如果该分区作为标准分区与根分区或启动分区共存于同一磁盘上，则将其替换为 UUID。
- 如果设备名称为 UUID/LABEL/LV，则不会进行任何更改。
- 如果它是网络设备（nfs、cifs、smbfs 等），脚本将对相应条目进行注释。若要访问它，你可以对同一条目取消注释并重新启动 Azure VM。
安装 Linux Azure 代理程序。

Azure Site Recovery 将尝试安装 Azure Linux 代理（waagent），这是一个安全、轻型的过程，用于管理 Linux 和 FreeBSD 预配，并与 Azure Fabric 控制器进行 VM 交互。详细了解通过 Linux 代理为 Linux 和 FreeBSD IaaS 部署启用的功能。

查看安装 Linux VM 代理所需的包列表。 Azure Site Recovery 自动为 RHEL 9.x、8.x/7.x/6.x 安装 Linux VM 代理，使用 VMware 故障转移的无代理方法时，Ubuntu 14.04/16.04/18.04/19.04/19.10/20.04、SUSE 15 SP0/15 SP1/12、Debian 9/8/7 和 Oracle 7/6。按照以下说明手动安装其他 OS 版本的 Linux 代理。

可以使用命令验证 Azure Linux 代理的服务状态，确保它正在运行。服务名称可能是 walinuxagent 或 waagent。完成混合更改后，脚本将卸载所有已装载的分区，停用卷组，然后刷新设备。
```
   sudo vgchange -an <vg-name>
   sudo lockdev –flushbufs <disk-device-name>
```
详细了解 Linux 服务器的更改。

清理与验证

Site Recovery 会自动尝试分离受保护磁盘，并移除服务创建的辅助资源，如辅助虚拟机、网络接口、辅助操作系统磁盘以及不再使用的临时网络资源。清理工作是尽最大努力。失败或取消的操作可能会在订阅中留下临时资源或目标磁盘，Site Recovery 作业会记录清理问题。

辅助资源的清理与 Cleanup test failover 相互独立。验证测试故障转移后，必须执行 清理测试故障转移 ，删除客户可见的测试虚拟机和测试环境。

有些补水问题会以警告形式出现，而不是停止故障切换。同样，最终虚拟机可以在作业记录启动或配置后警告时创建。在执行故障切换之前：

请查看 Site Recovery 作业中的所有警告和错误。
核实最终虚拟机的大小、区域、可用性配置及其他配置设置。对于可重试的预配失败，Site Recovery 可以在不使用不受支持或限制过严的放置设置的情况下重试。
在提交前，验证虚拟机电源状态、启动诊断、串口控制台、网络连接、授权以及工作负载特定注册情况。

排查水分问题

辅助 VM 大小选择

Site Recovery 首先评估已配置的最终 VM 大小，供临时帮助器虚拟机使用。辅助工具大小可能与最终恢复的虚拟机大小不同。合适的辅助器尺寸必须：

使用兼容的x64架构，支持第一代，并且在目标区域和区域内对订阅用户开放。
选择备用大小时，应至少具有两个活跃核心和 2 GiB 的内存。
支持在补水期间连接的源盘数量。辅助虚拟机自身的操作系统和资源盘不计入数据磁盘限制。不支持对超过 64 个已附加源磁盘进行水合操作。
当连接的源磁盘需要时，支持高级存储。

Site Recovery 不会选择已退休或不受支持的虚拟机家族。这些家族包括较早的A、D、F、G、L和H系列，机密计算系列，以及部分专用或已退役的高内存和加速器尺寸。随着 Azure VM 家族的退役，这些类别可能会发生变化。 Site Recovery 仅将基本尺寸视为最后的后备方案。

如果配置的最终大小不合适，Site Recovery 会先搜索同一系列内兼容的大小，优先考虑磁盘容量充足，然后考虑核心数量。然后它会搜索更广泛的合格候选人。如果没有可用的兼容辅助程序大小，该作业将返回 SkuNotAvailableForHydrationVM。

有关故障排除步骤，请参阅将 VMware 虚拟机或物理计算机故障转移到 Azure 时排查错误。

Last updated on 2026-09-30