虚拟机迁移教程(基于快照方式)

前言

本教程演示如何在 Azure 平台上通过快照方式迁移虚拟机。

重要说明

• 本教程采用的是 托管磁盘快照（Managed Disk Snapshot） 迁移方式
• Azure 还提供 Azure Migrate 工具进行迁移，但不在本教程讨论范围内
• 虽然Azure可以进行不关机的快照，但是为了应用程序的缓存数据可以完整落盘，还是建议进行关机后再快照，这将保证数据的完整性。
• 公网IP是区域级产品，此资源不支持跨区域移动。

涵盖场景：

1. 同账号跨区域迁移（Malaysia West → Japan East）
2. 跨账号迁移（账号 A → 账号 B）

演示环境：

• 操作系统：Ubuntu 24.04 LTS
• 系统盘：30GB
• 数据盘：1 块 100GB 附加磁盘
• 源区域：Malaysia West (Southeast Asia)
• 目标区域：Japan East（跨区域场景）

---

前置条件

通用前置条件

1. 权限要求

• 具有虚拟机的停止/启动权限
• 具有创建快照、磁盘、虚拟机的权限
• 具有虚拟网络的访问权限

2. 目标区域准备

虚拟网络必须提前创建好，配置如下：

操作路径：创建资源 > 虚拟网络

• 资源组：选择或新建目标区域的资源组
• 虚拟网络名称：vnet-japaneast
• 区域：Japan East
• 地址空间：10.1.0.0/16
• 子网名称：default
• 子网地址范围：10.1.0.0/24

Tip

说明：如果目标区域已有可用的虚拟网络，可直接使用，无需新建。

截图占位符：虚拟网络创建配置页面

保持默认即可

4. 配额检查

确认目标区域有足够的配额：

• vCPU 配额（至少与源虚拟机相同）
• 公共 IP 地址配额
• 托管磁盘配额

操作路径：配额 > 设置 > 我的配额

截图占位符：配额检查页面

跨账号迁移额外要求

5. 账号访问

• 能够登录源账号（账号 A）和目标账号（账号 B）
• 两个账号的订阅都处于活跃状态

迁移场景说明

场景一流程图：同账号跨区域迁移

graph TB
    A[源虚拟机<br/>Malaysia West] -->|1. 停止虚拟机| B[已停止状态]
    B -->|2. 创建快照| C[OS磁盘快照<br/>Malaysia West]
    B -->|2. 创建快照| D[数据盘快照<br/>Malaysia West]
    C -->|3. 复制快照| E[OS磁盘快照<br/>Japan East]
    D -->|3. 复制快照| F[数据盘快照<br/>Japan East]
    E -->|4. 创建托管磁盘| G[OS托管磁盘<br/>Japan East]
    F -->|4. 创建托管磁盘| H[数据托管磁盘<br/>Japan East]
    G -->|5. 创建虚拟机| I[新虚拟机<br/>Japan East]
    H -->|6. 附加磁盘| I
    I -->|7. 验证| J[迁移完成]

场景二流程图：跨账号迁移

graph TB
    A[源虚拟机<br/>账号A] -->|1. 停止虚拟机| B[已停止状态]
    B -->|2. 创建快照| C[OS磁盘快照<br/>账号A]
    B -->|2. 创建快照| D[数据盘快照<br/>账号A]
    C -->|3. 生成SAS URL| E[OS快照SAS URL]
    D -->|3. 生成SAS URL| F[数据快照SAS URL]
    E -->|4. 切换到账号B<br/>导入磁盘| G[OS托管磁盘<br/>账号B]
    F -->|4. 导入磁盘| H[数据托管磁盘<br/>账号B]
    G -->|5. 创建虚拟机| I[新虚拟机<br/>账号B]
    H -->|6. 附加磁盘| I
    I -->|7. 验证| J[迁移完成]

---

场景一：同账号跨区域迁移

此场景适用于：将虚拟机从 Malaysia West 迁移到 Japan East（同一订阅账号）。

---

迁移前必要准备：修改 fstab 配置

:::tip重要性 防止因数据盘挂载失败导致系统无法启动。 :::

操作路径：SSH 连接到源虚拟机

为什么需要这一步？

虽然从快照创建的磁盘会保留文件系统 UUID，但为了确保系统在任何情况下都能正常启动，必须修改 /etc/fstab。以下操作二选一：

1. 为数据盘挂载添加 nofail 参数。
2. 注释掉数据盘挂载的所在行。

如果不添加 nofail，可能导致：

• 数据盘附加延迟时系统启动失败
• 进入紧急模式（emergency mode）
• 无法通过 SSH 连接

Tip

以下步骤采用添加nofail参数。

操作步骤

1. SSH 连接到源虚拟机：

ssh azureuser@<源虚拟机IP>

2. 检查当前 fstab 配置：

cat /etc/fstab

查找数据盘的挂载配置，通常类似：

UUID=12345678-abcd-1234-abcd-123456789abc /mnt/data ext4 defaults 0 2

3. 备份 fstab 文件：

sudo cp /etc/fstab /etc/fstab.backup.$(date +%Y%m%d)

4. 编辑 fstab 文件：

sudo nano /etc/fstab

5. 修改数据盘挂载行，添加 nofail 参数：

修改前：

UUID=12345678-abcd-1234-abcd-123456789abc /mnt/data ext4 defaults 0 2

修改后：

UUID=12345678-abcd-1234-abcd-123456789abc /mnt/data ext4 defaults,nofail 0 2

保存并退出（Ctrl+O, Enter, Ctrl+X）

6. 测试 fstab 配置：

# 卸载数据盘
sudo umount /mnt/data

# 测试自动挂载
sudo mount -a

# 验证挂载成功
df -h | grep /mnt/data

如果测试成功，说明配置正确。

7. 退出 SSH 连接：

exit

:::tip关键说明 nofail 参数的作用是告诉系统，如果这个磁盘在启动时不可用，不要阻止系统启动，而是继续启动并记录错误。这样即使数据盘附加有延迟或失败，系统也能正常启动，你可以 SSH 登录后手动排查。 :::

---

步骤 1：停止源虚拟机

操作路径：虚拟机 > 概述 > 停止

1. 在 Azure Portal 导航到源虚拟机
2. 点击顶部的”停止”按钮
3. 在确认对话框中点击”确定”
4. 等待虚拟机状态变为”已停止（已解除分配）”

截图占位符：虚拟机停止按钮位置

截图占位符：虚拟机状态显示”已停止（已取消分配）”

:::tip重要 必须是”已停止（已解除分配）“状态，而非仅”已停止”。只有解除分配才能停止计算费用，并确保磁盘数据一致性。 :::

---

步骤 2：创建 OS 磁盘快照

操作路径：虚拟机 > 磁盘 > OS 磁盘 > 创建快照

1. 在源虚拟机页面，点击左侧菜单”磁盘”
2. 在”OS 磁盘”部分，点击磁盘名称（通常类似 vm-name_OsDisk_1_xxx）
3. 进入磁盘详情页后，点击顶部”创建快照”按钮

截图占位符：虚拟机磁盘页面

截图占位符：磁盘详情页的”创建快照”按钮

快照配置：

• 资源组：选择现有资源组（建议与源虚拟机相同）
• 名称：snapshot-os-ubuntu-malaysiaw
• 快照类型：增量
• 存储类型：标准 HDD（成本最低，适合迁移用途）
• 区域：Malaysia West（必须与源磁盘同区域）

截图占位符：OS 快照创建配置页面

完整快照不支持直传；需要用下载的方式导入磁盘；本示例采用Azure内部直传的方式。

点击”审阅 + 创建” > “创建”

等待快照创建完成（通常 2-5 分钟）。

---

步骤 3：创建数据盘快照

操作路径：虚拟机 > 磁盘 > 数据磁盘 > 创建快照

1. 返回源虚拟机的”磁盘”页面
2. 在”数据磁盘”部分，点击数据盘名称
3. 进入磁盘详情页后，点击”创建快照”按钮

快照配置：

• 资源组：与 OS 快照相同
• 名称：snapshot-data-ubuntu-malaysiaw
• 快照类型：增量
• 存储类型：标准 HDD
• 区域：Malaysia West
• 大小：100 GiB（自动检测）

截图占位符：数据盘快照配置页面

数据盘快照配置页面-1

数据盘快照配置页面-2

点击”审阅 + 创建” > “创建”

:::tip提示 如果有多块数据盘，需要为每块磁盘分别创建快照。 :::

---

步骤 4：复制快照到目标区域

操作路径：快照 > 复制快照

4.1 复制 OS 磁盘快照

1. 在 Azure Portal 顶部搜索栏输入”快照”，进入快照服务
2. 在快照列表中，找到 snapshot-os-ubuntu-malaysiaw
3. 点击快照名称进入详情页
4. 点击左侧菜单”复制到其他区域”

截图占位符：快照详情页的”复制到其他区域”菜单

复制配置：

• 目标区域：Japan East
• 名称：snapshot-os-ubuntu-japane
• 存储类型：标准 HDD

截图占位符：快照复制配置页面

点击”创建”

4.2 复制数据盘快照

重复上述操作，复制数据盘快照：

1. 选择 snapshot-data-ubuntu-malaysiaw
2. 点击”复制到其他区域”
3. 配置如下：
   • 目标区域：Japan East
   • 名称：snapshot-data-ubuntu-japane
   • 存储类型：标准 HDD

点击”创建”

等待时间：根据磁盘大小，快照复制通常需要 10-30 分钟。可以在 Azure Portal 右上角的”通知”图标中查看进度。

---

步骤 5：从快照创建托管磁盘

操作路径：快照 > 创建磁盘

5.1 创建 OS 托管磁盘

1. 点击创建硬盘
2. 找到并点击 snapshot-os-ubuntu-japane
3. 点击顶部”创建磁盘”按钮

截图占位符：快照详情页的”创建磁盘”按钮

磁盘配置：

• 资源组：选择或新建（建议与虚拟网络同一资源组）
• 磁盘名称：disk-os-ubuntu-japane
• 区域：Japan East
• 可用性区域：无
• 源类型：快照
• 源快照：snapshot-os-ubuntu-japane（自动选择）
• 大小：保持与源磁盘相同（30 GiB）
• 磁盘 SKU：Premium SSD（生产环境推荐）

Tip

重要说明：由于虚拟机是从磁盘镜像创建的，源虚拟机系统中的 ~/.ssh/authorized_keys 文件会被完整保留。这意味着原来能够访问源虚拟机的 SSH 私钥，在迁移后依然有效。此处配置的 SSH 公钥会被 Azure 添加到系统中，不会覆盖原有配置。

点击”审阅 + 创建” > “创建”

5.2 创建数据托管磁盘

重复上述步骤，为数据盘创建托管磁盘：

1. 选择快照 snapshot-data-ubuntu-japane
2. 点击”创建磁盘”
3. 配置如下：
   • 磁盘名称：disk-data-ubuntu-japane
   • 区域：Japan East
   • 大小：100 GiB
   • 磁盘 SKU：Premium SSD

截图占位符：数据托管磁盘创建配置

点击”审阅 + 创建” > “创建”

等待托管磁盘创建完成（通常 2-3 分钟）。

---

步骤 6：创建目标虚拟机

操作路径：磁盘 > 创建VM

6.1 基本信息配置

1. 在 Azure Portal 点击左上角”磁盘”
2. 选择”disk-os-ubuntu-japane”
3. 点击”创建VM”

基本信息：

• 订阅：选择你的订阅
• 资源组：选择托管磁盘所在的资源组
• 虚拟机名称：vm-ubuntu-japane
• 区域：Japan East
• 可用性选项：无基础结构冗余
• 安全类型：标准

截图占位符：虚拟机基本信息配置页面

6.2 选择数据盘

1. 点击“附加磁盘”
2. 选择数据盘“disk-data-ubuntu-japane”

6.5 网络配置

• 虚拟网络：选择前置条件中创建的 vnet-japaneast
• 子网：default
• 公共 IP：新建
• 公共 IP 名称：pip-ubuntu-japane
• 网络安全组（NSG）：新建
• 选择入站端口：SSH (22)、HTTP(80)、HTTPS(443)

截图占位符：网络配置页面

6.6 审阅和创建

1. 点击”审阅 + 创建”
2. 检查配置信息无误后，点击”创建”

等待时间：虚拟机创建通常需要 3-5 分钟。

截图占位符：部署进行中页面

由于地域发生了变了，Azure会在从之前的区域中复制一份公钥；因此之前的公钥可以登录使用。

步骤 7：验证迁移

7.1 获取公网 IP 并 SSH 连接

1. 在虚拟机”概述”页面，找到”公共 IP 地址”
2. 复制 IP 地址

截图占位符：虚拟机概述页面显示公网 IP

3. 在本地终端使用 SSH 连接：

ssh azureuser@<新虚拟机公网IP>

成功登录后，你会看到 Ubuntu 的欢迎信息。

7.2 检查 OS 磁盘

# 查看磁盘挂载情况
df -h

# 应该看到类似输出
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sda1        30G  5.2G   24G  18% /

验证系统盘数据完整，检查关键目录：

# 检查用户目录
ls -la /home/azureuser

# 检查应用程序（如有）
ls -la /var/www  # 示例：web 应用目录

7.3 检查数据盘

# 查看所有块设备
lsblk

# 应该看到类似输出
# NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
# sda       8:0    0   30G  0 disk
# ├─sda1    8:1    0 29.9G  0 part /
# ├─sda14   8:14   0    4M  0 part
# └─sda15   8:15   0  106M  0 part /boot/efi
# sdb       8:16   0  100G  0 disk
# └─sdb1    8:17   0  100G  0 part /mnt/data

检查数据盘是否已自动挂载：

由于迁移前已在 fstab 中添加了 nofail 参数，数据盘应该会自动挂载到 /mnt/data。

Tip

UUID没有改变，挂载的目录也没有改变；但是磁盘的顺序可能被改变；比如从之前的/dev/sdc1改变为/dev/sda1。这就是不推荐使用路径挂载的原因之一。

# 检查挂载情况
df -h | grep /mnt/data

# 如果已挂载，应该看到：
# /dev/sdb1       99G   5.0G   89G   6% /mnt/data

如果数据盘未自动挂载（虽然已配置 nofail，但可能附加延迟）：

# 手动挂载
sudo mount -a

# 验证挂载
df -h | grep /mnt/data

# 检查数据完整性
ls -la /mnt/data
du -sh /mnt/data

验证 UUID 是否保留：

# 查看当前数据盘的 UUID
sudo blkid /dev/sdb1

# 查看 fstab 中的 UUID
cat /etc/fstab | grep /mnt/data

两者的 UUID 应该匹配。如果不匹配（极少数情况），需要更新 fstab。

7.4 验证 fstab 配置

由于迁移前已经配置了 nofail 参数，现在验证配置是否正确：

# 查看 fstab 配置
cat /etc/fstab | grep /mnt/data

# 应该看到类似：
# UUID=12345678-abcd-1234-abcd-123456789abc /mnt/data ext4 defaults,nofail 0 2

测试重启后自动挂载（可选）：

# 重启虚拟机
sudo reboot

# 等待 1-2 分钟后重新 SSH 连接
ssh azureuser@<新虚拟机公网IP>

# 验证数据盘自动挂载
df -h | grep /mnt/data

如果数据盘成功自动挂载，说明迁移完全成功。

7.5 验证应用程序和服务（如有）

如果源虚拟机运行了特定服务，需要验证它们是否正常：

# 检查服务状态（示例）
sudo systemctl status nginx
sudo systemctl status mysql
sudo systemctl status your-app-service

# 检查端口监听
sudo netstat -tulnp

7.6 验证网络连接

# 测试出站网络
ping -c 3 google.com

# 测试 DNS 解析
nslookup azure.microsoft.com

# 如果虚拟机提供 Web 服务，从外部访问测试
# 在本地浏览器访问：http://<新虚拟机公网IP>

---

迁移后清理（可选）

完成迁移并验证无误后，可删除以下资源以节省成本：

可删除的资源：

1. 源区域的快照：

   • snapshot-os-ubuntu-malaysiaw
   • snapshot-data-ubuntu-malaysiaw

2. 目标区域的快照：

   • snapshot-os-ubuntu-japane
   • snapshot-data-ubuntu-japane

3. 源虚拟机及其磁盘（如确认不再需要）：

   • 源虚拟机
   • 源 OS 磁盘
   • 源数据磁盘
   • 源公网 IP

操作路径：资源 > 删除

Tip

警告：删除前务必确认目标虚拟机运行正常，并且已备份所有重要数据。建议保留快照至少 7-14 天，以防需要回滚。

---

场景二：跨账号迁移

此场景适用于：将虚拟机从账号 A 迁移到账号 B（不同订阅）。

---

• 资源组：vm-resources
• 版本号：1.0.0
• 数据盘：选择数据盘快照
• 目标Azure compute gallery：image
• 目标VM映像定义：
  • VM映像定义名称：ubuntu-os-may
  • VM体系结构：x64
  • 发布者：myself
  • 产品/服务：ubuntu-os-may
  • SKU：ubuntu-os-may
• 默认存储SKU：标准HDD LRS
• 默认副本计数：1

常见问题

Q1: 迁移过程中虚拟机需要停机吗？

A: 是的，必须停止虚拟机。创建快照时虚拟机必须处于”已停止（已解除分配）“状态，以确保磁盘数据的一致性。在线快照虽然技术上可行，但可能导致数据不一致。

停机时间：

• 停止虚拟机：1-2 分钟
• 创建快照：2-5 分钟
• 复制快照：10-30 分钟（后台进行，不影响源虚拟机）
• 创建新虚拟机：3-5 分钟

总停机时间：约 5-10 分钟（不包括快照复制，因为复制期间源虚拟机可以重新启动）。

---

Q2: 公网 IP 能否迁移？

A: 不能。Azure 的公网 IP 是区域性资源，无法跨区域迁移。跨账号迁移也无法保留公网 IP。

解决方案：

• 使用 DNS 域名而非 IP 直接访问虚拟机
• 迁移后更新 DNS A 记录指向新 IP
• 考虑使用 Azure Traffic Manager 实现无缝切换
• 使用 Azure Front Door 或 Application Gateway 作为统一入口

---

Q3: 私网 IP 能否保持不变?

A: 取决于情况：

同账号跨区域：

• 通常无法保持，因为需要新建 VNet，地址空间可能不同
• 如果提前在目标区域创建相同地址空间的 VNet，可以在创建虚拟机时手动指定相同的私网 IP

跨账号迁移：

• 无法保持，必须使用目标账号的 VNet
• 可以在目标账号创建相同地址空间的 VNet，然后手动指定 IP

保持私网 IP 的方法（同账号内）：

1. 提前在目标区域创建 VNet，使用相同的地址空间（如 10.0.0.0/16）
2. 创建虚拟机时，在网络配置中手动指定私网 IP

---

Q4: 迁移后原来的 SSH 密钥还能用吗？

A: 可以。由于虚拟机是从磁盘快照创建的，系统磁盘中的所有数据都被完整保留，包括 /home/azureuser/.ssh/authorized_keys 文件。

关键点：

• 原有的 SSH 密钥配置保留在磁盘镜像中
• 你可以继续使用原来的私钥登录
• Azure 在创建虚拟机时配置的 SSH 公钥会被添加到系统中，而不是覆盖
• 这意味着新旧两套 SSH 密钥都可以使用

验证方法：

# 登录后查看 authorized_keys
cat ~/.ssh/authorized_keys

# 你应该会看到多个公钥

---

Q5: 数据盘为什么没有自动挂载？

A: 如果按照本教程在迁移前已添加 nofail 参数，数据盘应该会自动挂载。但可能由于以下原因未挂载：

可能原因：

1. 数据盘附加有延迟（Azure 后台操作未完成）
2. 虚拟机启动时数据盘尚未就绪
3. nofail 参数虽然允许系统启动，但磁盘确实不可用

解决方法：

方式一：手动挂载

# 检查磁盘是否识别
lsblk

# 手动挂载所有 fstab 中的磁盘
sudo mount -a

# 验证
df -h | grep /mnt/data

方式二：检查并修复 fstab

# 查看当前磁盘的 UUID
sudo blkid /dev/sdb1

# 查看 fstab 配置
cat /etc/fstab | grep /mnt/data

# 如果 UUID 不匹配（极少情况），更新 fstab
sudo nano /etc/fstab

方式三：重启虚拟机

sudo reboot

重启后数据盘通常会正常挂载。

预防措施：

• 迁移前务必在 fstab 中添加 nofail 参数（本教程已强调）
• 使用 UUID 而非设备名挂载
• 验证 fstab 配置正确性

---

Q6: 迁移会保留虚拟机的标签（Tags）吗？

A: 不会。标签是资源的元数据，附加在资源对象上，不存储在磁盘中，因此不会随快照迁移。

解决方法：

1. 迁移前导出标签：

   # 使用 Azure CLI 导出源虚拟机的标签
   az vm show --resource-group <rg-name> --name <vm-name> --query tags

2. 迁移后批量添加标签： 在 Azure Portal 的虚拟机页面 > 标签，手动添加。

或使用 Azure CLI：

az vm update --resource-group <new-rg> --name <new-vm> \
  --set tags.Environment=Production tags.Owner=IT tags.CostCenter=12345

建议：

• 使用一致的标签策略
• 记录源虚拟机的所有标签
• 使用 Azure Policy 强制标签规范

---

Q7: 如何验证磁盘数据完整性？

A: 可以使用以下方法验证：

文件系统检查：

# 1. 检查文件系统健康状态
df -h
lsblk

# 2. 验证关键目录
ls -la /home
ls -la /var
ls -la /etc

# 3. 比较文件数量（如果有备份清单）
find /mnt/data -type f | wc -l

# 4. 检查磁盘使用情况
du -sh /mnt/data

应用服务检查：

# 验证应用程序服务
systemctl status nginx
systemctl status mysql

# 检查配置文件
cat /etc/nginx/nginx.conf

数据校验：

# 如果迁移前创建了校验和
md5sum /mnt/data/important-file.txt

# 比较迁移前后的校验和是否一致

---

Q8: 迁移后性能是否会受影响？

A: 通常不会，但需要注意以下因素：

影响性能的因素：

1. 磁盘类型：

   • Standard HDD：慢，适合归档
   • Standard SSD：中等性能
   • Premium SSD：高性能，推荐生产环境
   • Ultra Disk：超高性能，适合数据库

2. VM 大小：

   • 确保选择与源虚拟机相同或更强大的规格
   • 注意 CPU、内存、网络带宽限制

3. 区域差异：

   • 不同区域的网络延迟不同
   • 与其他 Azure 服务的连接速度可能变化

性能测试：

# 磁盘读写测试
sudo dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=direct

# 磁盘 IOPS 测试（需安装 fio）
sudo fio --name=randread --rw=randread --bs=4k --size=1G --runtime=60

# 网络测试
ping -c 10 8.8.8.8
curl -o /dev/null https://www.google.com

建议：

• 生产环境使用 Premium SSD
• 选择合适的 VM 大小
• 迁移后进行性能基准测试

---

Q9: 迁移失败如何回滚？

A: 由于迁移是创建新资源，原虚拟机不受影响，回滚非常简单。

回滚步骤：

1. 在源区域重新启动源虚拟机
2. 删除目标区域创建的资源：
   • 新虚拟机
   • 新托管磁盘
   • 新公网 IP
   • 新 NSG（如果新建的）

预防措施：

• 迁移验证完成前，不要删除源虚拟机
• 保留快照至少 7-14 天
• 记录所有配置参数
• 制定详细的迁移检查清单

回滚时间：

• 重启源虚拟机：1-2 分钟
• 删除目标资源：2-3 分钟

---

Q10: 成本如何计算？

迁移过程成本：

1. 快照存储：

   • Standard HDD 快照：约 $0.05/GB/月
   • 30GB OS 快照：约 $1.50/月
   • 100GB 数据快照：约 $5.00/月

2. 跨区域数据传输（场景一）：

   • 出站流量费用（约 $0.05-0.08/GB）
   • 130GB 数据传输：约 $6.50-10.40

3. 托管磁盘（持续费用）：

   • Premium SSD 30GB：约 $4.80/月
   • Premium SSD 100GB：约 $13.78/月

4. 虚拟机计算（持续费用）：

   • Standard_B2s：约 $30-40/月

5. 公网 IP（持续费用）：

   • 静态公网 IP：约 $3.60/月

节省成本建议：

• 使用 Standard HDD 快照（仅用于迁移）
• 迁移完成后及时删除快照
• 验证完毕后删除源虚拟机
• 考虑使用 Azure 保留实例节省 VM 成本

总迁移成本示例：

• 一次性成本：约 $7-11（快照 + 数据传输）
• 清理快照后无额外成本

---

Q11: 支持迁移哪些 Linux 发行版？

A: Azure 支持的所有 Linux 发行版都可以使用此快照方法迁移：

官方支持的发行版：

• Ubuntu (18.04, 20.04, 22.04, 24.04)
• Red Hat Enterprise Linux (7.x, 8.x, 9.x)
• CentOS (7.x, 8.x)
• Debian (9, 10, 11, 12)
• SUSE Linux Enterprise (12, 15)
• Oracle Linux (7.x, 8.x)
• Rocky Linux (8, 9)
• AlmaLinux (8, 9)

注意事项：

1. 确保目标区域支持该操作系统版本
2. 某些旧版本 OS 可能不再受支持
3. 自定义内核可能需要额外配置
4. 确保 Azure Linux Agent (waagent) 已安装

验证 OS 支持：

# 检查 Linux 发行版和版本
cat /etc/os-release

# 检查 Azure Agent
systemctl status walinuxagent

---

Q12: 可以在快照创建后重新启动源虚拟机吗？

A: 可以。快照创建完成后，源虚拟机可以立即重新启动，不影响快照复制过程。

流程：

1. 停止源虚拟机
2. 创建快照（5-10 分钟）
3. 快照创建完成后，重新启动源虚拟机
4. 快照复制在后台进行（10-30 分钟），不影响源虚拟机运行

这样可以最大限度减少业务停机时间。

---

Q13: 迁移时如何处理静态 IP 配置？

A: 如果源虚拟机使用静态私网 IP：

问题：

• 虚拟机内部的网络配置（/etc/netplan/ 或 /etc/network/interfaces）可能配置了静态 IP
• 迁移后 VNet 地址空间可能不同，导致网络不通

解决方法：

1. 迁移前检查：

# 检查网络配置
cat /etc/netplan/*.yaml
cat /etc/network/interfaces

2. 修改为 DHCP（推荐）：

# Ubuntu 20.04+ (Netplan)
sudo nano /etc/netplan/50-cloud-init.yaml

# 修改为：
network:
  ethernets:
    eth0:
      dhcp4: true
  version: 2

# 应用配置
sudo netplan apply

3. 迁移后验证：

# 检查 IP 地址
ip addr show

# 测试网络连接
ping -c 3 8.8.8.8

---

Q14: 为什么必须在迁移前修改 fstab 添加 nofail？

A: 这是避免系统启动失败的关键步骤。

技术原理：

1. 文件系统 UUID 会保留：

   • 快照是扇区级别的完整复制
   • 从快照创建的新磁盘，其文件系统 UUID 与源磁盘相同
   • 理论上，fstab 中的 UUID 配置仍然有效

2. 但存在风险：

   • 数据盘附加到虚拟机可能有延迟
   • Azure 后台操作顺序不确定
   • 虚拟机启动时，数据盘可能尚未就绪

3. 不添加 nofail 的后果：

   # fstab 中如果没有 nofail
   UUID=xxx /mnt/data ext4 defaults 0 2
   
   # 系统启动时找不到磁盘，会：
   # - 进入紧急模式（emergency mode）
   # - 或者启动失败
   # - 无法 SSH 连接

4. 添加 nofail 的好处：

   # 添加 nofail 参数
   UUID=xxx /mnt/data ext4 defaults,nofail 0 2
   
   # 系统启动时：
   # - 如果磁盘可用，自动挂载
   # - 如果磁盘不可用，跳过挂载但继续启动
   # - 可以 SSH 登录后手动排查

实际案例：

没有 nofail 的情况：

# 虚拟机启动日志
[FAILED] Failed to mount /mnt/data
[DEPEND] Dependency failed for Local File Systems
You are in emergency mode...

添加 nofail 的情况：

# 虚拟机正常启动
[  OK  ] Reached target Local File Systems
# 数据盘稍后自动挂载或可手动挂载

验证方法：

迁移后验证 UUID 是否真的保留：

# 查看新磁盘的 UUID
sudo blkid /dev/sdb1
# 输出：UUID="12345678-abcd-1234-abcd-123456789abc"

# 查看 fstab 中的 UUID
cat /etc/fstab | grep /mnt/data
# 输出：UUID=12345678-abcd-1234-abcd-123456789abc ...

# UUID 应该匹配

最佳实践：

即使你确信 UUID 会保留，也应该添加 nofail，因为：

• 防止意外情况
• 生产环境的容错性要求
• 迁移操作的安全性优先

---

总结

本教程涵盖了 Azure 虚拟机基于快照镜像的两种主要迁移场景：

场景一：同账号跨区域迁移

• 适用于业务扩展、区域优化、灾难恢复
• 流程：停止 VM → 创建快照 → 复制快照 → 创建磁盘 → 创建 VM

场景二：跨账号迁移

• 适用于组织重组、项目转移、开发测试环境隔离
• 流程：

核心要点：

1. 迁移前务必停止虚拟机（已解除分配）
2. 目标区域的虚拟网络必须提前创建
3. 公网 IP 无法迁移，需更新 DNS 记录
4. 原有 SSH 密钥会被完整保留在磁盘镜像中
5. 数据盘需手动附加并配置自动挂载
6. 保留快照和源虚拟机直到验证完成

最佳实践：

• 详细记录源虚拟机的所有配置信息
• 使用标签（Tags）管理资源
• 制定详细的迁移计划和验证清单
• 在生产环境迁移前先进行测试迁移
• 选择业务低峰期进行迁移
• 提前通知相关人员停机时间

文档版本：v2.0
更新日期：2025-12
适用环境：Azure Portal (Web)
迁移方式：托管磁盘快照（Managed Disk Snapshot）
目标系统：Ubuntu 24.04 LTS
演示区域：Malaysia West → Japan East