迁移和现代化：常见问题

本文解答有关“迁移和现代化”工具的常见问题。 如果你遇到其他问题，请查看以下资源：

• 获取有关 Azure Migrate 的常规信息。
• 阅读有关 Azure Migrate 设备的常见问题。
• 了解有关发现、评估和依赖项可视化的详细信息。
• 在 Azure Migrate 论坛中提问。

一般问题

使用“迁移和现代化”工具时，有哪些迁移选项？

“迁移和现代化”工具提供无代理和基于代理的迁移方式，可将源服务器和虚拟机（VM）迁移到 Azure。

无论选择哪种迁移选项，使用“迁移和现代化”工具迁移服务器的第一步都是为服务器启动复制功能。 此过程会将 VM/服务器数据初始复制到 Azure。 初始复制完成后，将建立持续复制（增量同步），将增量数据迁移到 Azure。 操作进入增量同步阶段后，可以随时选择迁移到 Azure。

在决定使用哪种迁移选项时，请考虑以下信息。

无代理迁移无需在要迁移的源 VM/服务器上部署任何软件（代理）。 无代理选项通过集成虚拟化平台提供的功能来协调复制。

无代理复制选项适用于 VMware VM 和 Hyper-V VM。

基于代理的迁移需要在要迁移的源 VM 上安装 Azure Migrate 软件（代理）。 基于代理的选项不依赖于虚拟化平台来实现复制功能。 它可用于任何运行 x86/x64 体系结构且操作系统版本受基于代理的复制方法支持的服务器。

基于代理的迁移选项可用于：

• VMware VM。
• Hyper-V VM。
• 物理服务器。
• 在 AWS 上运行的 VM。
• 在 GCP 上运行的 VM。
• 在其他虚拟化提供商上运行的 VM。

基于代理的迁移将计算机当作物理服务器进行迁移。

对于 VMware 和 Hyper-V VM，无代理迁移比基于代理的复制选项更便捷、更简单。 不过，在以下用例中，可能需要考虑使用基于代理的方案：

• 受每秒输入/输出操作数 (IOPS) 限制的环境：无代理复制使用快照，会消耗存储 IOPS/带宽。 如果环境中的存储/IOPS 有限制，我们建议使用基于代理的迁移方法。

• 没有 vCenter Server：如果你没有 vCenter Server，可以将 VMware VM 视为物理服务器，并使用基于代理的迁移工作流。

若要了解更多信息，请查看选择 VMware 迁移选项。

使用 Azure Migrate 的迁移支持哪些地理位置？

查看公有云和政府云支持的地理位置。

是否可以使用同一个 Azure Migrate 项目迁移到多个区域？

尽管可以在一个 Azure Migrate 项目中为多个区域创建评估，但一个 Azure Migrate 项目只可用于将服务器迁移到一个 Azure 区域。 可以为其他区域创建更多 Azure Migrate 项目。

• 对于无代理 VMware 迁移，启用首次复制后，就会锁定目标区域。
• 对于基于代理的迁移（VMware、物理服务器以及其他云中的服务器），设置复制设备时，在门户上选择“创建资源”按钮后，就会锁定目标区域。
• 对于无代理的 Hyper-V 迁移，设置 Hyper-V 复制提供程序时，在门户上选择“创建资源”按钮后，就会锁定目标区域。

是否可以使用同一个 Azure Migrate 项目迁移到多个订阅？

可以，可以使用同一个 Azure Migrate 项目，迁移到同一目标区域内同一 Azure 租户下的多个订阅。 在为一台或一组计算机启用复制时，可以选择目标订阅。

在以下情况下会锁定目标区域：

• 无代理 VMware 迁移的首次复制完成后。
• 基于代理的迁移安装复制设备期间。
• 无代理 Hyper-V 迁移安装 Hyper-V 提供程序期间。

Azure Migrate 是否支持 Azure Resource Graph？

目前，Azure Migrate 未与 Azure Resource Graph 集成。 它确实支持执行与 Azure Resource Graph 相关的查询。

数据如何从本地环境传输到 Azure？ 传输前数据是否经过加密？

进行无代理复制时，Azure Migrate 设备会在上传数据前对其进行压缩和加密。 将使用 HTTPS 以及 TLS 1.2 或更高版本通过安全信道传输数据。 此外，Azure 存储会在将数据持久化到云端时，自动对数据进行加密（静态加密）。

我可以将 Azure Migrate 创建的恢复服务保管库用于灾难恢复方案吗？

我们不建议将 Azure Migrate 创建的恢复服务保管库用于灾难恢复方案，因为这可能会导致 Azure Migrate 中的启动复制失败。

测试迁移与 Migrate 操作有何区别？

“测试迁移”选项可在实际迁移之前对迁移进行测试和验证。 测试迁移的工作原理是，允许你在实际迁移之前使用 Azure 中的沙盒环境对 VM 进行测试。 沙盒环境按你指定的测试虚拟网络划定。 只要测试虚拟网络足够独立，测试迁移操作就没有破坏性。 设计入站和出站连接规则以避免不必要的连接时，虚拟网络就足够独立。 例如，限制与本地计算机的连接。

应用程序可以继续在源中运行，同时你可以在独立的沙盒环境中对克隆的副本执行测试。 可根据需要执行多项测试来验证迁移，执行应用测试，并在实际迁移之前解决任何问题。

Azure Migrate 是否提供回滚选项？

可以使用“测试迁移”选项来验证应用程序在 Azure 中的功能和性能。 可以执行任意次数的测试迁移，并在通过测试迁移操作建立信心后执行最终迁移。

测试迁移不影响本地计算机。本地计算机仍保持运行并持续复制，直到你执行实际迁移。 如果在测试迁移的用户验收测试 (UAT) 过程中出现任何错误，你可以选择推迟最终迁移，让源 VM/服务器保持运行并向 Azure 复制数据。 解决错误后，可以再次尝试最终迁移。

是否可以选择用于测试迁移的虚拟网络和子网？

可以选择用于测试迁移的虚拟网络。 Azure Migrate 会根据以下逻辑自动选择子网：

• 如果你在启用复制时指定了目标子网（非默认子网）作为输入，Azure Migrate 会优先选择测试迁移所用虚拟网络中同名的子网。
• 如果找不到同名子网，Azure Migrate 会按字母顺序选择第一个可用的非网关、非应用程序网关、非防火墙且非 Azure Bastion 的子网。

为何我的服务器对应的“测试迁移”按钮已禁用？

在以下情况下，“测试迁移”按钮可能会处于禁用状态：

• 在 VM 的初始复制完成之前，无法开始测试迁移。 在初始复制过程完成之前，“测试迁移”按钮将保持禁用状态。 在 VM 进入增量同步阶段后，即可执行测试迁移。
• 如果测试迁移已完成，但未对该 VM 执行测试迁移清理，则可能会禁用该按钮。 执行测试迁移清理，然后重试操作。

不清理测试迁移会发生什么情况？

测试迁移通过使用复制的数据创建测试 Azure VM 来模拟实际迁移。 服务器将连同所复制数据的时间点副本一起部署到带有 -test 后缀的目标资源组（在启用复制时选择）。 测试迁移旨在验证服务器功能，以最大程度地减少迁移后的问题。

如果在测试后未清理测试迁移，测试 VM 会继续在 Azure 中运行并产生费用。 若要在测试迁移后进行清理，请在“迁移和现代化”工具中转到“复制计算机”视图，然后对计算机使用“清理测试迁移”操作。

如何知道我的 VM 是否成功迁移？

成功迁移 VM/服务器后，可以从“虚拟机”窗格中查看和管理该 VM。 连接到已迁移的 VM 进行验证。

也可以查看操作的作业状态，以检查迁移是否成功完成。 如果看到任何错误，请解决这些错误，然后重试迁移操作。

如果迁移后不停止复制，会发生什么情况？

停止复制时，“迁移和现代化”工具将清理订阅中为复制创建的托管磁盘。

如果没有在迁移后选择“完成迁移”，会发生什么情况？

选择“完成迁移”后，“迁移和现代化”工具将清理订阅中为复制创建的托管磁盘。 如果没有在迁移后选择“完成迁移”，则这些磁盘会继续产生费用。 完成迁移不会影响附加到已迁移计算机的磁盘。

如何将基于 UEFI 的计算机作为 Azure 第 1 代 VM 迁移到 Azure？

“迁移和现代化”工具会将基于 UEFI 的计算机作为 Azure 第二代 VM 迁移到 Azure。 如果你要将其迁移到 Azure 第 1 代 VM，请在开始复制之前将启动类型转换为 BIOS，然后使用“迁移和现代化”工具迁移到 Azure。

Azure Migrate 是否将基于 UEFI 的计算机转换为基于 BIOS 的计算机，并将其作为 Azure 第 1 代 VM 迁移到 Azure？

“迁移和现代化”工具会将所有基于 UEFI 的计算机作为 Azure 第 2 代 VM 迁移到 Azure。 我们不再支持将基于 UEFI 的 VM 转换为基于 BIOS 的 VM。 所有基于 BIOS 的计算机仅作为 Azure 第 1 代 VM 迁移到 Azure。

从基于 UEFI 的计算机到 Azure 的迁移支持哪些操作系统？

基于 UEFI 的计算机支持的操作系统	从 VMware 到 Azure 的无代理迁移	从 Hyper-V 到 Azure 的无代理迁移	从 VMware、物理服务器和其他云到 Azure 的基于代理的迁移
Windows Server 2025、2022、2019、2016、2012 R2、2012	Y	Y	Y
Windows 11 专业版、Windows 11 企业版	Y	Y	Y
Windows 10 专业版、Windows 10 企业版	Y	Y	Y
SUSE Linux Enterprise Server 15 SP1、SP2、SP3、SP4、SP5、SP6	Y	Y	Y
SUSE Linux Enterprise Server 12 SP4	Y	Y	Y
Ubuntu Server 22.04 LTS、20.04 LTS、18.04 LTS、16.04 LTS	Y	Y	Y
RHEL 9.x、8.1、8.0、7.8、7.7、7.6、7.5、7.4、7.0、6.x	Y	Y	Y
CentOS 流	Y	Y	Y
Oracle Linux 9、8、7.7-CI、7.7、6	Y	Y	Y

是否可以使用 Azure Migrate 迁移 Active Directory 域控制器？

“迁移和现代化”工具不区分应用程序，可用于大多数应用程序。 使用“迁移和现代化”工具迁移服务器时，安装在该服务器上的所有应用程序会随之一起迁移。 不过，对于某些应用程序，其他迁移方法可能更合适。

对于 Active Directory，环境类型可能是一个影响因素。 在本地站点连接到 Azure 环境的混合环境中，可以通过添加更多域控制器并设置 Active Directory 复制，将目录扩展到 Azure。 在以下情况下，可以使用“迁移和现代化”工具：

• 迁移到 Azure 中需要自有域控制器的隔离环境。
• 在沙盒环境中测试应用程序。

在迁移时是否可以升级 OS？

现在，“迁移和现代化”工具支持在迁移过程中进行 Windows OS 升级。 目前，此选项不适用于 Linux。 获取有关 Windows OS 升级的更多详细信息。

是否需要 VMware vCenter 才能迁移 VMware VM？

若要使用基于 VMware 代理或无代理迁移来迁移 VMware VM，vCenter Server 必须管理托管 VM 的 ESXi 主机。 如果没有 vCenter Server，则可将 VMware VM 作为物理服务器进行迁移。 了解详细信息。

在迁移时是否可以将多个源 VM 合并成一个 VM？

“迁移和现代化”工具目前仅支持对等性的迁移。 不支持在迁移过程中合并服务器。

迁移后，Windows Server 2008 和 2008 R2 是否在 Azure 中受支持？

可将本地 Windows Server 2008 和 2008 R2 服务器迁移到 Azure VM，并获取在支持终止日期之后为期三年的延期安全更新，这样，除了支付运行 VM 的费用外，无需额外付费。 可以使用“迁移和现代化”工具迁移 Windows Server 2008 和 2008 R2 工作负荷。

如何将 VMware/Hyper-V 上运行的 Windows Server 2003 迁移到 Azure？

Windows Server 2003 外延支持已于 2015 年 7 月 14 日终止。 Azure 支持团队将继续帮助排查有关在 Azure 上运行 Windows Server 2003 的问题。 但是，这种支持仅限于不需要 OS 级故障排除或补丁的问题。

建议将应用程序迁移到运行较新版 Windows Server 的 Azure 实例，以确保有效使用 Azure 云的灵活性和可靠性。

如果你仍选择将 Windows Server 2003 迁移到 Azure，则可使用“迁移和现代化”工具（如果你部署的 Windows Server 是在 VMware 或 Hyper-V 上运行的 VM）。 有关详细信息，请参阅为迁移准备 Windows Server 2003 计算机。

无代理 VMware 迁移

无代理迁移的工作原理是什么？

“迁移和现代化”工具提供无代理复制选项，用于迁移运行 Windows 或 Linux 的 VMware 和 Hyper-V VM。 该工具为 Windows 和 Linux 服务器提供了另一个基于代理的复制选项。 此选项可用于迁移物理服务器以及 VMware、Hyper-V、AWS 和 GCP 等提供程序上的 x86/x64 VM。

基于代理的复制要求在要迁移的 VM/服务器上安装代理软件。 无代理选项则无需在 VM 上安装软件，因此更加便捷简单。

无代理复制选项利用虚拟化提供程序（VMware 或 Hyper-V）提供的机制。 对于 VMware VM，无代理复制机制使用 VMware 快照和 VMware 已更改块跟踪技术从 VM 磁盘复制数据。 许多备份产品也采用类似机制。 对于 Hyper-V VM，无代理复制机制使用 VM 快照和 Hyper-V 副本的更改跟踪功能从 VM 磁盘复制数据。

为 VM 配置复制后，首先会经历初始复制阶段。 在初始复制期间，将创建一个 VM 快照，并将快照磁盘中的完整数据副本复制到订阅中的托管磁盘。 VM 的初始复制完成后，复制过程将转换为增量复制（差异复制）阶段。

增量复制阶段会处理自上次完整复制周期以来发生的所有数据更改。 这些更改会定期复制并应用到副本托管磁盘。 此过程可使复制与 VM 上的更改保持同步。

VMware 变更块跟踪技术可记录 VMware VM 各复制周期之间的更改。 复制周期开始时，将创建一个 VM 快照，并使用已更改块跟踪来编译当前快照与上次成功复制的快照之间的变化。 若要使 VM 复制保持同步，只需复制自上次完整复制周期以来发生更改的数据。

在每个复制周期结束时，将释放快照，并对 VM 执行快照合并。 同样，对于 Hyper-V VM，Hyper-V 副本更改跟踪引擎会跟踪连续复制周期之间的变化。

当对正在复制的 VM 执行 Migrate 操作时，可以关闭本地 VM 并执行一次最终增量复制，以确保不会丢失任何数据。 复制完成后，将使用与该 VM 对应的副本托管磁盘在 Azure 中创建 VM。

若要开始，请参阅 VMware 无代理迁移和 Hyper-V 无代理迁移教程。

如何衡量迁移的带宽要求？

有一系列因素会影响将数据复制到 Azure 所需的带宽量。 带宽需求取决于本地 Azure Migrate 设备读取数据并将其复制到 Azure 的速度。 复制分为两个阶段：初始复制和差异复制。

当 VM 复制开始时，将执行初始复制周期，在此周期将复制磁盘的完整副本。 初始复制完成后，将定期计划增量复制周期（差异周期），以传输自上次复制周期后发生的所有更改。

可以根据以下因素计算带宽需求：

• 需要在波次中移动的数据量。
• 要为初始复制过程预留的时间。

理想情况下，应至少在实际迁移窗口开始前 3-4 天完成初始复制。 这样的时间安排能让你有足够时间在实际迁移窗口前进行测试迁移，并将迁移窗口期间的停机时间保持在最低水平。

可以使用以下公式来估计无代理 VMware VM 迁移所需的带宽或时间：

• 完成初始复制所需的时间 = {磁盘大小（或已用大小，如果适用）* 0.7（假设平均压缩率为 30% – 保守估计）}/可用于复制的带宽。

使用 Azure Migrate 设备进行无代理 VMware 复制时，如何限制复制带宽？

可以使用 NetQosPolicy 来限制带宽。 此限制方法仅适用于从 Azure Migrate 设备发出的出站连接。

例如，在 NetQosPolicy 中使用的 AppNamePrefix 值为 GatewayWindowsService.exe。 可按如下所示在 Azure Migrate 设备上创建一个策略，以限制来自设备的复制流量：

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

若要根据计划增加和减少复制带宽，可以使用 Windows 计划任务根据需要缩放带宽。 一个任务用于降低带宽，另一个任务用于增加带宽。

#Replace with an account that's part of the local Administrators group
$User = "localVmName\userName"

#Set the task names
$ThrottleBandwidthTask = "ThrottleBandwidth"
$IncreaseBandwidthTask = "IncreaseBandwidth"

#Create a directory to host PowerShell scaling scripts
if (!(Test-Path "C:\ReplicationBandwidthScripts"))
{
 New-Item -Path "C:\" -Name "ReplicationBandwidthScripts" -Type Directory
}

#Set your minimum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 10 MBps
New-Item C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 10MB'
$ThrottleBandwidthScript = "C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1"

#Set your maximum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 1000 MBps
New-Item C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 1000MB'
$IncreaseBandwidthScript = "C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1"

#Timezone set on the Azure Migrate Appliance (VM) is used; change the frequency to meet your needs
#In this example, the bandwidth is being throttled every weekday at 8:00 AM local time
#The bandwidth is being increased every weekday at 6:00 PM local time
$ThrottleBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 8:00am
$IncreaseBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 6:00pm

#Setting the task action to execute the scripts
$ThrottleBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $ThrottleBandwidthScript"
$IncreaseBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $IncreaseBandwidthScript"

#Creating the scheduled tasks
Register-ScheduledTask -TaskName $ThrottleBandwidthTask -Trigger $ThrottleBandwidthTrigger -User $User -Action $ThrottleBandwidthAction -RunLevel Highest -Force
Register-ScheduledTask -TaskName $IncreaseBandwidthTask -Trigger $IncreaseBandwidthTrigger -User $User -Action $IncreaseBandwidthAction -RunLevel Highest -Force

流失率对无代理复制造成怎样的影响？

由于无代理复制对半缩减数据，因此流失模式比流失率更重要 。 反复写入文件时，流失率不会造成很大的影响。 但是，每隔一个扇区写入的模式会导致下一个周期的流失变高。 由于要尽量减少传输的数据量，因此在计划下一个周期之前，应尽可能让数据多整合一些。

复制周期的计划频率是怎样的？

计划下一个复制周期的公式为（上一周期时间/2）或一小时，以较大的结果为准。

例如，如果某个 VM 完成一个差异周期需要四个小时，则会将下一个周期计划为两小时后，而不是下一个小时。 完成初始复制后立即计划第一个差异周期时，该过程会立即发生变化。

我部署了两个（或更多个）设备以在 vCenter Server 中发现 VM。 但是，当我尝试迁移 VM 时，只看到了与其中一台设备对应的 VM。

如果设置了多台设备，所提供的 vCenter 帐户中的 VM 间不应有重叠。 具有此类重叠的发现是不受支持的方案。

无代理复制会对 VMware 服务器造成怎样的影响？

无代理复制会对 VMware vCenter Server 和 VMware ESXi 主机的性能造成一定的影响。 由于无代理复制使用快照，会消耗 IOPS 或存储，因此需要占用一些 IOPS 存储带宽。 如果你环境中的存储或 IOPS 有限制，则我们不建议使用无代理复制。

可以复制关闭电源的 VM 吗？

支持在 VMware VM 关闭电源时进行复制，但仅适用于无代理方法。

强烈建议执行测试迁移，以确保实际迁移过程一切顺利。 当初始复制过程较长，或者对于高改动率的 VM（如数据库服务器或其他磁盘密集型工作负载），这种方法很有用。

是否可以使用 Azure Migrate 将 Web 应用迁移到 Azure 应用服务？

可以对 VMware 环境中的 Windows OS 上托管的 IIS Web 服务器上运行的 ASP.NET Web 应用执行大规模无代理迁移。 了解详细信息。

基于代理的迁移

如何将 AWS EC2 实例迁移到 Azure？

查看发现、评估 Amazon Web Services (AWS) VM 并将其迁移到 Azure。

基于代理的迁移的工作原理是什么？

“迁移和现代化”工具提供基于代理的迁移选项，用于迁移在物理服务器上运行的 Windows 和 Linux 服务器，或者在 VMware、Hyper-V、AWS 和 GCP 等提供程序上运行的 x86/x64 VM。

基于代理的迁移方法使用代理软件将服务器数据复制到 Azure。 需要在要迁移的服务器上安装软件。 复制过程使用卸载体系结构，在其中，代理会将复制数据中继到称作复制设备或配置服务器的专用复制服务器（或中继到横向扩展进程服务器）。 有关详细信息，请参阅基于 VMware 代理的迁移体系结构。

用于基于代理的迁移的复制设备应安装在何处？

应将复制设备安装在专用计算机上。 不应将复制设备安装在要复制的源计算机上，也不应安装在用于发现和评估的 Azure Migrate 设备上。 有关详细信息，请参阅将计算机作为物理服务器迁移到 Azure。

是否可以迁移运行 Amazon Linux 操作系统的 AWS VM？

运行 Amazon Linux 的 VM 无法直接迁移，因为 Amazon Linux 操作系统仅在 AWS 上受支持。

若要迁移在 Amazon Linux 上运行的工作负荷，可以在 Azure 中启动 CentOS/RHEL VM。 然后，你可以使用相关的工作负载迁移方法迁移在 AWS Linux 计算机上运行的工作负载。 例如，根据工作负载的不同，可能会有特定于工作负载的工具来辅助迁移，如数据库工具或 Web 服务器部署工具。

如何衡量迁移的带宽要求？

有一系列因素会影响将数据复制到 Azure 所需的带宽量。 带宽需求取决于本地 Azure Migrate 设备读取数据并将其复制到 Azure 的速度。 复制分为两个阶段：初始复制和差异复制。

当 VM 复制开始时，将执行初始复制周期，在此周期将复制磁盘的完整副本。 初始复制完成后，将定期计划增量复制周期（差异周期），以传输自上次复制周期后发生的所有更改。

对于基于代理的复制方法，Azure Site Recovery 部署规划器 可以帮助分析环境中的数据流失率，并帮助预测所需的带宽要求。 若要了解详细信息，请参阅规划 VMware 部署。

无代理 Hyper-V 迁移

无代理迁移的工作原理是什么？

“迁移和现代化”工具提供无代理复制选项，用于迁移运行 Windows 或 Linux 的 VMware 和 Hyper-V VM。 该工具为 Windows 和 Linux 服务器提供了另一个基于代理的复制选项。 此选项可用于迁移物理服务器以及 VMware、Hyper-V、AWS 和 GCP 等提供程序上的 x86/x64 VM。

基于代理的复制选项要求在要迁移的 VM/服务器上安装代理软件。 无代理选项则无需在 VM 上安装软件，因此更加便捷简单。

无代理复制选项是使用虚拟化平台（VMware 或 Hyper-V）提供的机制运行的。 对于 Hyper-V VM，无代理复制机制使用 VM 快照和 Hyper-V 副本的更改跟踪功能从 VM 磁盘复制数据。

为 VM 配置复制后，首先会经历初始复制阶段。 在初始复制期间，将创建一个 VM 快照，并将快照磁盘中的完整数据副本复制到订阅中的托管磁盘。 VM 的初始复制完成后，复制过程将转换为增量复制（差异复制）阶段。

增量复制阶段会处理自上次完整复制周期以来发生的所有数据更改。 这些更改会定期复制并应用到副本托管磁盘。 此过程可使复制与 VM 上的更改保持同步。

VMware 采用已更改块跟踪技术来跟踪 VMware VM 复制周期之间发生的更改。 复制周期开始时，将创建一个 VM 快照，并使用已更改块跟踪来获取当前快照与上次成功复制的快照之间的变化。 若要使 VM 复制保持同步，只需复制自上次完整复制周期以来发生更改的数据。

在每个复制周期结束时，将释放快照，并对 VM 执行快照合并。 同样，对于 Hyper-V VM，会使用 Hyper-V 副本更改跟踪引擎来跟踪连续复制周期之间的变化。

当对正在复制的 VM 执行 Migrate 操作时，可以关闭本地 VM 并执行一次最终增量复制，以确保不会丢失任何数据。 将使用与该 VM 对应的副本托管磁盘在 Azure 中创建 VM。

若要开始，请参阅 Hyper-V 无代理迁移教程。

如何衡量迁移的带宽要求？

有一系列因素会影响将数据复制到 Azure 所需的带宽量。 带宽需求取决于本地 Azure Migrate 设备读取数据并将其复制到 Azure 的速度。 复制分为两个阶段：初始复制和差异复制。

当 VM 复制开始时，将执行初始复制周期，在此周期将复制磁盘的完整副本。 初始复制完成后，将定期计划增量复制周期（差异周期），以传输自上次复制周期后发生的所有更改。

可以根据以下因素计算带宽需求：

• 需要在波次中移动的数据量。
• 要为初始复制过程预留的时间。

理想情况下，应至少在实际迁移窗口开始前 3-4 天完成初始复制。 这样的时间安排能让你有足够时间在实际迁移窗口前进行测试迁移，并将迁移窗口期间的停机时间保持在最低水平。

相关内容

• 了解有关迁移 VMware VM、Hyper-V VM 和物理服务器的更多信息。