如何自动化 VMware 到 AVD 迁移：完整指南

 将 VMware 或 Horizon 工作负载迁移到 Azure Virtual Desktop（AVD）不仅仅是移动虚拟机。VM 依赖关系、应用程序兼容性、用户配置文件、安全策略和切换规划都会影响迁移批次能否成功，因此最好在迁移之前梳理这些依赖关系，这样自动化才能发挥最佳效果。

本指南涵盖：

• 自动化 VMware 到 AVD 迁移的三种方法
• FSLogix 配置文件迁移
• 切换前的预切换测试
• 切换过程中出现的常见问题

自动化 VMware 到 AVD 迁移的前提条件

在自动化迁移之前，请准备源 VMware 环境、Azure 资源、应用程序依赖关系和恢复计划。跳过其中任何一步都会增加风险，即自动化了一个只在切换时才暴露问题的迁移。

VMware 管理员访问权限和权限

迁移工作流需要足够的访问权限来清点 VMware 资源、配置复制并收集要迁移的 VM 信息。确切的权限要求取决于迁移方法和 VMware 环境，因此在部署之前，请根据当前的 Azure Migrate 或 Azure Site Recovery 文档验证所需角色。

迁移团队至少需要能够查看：

• VM 清单和磁盘配置
• 每个 VM 的网络设置
• 操作系统版本
• 已安装的应用程序及其依赖关系

对于大型 VMware 环境，PowerCLI 可以帮助从 vCenter 批量导出 VM 清单，而不是手动收集。

Azure 资源规划

AVD 需要的不仅仅是迁移 VM 的目的地。在开始复制或部署之前，请规划：

• Azure 订阅和资源组
• 虚拟网络设计
• 主机池和工作区
• 会话主机配置
• 存储策略

磁盘和存储规划尤为重要，因为 AVD 会话主机是作为新的 Azure VM 部署的，而不是导入原始 VMware VM 的副本。在最终确定目标架构之前，请考虑 VM 规格、OS 磁盘要求、用户配置文件存储、网络连接以及预期的并发会话数。

自动化切换前的依赖关系映射

自动化可以重现已定义的迁移工作流，但无法弥补缺失的依赖关系。请梳理以下依赖关系：

• 域控制器和 DNS
• 文件共享和数据库
• 许可证服务器
• 身份验证服务
• 业务线应用程序

这是 VMware 到 AVD 项目中的常见故障点。会话主机可以成功迁移，而应用程序仍指向本地服务器或 Azure 无法访问的网络路径，从而使技术上成功的 VM 迁移变成失败的用户迁移。

源 VM 的完整备份或快照

在复制和切换之前，为源工作负载创建可恢复的副本。VMware 快照可以作为短期恢复点，但不应将其视为生产工作负载的完整备份策略。了解备份与快照之间的区别有助于为这一步设定正确的期望。

迁移计划还应定义每个迁移批次之后原始 VMware 环境保持可用的时长。在验证完成之前保持源工作负载完好，可以在应用程序、配置文件或用户访问未按预期运行时，为团队提供实用的回滚路径。

自动化 VMware 到 AVD 迁移的 3 种方法

并非每个 VMware 到 AVD 项目都有单一的自动化路径。Azure Migrate 是 Microsoft 推荐的 VM 迁移工具，PowerShell 可以在其之上自动化重复性的预配和清点任务，而 Azure Site Recovery 适合已将其用于灾难恢复并希望将同样的复制扩展到迁移的团队。

方法 1：使用 Azure Migrate 自动化 VM 复制

Azure Migrate 可以发现 VMware VM、评估其 Azure 就绪情况，并使用其无代理迁移方法复制受支持的工作负载。对于 AVD 项目，复制只是过程中的一部分，因为生成的 Azure VM 仍需符合规划的 AVD 会话主机架构。

典型工作流包括：

1. 将 Azure Migrate 设备部署为 VMware VM，并将其注册到你的 Azure Migrate 项目。该设备连接到 vCenter Server，并在不向各个 VM 安装代理的情况下执行发现。
2. 运行发现和评估。在选择要迁移的工作负载之前，查看每个已发现 VM 的操作系统兼容性、VM 规格、磁盘配置、网络要求和依赖关系信息。
3. 初始化项目的复制基础结构。这是每个 Azure 区域的一次性步骤，用于设置复制所依赖的服务总线、存储账户和密钥保管库。
4. 为选定的 VM 启动复制，并为每个 VM 指定目标资源组、虚拟网络、VM 大小和磁盘配置。
5. 监控复制运行状况，直到 VM 达到增量复制状态，即持续更改正在同步，VM 已准备好迁移。
6. 在隔离的 Azure 虚拟网络中运行测试迁移。在不影响源 VM 的情况下验证启动行为、网络、身份验证和应用程序依赖关系，然后在继续之前清理测试迁移。
7. 完成切换。运行完整迁移，可选择在此过程中关闭源 VM，并确认迁移后的 VM 在 Azure 中正常启动和运行。
8. 完成迁移后步骤。停止并移除已迁移 VM 的复制，更新内部文档，并在验证完成后从本地清单和备份中移除源 VM。

Azure Migrate 自动化了复制和切换机制，但它不会验证应用程序依赖关系，也不会自行将 VMware Horizon 桌面转换为完整的 AVD 部署。在用户迁移到新环境之前，会话主机配置、用户配置文件设置、应用程序交付、AVD 注册和身份仍需单独审查。

方法 2：使用 PowerShell 自动化 VMware 到 AVD 迁移

PowerShell 适合涉及大量 VM 或需要与现有预配管道集成的迁移。管理员无需通过门户手动收集清单并配置每个工作负载，而是可以将 VMware PowerCLI 与 Azure Migrate PowerShell 模块结合使用，以标准化可重复的任务。

步骤 1：使用 PowerCLI 导出 VMware VM 清单

Connect-VIServer -Server vcenter.contoso.com

Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB, `
    @{N='OS'; E={$_.Guest.OSFullName}} |
    Export-Csv -Path .\vm-inventory.csv -NoTypeInformation

这会生成一个包含 VM 名称、电源状态、CPU 和内存分配以及客户机操作系统的 CSV，迁移团队可以在决定迁移哪些 VM 之前进行审查。

步骤 2：连接到 Azure 并检索 Azure Migrate 项目

Connect-AzAccount
Set-AzContext -SubscriptionId ""

$ResourceGroup   = Get-AzResourceGroup -Name "MigrateRG"
$MigrateProject  = Get-AzMigrateProject -Name "MyMigrateProject" `
                    -ResourceGroupName $ResourceGroup.ResourceGroupName

步骤 3：检索已发现的服务器并启动复制

$DiscoveredServers = Get-AzMigrateDiscoveredServer `
    -ProjectName $MigrateProject.Name `
    -ResourceGroupName $ResourceGroup.ResourceGroupName

$TargetResourceGroup   = Get-AzResourceGroup -Name "TargetRG"
$TargetVirtualNetwork  = Get-AzVirtualNetwork -Name "TargetVNet"

foreach ($server in $DiscoveredServers) {
    New-AzMigrateServerReplication -InputObject $server `
        -TargetResourceGroupId $TargetResourceGroup.ResourceId `
        -TargetNetworkId $TargetVirtualNetwork.Id `
        -TargetSubnetName $TargetVirtualNetwork.Subnets[0].Name `
        -OSDiskID $server.Disk[0].Uuid `
        -DiskType Standard_LRS `
        -LicenseType NoLicenseType `
        -TargetVMName $server.DisplayName `
        -TargetVMSize Standard_D2s_v3
}

步骤 4：跟踪作业，然后测试并完成迁移

$ReplicatingServer = Get-AzMigrateServerReplication `
    -ProjectName $MigrateProject.Name `
    -ResourceGroupName $ResourceGroup.ResourceGroupName `
    -MachineName "MyTestVM"

Start-AzMigrateTestMigration -InputObject $ReplicatingServer -TestNetworkID $TargetVirtualNetwork.Id
Start-AzMigrateServerMigration -InputObject $ReplicatingServer -TurnOffSourceServer

这些 cmdlet 中的每一个都会返回一个作业对象，可以使用 Get-AzMigrateJob 轮询该对象，直到其状态变为 Succeeded。对于需要更精细控制的自定义管道，Azure Site Recovery REST API 公开了相同的复制和迁移操作，以便直接集成。

这种方法的主要优势是一致性，而不是完全无人工干预的迁移。PowerShell 可以标准化重复性操作，但工程师应保留依赖关系检查、应用程序验证、测试迁移和生产切换的人工审批点。

方法 3：通过 Azure Site Recovery 自动化 VMware 到 AVD 迁移

Microsoft 目前将 Azure Site Recovery（ASR）定位为灾难恢复服务，并建议将 Azure Migrate 用于 VM 迁移项目。ASR 仍支持将 VMware VM 复制到 Azure 并故障转移到这些 VM，因此对于已经将其用于 VMware 灾难恢复并希望将同样的复制扩展到 AVD 迁移批次的企业来说，它仍然是一个实用选项，而不是仅迁移项目的首选。

如果 ASR 已经是环境的一部分，典型工作流包括：

1. 使用现代化保护体验在目标 Azure 区域中创建恢复服务保管库。经典 VMware 保护体验已于 2026 年 3 月停用，因此新配置应使用当前的复制设备模型。
2. 将 Azure Site Recovery 复制设备部署为 VMware VM 并将其注册到保管库，然后添加 vCenter Server 详细信息，以便该设备可以发现 VM。
3. 为选定的 VMware VM 启用复制，指定目标资源组、网络和磁盘配置。
4. 监控复制运行状况，直到每个 VM 达到稳定的持续复制状态。
5. 运行测试故障转移到隔离网络，以验证工作负载而不影响生产 VMware VM。
6. 在迁移窗口期间运行计划故障转移，在此之前确认最终数据同步已完成。
7. 在 Azure 中验证迁移后的工作负载，然后移除源 VM 的复制，并在验证完成后将其退役。ASR 迁移不支持故障回复到源 VMware VM。

对于 Horizon 环境，复制的 VMware VM 不会自动成为 AVD 会话主机。迁移架构仍需确定工作负载是成为单个 Azure VM、从黄金映像重建，还是在此路径最终确定之前重新部署为 AVD 会话主机。

自动化 FSLogix 配置文件迁移到 AVD

VM 迁移不会自动保留 VMware Horizon 的用户体验。Horizon 环境通常依赖 VMware UEM、Persona 或漫游配置文件，因此将用户迁移到 AVD 时，配置文件数据需要自己的迁移计划。

为什么 VMware UEM 和 Persona 配置文件需要转换为 FSLogix

AVD 通常使用 FSLogix 配置文件容器，它将用户配置文件与会话主机分开存储，以便用户在任何会话主机上都能获得一致的体验。

简单地将现有配置文件目录复制到 FSLogix 容器中，可能会带入损坏的权限或对旧环境的引用。Microsoft 的 FSLogix Profile Migration Module（目前是私人预览工具）可以帮助将漫游配置文件和 UPD 磁盘转换为 FSLogix 容器，但由于预览工具没有 SLA，应先在非生产环境中测试。

使用 FSLogix Cloud Cache 进行分阶段切换

FSLogix Cloud Cache 会同时将配置文件数据写入多个存储位置，这可以在用户在 VMware 和 AVD 之间移动时缓解过渡。它不能替代对实际迁移的规划；存储权限、身份和网络访问仍需在切换前验证。

常见的配置文件迁移陷阱

• 跨域 SID 不匹配：绑定到旧安全标识符的配置文件权限在域更改后可能会失效。
• Windows 版本兼容性：FSLogix 容器本身可以顺利迁移到 Windows 11 主机，但其中的应用设置和缓存凭据可能不行。
• 并发会话：配置文件容器一次只能挂载到一个活动会话，因此请规划清晰的切换窗口。
• 配置文件大小：大型配置文件会拖慢迁移和验证速度。
• 应用程序特定设置：某些应用将数据存储在配置文件本身之外，需要单独测试。

先迁移一小部分配置文件。在向其他人推广之前，检查 AVD 上的登录、应用设置和权限。

在切换前测试 VMware 到 AVD 迁移

成功的复制或配置文件迁移并不能证明用户可以在 AVD 中正常工作。试点应在第一批迁移批次切换之前，复现生产环境的关键身份、应用程序、网络、配置文件和安全依赖关系，这与灾难恢复测试最佳实践背后的逻辑相同：在你真正需要之前验证故障转移路径。

构建试点主机池

从一个小型 AVD 主机池开始，覆盖不同的应用程序需求、配置文件大小、用户角色和访问模式，而不是只覆盖最简单的桌面。

试点应走完完整的用户路径：身份验证、AVD 客户端访问、会话主机注册、配置文件加载、应用程序启动、文件访问、打印和其他外围设备。仅检查 Azure VM 是否启动可能会遗漏只有在真实会话开始后才会出现的问题。

创建验证环境

保持验证环境足够隔离，使测试不会影响活动用户或业务数据，同时仍能复现生产依赖关系，例如 Active Directory、DNS、网络连接、应用程序服务器、文件共享和身份策略。

对于每个迁移的工作负载，将 AVD 会话与其 VMware 等效项进行比较。重点关注应用程序许可、驱动器映射、组策略行为、剪贴板限制、USB 或外围设备访问以及依赖网络的应用程序。

在此阶段发现的问题远比用户已经迁移后才发现的问题更容易修复。

衡量迁移成功

在迁移批次开始之前定义可衡量的验收标准，以免仅凭 VM 复制成功就被误认为是迁移成功。

• 迁移完成：复制和切换完成，没有数据丢失或源 VM 的意外更改。
• 用户访问：用户可以身份验证并启动 AVD 会话。
• 配置文件完整性：FSLogix 配置文件加载时具有预期的设置和数据。
• 应用程序兼容性：业务关键应用可以启动并表现良好。
• 网络访问：文件共享、数据库和其他依赖关系保持可访问。
• 性能：登录时间、应用响应速度和资源使用保持在基线范围内。
• 回滚就绪：在满足验收标准之前，VMware 工作负载保持可用。

记录每个批次的结果，而不是依赖非正式反馈。一致的检查清单可以更容易地决定工作负载是已准备好投入生产、需要修复，还是应在 VMware 上再保留一段时间。

在自动化 AVD 迁移之前保护 VMware 工作负载

自动化加快了 VMware 到 AVD 迁移的机制，但它不能在复制、测试和切换进行期间保护源环境。在迁移批次之前拍摄的快照提供了短期恢复点，但如果切换失败或几天后才做出回滚决定，它不能替代真正的备份。

i2Backup 为源 VMware 环境提供可恢复的副本，该副本独立于迁移过程本身，因此糟糕的切换不会同时变成数据丢失事件。

• 无代理 VM 备份：通过原生平台 API 保护 VMware VM，无需安装代理，并且在迁移窗口期间不会影响生产。
• 块级更改跟踪：以分钟级 RPO 捕获近实时备份，因此恢复点在多批次迁移过程中保持最新。
• 即时 VM 恢复：远程挂载 VM 备份，以便在迁移的 VM 需要在 VMware 侧恢复时快速使工作负载重新上线。
• 时间点恢复：恢复到配置文件转换失败或应用程序中断之前的特定时刻，而不仅仅是最新状态。
• 恢复到任意位置：恢复到原始 VM、其他主机或新位置，在需要重建原始会话主机配置时非常有用。

对于同时构建试点主机池或验证环境的团队，i2CDM 可以在几分钟内启动生产数据的即用型虚拟副本，这对于在不接触实时工作负载的情况下测试迁移批次非常有用。

常见问题

问：我可以将现有的 VMware VM 直接移入 AVD 主机池吗？

不可以，不能直接移入。它仍然需要 AVD 代理组件、身份集成和主机池注册。从标准化的 Azure 映像重建会话主机通常比逐个转换迁移的 VM 更实用。

问：VMware Horizon 用户配置文件会怎样？

它们不会自动成为 FSLogix 容器。根据来源不同，团队可以选择将数据转换为 FSLogix、暂时保留旧配置文件系统、仅迁移部分用户数据，或让用户使用全新配置文件。在推广之前与真实用户一起测试，因为配置文件看起来已迁移，但仍可能在登录时失败。

问：我可以保留相同的应用程序吗？

通常可以，但要独立于 VM 迁移单独测试每个应用。绑定到特定驱动程序、许可证服务器或 Horizon 特定组件的应用可能需要 RemoteApp 或动态交付，而不是直接映像安装。

问：如何保留 VMware 安全策略？

在迁移之前，将每个 Horizon 策略（剪贴板、驱动器重定向、USB 访问、会话超时、条件访问及类似控制）映射到其 GPO、Intune 或 AVD 等效项。仅在纸面上名称匹配是不够的，因此请在真实 AVD 会话中测试实际行为。

问：我可以回滚到 VMware 吗？

可以，如果你保持 VMware 环境运行，直到每个迁移批次通过验证。提前定义回滚触发器（身份验证失败、应用损坏、配置文件损坏），并测试回滚过程本身，而不仅仅是纸上规划。

结论

自动化 VMware 到 AVD 迁移消除了 VM 复制和预配中的大量重复工作，但移动 VM 的机制只是项目的一部分。FSLogix 配置文件转换、应用程序测试和策略映射通常决定用户是否能顺利过渡，而不是复制工具本身。

切换前的试点测试、明确的回滚标准以及独立于迁移过程的备份，都可以降低迁移批次在 VM 层面看起来成功但对实际用户失败的风险。

英方软件 提供备份和副本数据管理工具，可以支持此类迁移项目，从保护源 VMware 环境到启动用于验证的测试副本。