如何将 VMDK 转换为 QCOW2：Linux、Proxmox 和 Windows 环境详解

将虚拟机从 VMware 迁移到基于 KVM 的 Hypervisor（如 Proxmox）时，会立即面临一个兼容性问题：QEMU 无法直接启动 VMDK 文件，仅重命名扩展名无法解决该问题，您需要执行 VMDK 到 QCOW2 的格式转换。本指南涵盖 Linux、Proxmox 和 Windows 环境下的 VMDK to QCOW2 转换方法，包括 qemu-img 和 virt-v2v 的使用，以及常见迁移错误的修复方案。

本指南涵盖在 Linux、Proxmox 和 Windows 上将 VMDK 转换为 QCOW2 的方法，包括 qemu-img 工作流、Proxmox 的 importdisk 流程，以及需要重新配置驱动程序时使用的 virt-v2v。文末的故障排查表涵盖了最常见的启动错误。

VMDK vs. QCOW2：有什么区别？

在开始转换之前，了解为什么这两种格式不能互换会很有帮助。

VMDK 是 VMware 的原生磁盘格式，用于 ESXi 和 VMware Workstation。QCOW2 是 QEMU 和 KVM 的原生格式，内置支持快照、压缩和 AES 加密。它是 Proxmox 和大多数 OpenStack 部署的默认格式。

您不能简单地将 .vmdk 文件重命名为 .qcow2。Hypervisor 将无法找到有效的启动头，虚拟机将无法启动。正确的转换会重建内部数据结构，使磁盘在 KVM 下正常工作。

开始之前：转换前检查清单

跳过这些步骤是导致转换产生损坏镜像或虚拟机无法启动的最常见原因。

• 首先检查源 VMDK。 在转换前运行 qemu-img info source.vmdk 以确认文件大小、格式和磁盘类型。
• 提交所有快照。 转换属于快照链一部分的 VMDK 通常会导致镜像过时或不完整。先在 VMware 中删除或合并所有快照，以便使用单个当前磁盘文件进行操作。
• 识别正确的 VMDK 文件。 ESXi 通常将磁盘拆分为一个小的描述符文件和一个以 -flat.vmdk 结尾的大型数据文件。您需要将转换工具指向 -flat.vmdk 文件，或确保两个文件在同一目录中。
• 检查可用磁盘空间。 精简置备的 VMDK 在转换过程中可能会显著扩展。请确保目标驱动器有足够的空间同时容纳原始 VMDK 和输出的 QCOW2 文件。
• 正常关闭虚拟机。 切勿从正在运行或挂起的虚拟机转换磁盘。完整的客户机关机可确保文件系统处于一致状态，没有残留的脏写入。

如何在 Linux 上将 VMDK 转换为 QCOW2（qemu-img）

在 Linux 上转换磁盘格式最直接的方式是使用 qemu-img 工具，它是 QEMU 工具集的一部分。

步骤 1：安装 qemu-utils

大多数 Linux 发行版默认不包含 qemu-img。使用发行版的包管理器进行安装。

对于 Ubuntu 或 Debian：

sudo apt update && sudo apt install qemu-utils

对于 RHEL、CentOS 或 Fedora：

# RHEL/CentOS 7
sudo yum install qemu-img

# RHEL/CentOS 8+, Fedora
sudo dnf install qemu-img

步骤 2：运行转换命令

导航到包含源 VMDK 的目录，然后运行：

qemu-img convert -f vmdk -O qcow2 source.vmdk output.qcow2

参数说明如下：

• -f vmdk：指定输入格式
• -O qcow2：指定输出格式
• -p：（可选）转换期间显示进度条
• -c：（可选）压缩输出以减少文件大小

步骤 3：验证输出

转换完成后，确认输出文件有效：

qemu-img info output.qcow2

该命令返回虚拟大小、实际磁盘使用情况和格式类型。如果格式显示为 qcow2 且虚拟大小与原始磁盘匹配，则转换成功。

步骤 4：处理 Windows 客户机驱动程序

如果源 VM 运行 Windows，转换后在 KVM 上很可能无法启动。Windows 默认不包含 VirtIO 驱动程序，因此无法与 KVM 存储控制器通信。

有两种处理方式：

• 迁移前：在 VM 仍在 VMware 上运行时，在 Windows VM 内部安装 VirtIO 客户机工具，然后再进行转换和导入。
• 迁移后：在创建新的 KVM VM 时，将磁盘总线设置为 IDE 而非 VirtIO SCSI。Windows 可以使用其内置的 IDE 驱动程序启动。VM 运行后，从官方 Red Hat 仓库安装 VirtIO Windows 驱动程序，然后将磁盘控制器切换为 VirtIO SCSI。

如何在 Proxmox 上将 VMDK 转换为 QCOW2

Proxmox VE 基于 Debian，预装了 qemu-img。然而，导入工作流与标准 Linux 转换不同。简单地将 .qcow2 文件复制到存储目录中是行不通的——Proxmox 通过其自身的配置系统管理磁盘，需要使用 qm importdisk 正确注册磁盘。

步骤 1：执行转换

将 VMDK 上传到 Proxmox 主机（通过 SCP 或 Web UI 文件上传），然后运行转换：

qemu-img convert -f vmdk -O qcow2 source.vmdk output.qcow2

步骤 2：将磁盘导入到虚拟机

转换完成后，使用 qm importdisk 将 QCOW2 文件导入到特定的 VM：

qm importdisk <VMID> output.qcow2 <storage_name>

将 <VMID> 替换为目标 VM 编号（例如 101），将 <storage_name> 替换为 Proxmox 存储目标（例如 local 或 local-lvm）。

导入完成后，在 Proxmox Web UI 中转到 VM 的 Hardware 选项卡，在启动前挂载新导入的磁盘。

存储格式限制

并非所有 Proxmox 存储后端都直接支持 QCOW2 文件。

• 基于目录的存储（如 local，文件存储于 /var/lib/vz 下）：原生支持 .qcow2 文件。
• 基于块的存储（如 local-lvm 或 ZFS）：不存储 QCOW2 文件。当您运行 qm importdisk 指向这些后端时，Proxmox 会自动提取数据并将其写入为原始逻辑卷。这是预期行为，通常提供更好的 I/O 性能。

如何在 Windows 上将 VMDK 转换为 QCOW2

qemu-img 并非原生 Windows 应用程序。最可靠的方式是通过 Windows Subsystem for Linux (WSL) 运行它，这为您提供了完整的 Linux 环境，而无需单独的 VM 开销。

步骤 1：启用 WSL 并安装 Ubuntu

以管理员身份打开 PowerShell 并运行：

wsl --install

这会安装 WSL 2 并将 Ubuntu 设为默认发行版。需要重启才能完成设置。机器重启后，终端窗口将打开以完成 Ubuntu 安装。

步骤 2：在 WSL 内部安装 qemu-utils

在 Ubuntu 终端中运行：

sudo apt update && sudo apt install qemu-utils

步骤 3：将 VMDK 复制到 WSL 文件系统中

WSL 将 Windows 驱动器挂载在 /mnt/ 下。C:\VMs\my_disk.vmdk 中的文件在 WSL 中可通过 /mnt/c/VMs/my_disk.vmdk 访问。

然而，直接在 /mnt/c/ 路径上运行转换会因跨文件系统开销而明显变慢。为获得更好性能，先将 VMDK 复制到 WSL 主目录中：

cp /mnt/c/VMs/my_disk.vmdk ~/my_disk.vmdk
cd ~

步骤 4：运行转换

qemu-img convert -f vmdk -O qcow2 my_disk.vmdk output.qcow2

步骤 5：将输出文件移回 Windows

转换完成后，将 QCOW2 文件复制回 Windows 驱动器：

cp ~/output.qcow2 /mnt/c/VMs/output.qcow2

该文件随后可在 Windows Explorer 中访问，并准备传输到您的 KVM 或 Proxmox 主机。

使用 virt-v2v 将 VMDK 转换为 QCOW2

qemu-img 仅转换磁盘格式，不涉及磁盘内部的操作系统。当将 Windows VM 从 ESXi 迁移到 KVM 时，客户机通常会因缺少新 Hypervisor 所需的 VirtIO 驱动程序而无法启动。

virt-v2v 通过一步完成完整迁移来解决此问题。它转换磁盘格式、注入 VirtIO 存储和网络驱动程序、调整引导加载程序，并移除 VMware Tools 以防止冲突。

何时使用 virt-v2v 而非 qemu-img

在以下情况下使用 virt-v2v：

• 源 VM 运行 Windows，手动安装驱动程序不实际
• 您希望直接从运行中的 ESXi 或 vCenter 主机迁移，而非使用导出的文件
• 您需要客户机操作系统自动为新 Hypervisor 环境重新配置

对于 Linux 客户机，qemu-img 通常就足够了。Linux 内核默认包含 VirtIO 驱动程序，因此仅格式转换通常可以正常启动而无引导问题。如果您正在评估命令行之外的其它 V2V 转换工具，我们的指南涵盖了主要选项。

基本 virt-v2v 用法

virt-v2v 可通过包管理器在大多数 Linux 发行版上获得：

# Debian/Ubuntu
sudo apt install virt-v2v

# RHEL/CentOS/Fedora
sudo dnf install virt-v2v

直接从 vCenter 服务器迁移 VM：

virt-v2v -ic vpx://user@vcenter.example.com/Datacenter/esxi-host \
  -it vddk \
  -o local -os /var/tmp \
  my_windows_vm

如果要连接到独立的 ESXi 主机，将 vpx:// 替换为 esx://：

virt-v2v -ic esx://user@esxi-host.example.com \
  -it vddk \
  -o local -os /var/tmp \
  my_windows_vm

该工具将转换后的 QCOW2 磁盘和 .xml 元数据文件输出到指定目录

VMDK 转 QCOW2 故障排查：常见错误与修复

大多数转换问题归结为两个原因：选择了错误的源文件，或者客户机操作系统期望的硬件配置与 KVM 提供的配置不匹配。

下表涵盖了最常见的错误及其修复方法。

使用 i2Move 简化 VMDK 到 QCOW2 的迁移

本指南中介绍的 qemu-img 和 virt-v2v 工作流适用于单个转换。但当您需要在不同环境之间迁移多个 VM，或需要在整个过程保持生产系统运行时，手动命令行工具的局限性就开始显现。没有内置验证、没有集中的进度跟踪，也没有办法在传输中途失败时从中断处继续——只能重新开始。

i2Move是一个统一的迁移平台，正是为这些场景而构建。它支持跨物理、虚拟和云环境的无中断实时迁移，并解决了大规模 VMware 到 KVM 过渡中出现的多个痛点。

i2Move 关键功能：

• 零停机迁移：i2Move 使用混合块级和文件级复制技术，在不关闭生产工作负载的情况下迁移系统，消除了导出和离线转换的要求。
• BIOS/UEFI 转换与驱动注入：对于 Windows 客户机（格式转换后启动失败是常见问题），i2Move 自动处理驱动注入和固件转换，确保迁移后的系统在新环境中正确启动。
• 跨环境覆盖：支持 P2V、V2V、物理到云、虚拟到云等迁移场景，适用范围不限于 VMware 到 KVM。
• 内置验证：执行端到端数据集验证并自动纠错，无需在转换后手动运行 qemu-img info 来验证每个磁盘。
• 安全传输：结合 AES/SM4 加密、带宽控制、并行传输和断点续传，确保长距离或不稳定连接下的可靠传输。

对于迁移完成后还需要持续数据保护的团队，i2Backup 提供跨虚拟、物理和云环境的集中备份。对于可用性要求更严格的工作负载，i2Availability 处理生产与灾备环境之间的实时复制和自动故障切换。

结论

将 VMDK 转换为 QCOW2 归结为为工作选择合适的工具。

对于大多数 Linux 用户来说，qemu-img 通过几个命令即可干净地完成转换。在 Proxmox 上，需要额外的 qm importdisk 步骤来将磁盘正确注册到存储后端。Windows 用户可以通过 WSL 遵循相同的 Linux 工作流。当迁移需要重新配置驱动程序的 Windows 客户机时，virt-v2v 是比纯格式转换更可靠的选择。

无论使用哪种方法，规则都是一样的：导出前提交所有快照，将工具指向 -flat.vmdk 数据文件，并在导入前使用 qemu-img info 验证输出。

对于需要进行更大规模迁移或工作负载不能容忍停机的团队，英方软件的 i2Move 提供了一条更具结构化的路径，具备内置验证、驱动注入和跨异构环境的实时迁移支持。