通过 Hydration 为 Azure 配置本地磁盘

发现并准备 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 不需要它们。

安装 Azure 来宾代理。

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 代理。

执行上述更改后，系统分区将被卸载。 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 操作系统的分发版和版本。

• OL：etc/oracle-release
• SLES：etc/SuSE-release
• Ubuntu：etc/lsb-release

安装 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 服务器的更改。