Azure经典VM迁移至ARM：Commit前需检查哪些结果？

一、检查迁移生成的ARM影子资源 #

准备阶段完成后，Azure会在指定资源组生成对应ARM格式的"影子资源"（未正式激活，不影响原经典VM），重点核对以下内容：

• 虚拟机基本信息：确认影子VM的名称、实例大小、区域和原经典VM完全一致
• 磁盘配置：检查OS盘、数据盘的数量、容量、存储SKU（标准/高级）是否匹配原配置，磁盘的挂载逻辑是否正确（比如数据盘的盘符/挂载点）
• 网络资源：
  • 虚拟网络/子网的地址空间、子网范围和原经典网络一致
  • NSG（网络安全组）规则是否完整迁移原经典VM的端点配置（比如RDP/SSH端口、业务端口的放行规则）
  • 公共IP的SKU、分配方式（静态/动态）和原配置一致（如果原VM有公网IP）
• 附属资源：如果原VM属于可用性集、负载均衡器，确认对应的ARM资源配置和原经典环境一致

二、VM内部内容的测试方法（准备阶段VM已停止时） #

准备阶段原经典VM处于停止状态，但可以通过临时启动影子VM来验证内部内容：

1. 在目标资源组找到影子VM，启动它（此操作不影响原经典VM）
2. 登录VM（Windows用RDP，Linux用SSH）后执行以下检查：
   • 磁盘与数据：Windows查看磁盘管理器确认所有数据盘挂载正常；Linux执行lsblk/df -h验证挂载，检查关键业务文件、数据库数据是否完整
   • 业务服务：启动Web应用、数据库等核心服务，测试本地访问（比如localhost:80）确认功能正常，验证数据库连接、API调用等依赖关系
   • 服务状态：Windows通过服务管理器检查关键服务是否自动启动；Linux用systemctl status [服务名]确认服务运行状态
   • 网络连通性：测试内部网络访问（比如同VNet内的其他服务）、出站网络访问（比如外部API、公网资源）是否正常
3. 测试完成后立即停止并解除分配影子VM，避免产生额外费用，同时不影响后续Commit流程

三、Commit前的必查项（生产环境重点） #

除了资源和内部内容检查，还需确认以下关键事项：

• 备份有效性：确认原经典VM的最新备份（如Azure备份服务生成的备份）完整可用，确保迁移失败时能快速回滚
• 权限配置：检查目标资源组的RBAC权限是否配置正确，运维人员需具备对应的管理权限（如虚拟机参与者、网络参与者），避免Commit后无法正常运维
• 成本核对：确认影子资源的计费SKU（如VM大小、磁盘类型）和原经典VM一致，避免Commit后出现非预期的成本上涨
• 依赖资源兼容性：如果VM依赖其他经典资源（如经典存储账户、经典云服务），确认这些资源已同步迁移或完成ARM兼容改造
• 回滚预案：明确回滚步骤（迁移页面点击「Discard」可取消迁移，恢复原经典VM运行），并确认原经典VM处于正常停止状态，未被修改
• 监控配置：确保ARM环境的监控（如Azure Monitor指标、日志）已配置完成，Commit后能正常采集VM和业务的监控数据

四、生产环境Commit操作建议 #

• 选择业务低峰期执行Commit，减少对业务的影响
• Commit完成后立即启动ARM VM，快速验证服务状态、网络连通性和核心业务功能
• 保留原经典VM的备份至少3天，确认ARM VM运行稳定后再彻底清理相关资源

内容的提问来源于stack exchange，提问作者aVar