如何在 Linux、Windows 和 Proxmox 上将 OVA 转换为 QCOW

将虚拟机设备从 VMware 或 VirtualBox 迁移到基于 KVM 的平台意味着要立即处理一个问题：格式不兼容。你导出的 OVA 文件无法直接在 Proxmox、KVM 主机或 EVE-NG 实验室中工作——这些环境都期望使用 QCOW2 镜像。

本指南将介绍在 Linux、Windows 和 Proxmox 上的完整转换过程，并提供逐步命令和常见问题的解决方案。

什么是 OVA 和 QCOW2？（以及为什么要转换？）

在运行任何命令之前，了解你实际正在处理的内容会很有帮助。

OVA（开放虚拟化格式归档文件）不是一个单一的磁盘文件。它是一个压缩的 TAR 归档文件，将三个组件捆绑在一起：

• .vmdk — 虚拟磁盘
• .ovf — 配置文件（XML 格式）
• .mf — 清单文件（转换时不需要）

QCOW2（QEMU 写时复制第二版）是基于 KVM 的虚拟化平台的标准磁盘格式。与 VMDK 不同，它原生支持精简配置、内置快照和 AES 加密。

OVA 与 QCOW2 对比一览

为什么要转换？

转换 OVA 到 QCOW2 的主要原因是跨虚拟化平台迁移。如果你正在搭建 Proxmox 家庭实验室、在 EVE-NG 中部署网络设备，或者将旧的 VMware 工作负载迁移到基于 KVM 的环境，那么在虚拟机启动之前，磁盘格式必须与目标平台所期望的格式匹配。

如何在 Linux 上将 OVA 转换为 QCOW2

Linux 命令行是进行此转换的最直接环境。qemu-img 工具处理虚拟磁盘格式更改，并且在大多数主流发行版上都可以获得。

前提条件

在开始之前，请确保你已具备以下条件：

• 一个有效的 .ova 文件： 从 VMware、VirtualBox 导出的文件，或下载的供应商设备。
• 已安装 qemu-utils： 在 Ubuntu/Debian 上，运行 sudo apt install qemu-utils。在 RHEL/CentOS 上，使用 sudo yum install qemu-img。
• 足够的磁盘空间： 一个 20 GB 的 OVA 在转换过程中可能会扩展到 40 GB 或更多，具体取决于虚拟磁盘的大小。
• root 或 sudo 访问权限： 稍后将文件移动到系统目录时需要。

步骤 1：解压 OVA 文件

OVA 是一个 TAR 归档文件，因此在转换任何内容之前，你需要先解包它。

tar -xvf your-appliance.ova

这会生成几个文件。你需要的是 .vmdk 文件——虚拟硬盘。.ovf（配置）和 .mf（清单）文件也会被解压出来，但在本次转换中可以忽略它们。

步骤 2：使用 qemu-img 将 VMDK 转换为 QCOW2

解压出 VMDK 后，运行以下命令进行转换：

qemu-img convert -p -f vmdk -O qcow2 your-disk-image.vmdk output-image.qcow2

每个标志的含义：

• -p — 显示进度条。对大型磁盘很有用。
• -f vmdk — 声明源格式为 VMDK。
• -O qcow2 — 将输出格式设置为 QCOW2。

步骤 3：验证转换后的镜像

转换后，确认输出文件是有效的：

qemu-img info output-image.qcow2

检查 文件格式 行是否显示为 qcow2。输出还会显示虚拟磁盘大小与实际占用的磁盘空间大小的对比——这对于发现任何意外的大小差异很有用。

步骤 4：可选：压缩 QCOW2 文件

转换后的文件可能比它实际持有的数据大得多，因为在转换过程中保留了空块。你可以通过第二次传递来压缩它：

qemu-img convert -O qcow2 output-image.qcow2 output-shrunk.qcow2

这会重写文件并跳过空块。一个只有 5 GB 实际数据的 100 GB 虚拟磁盘可以大幅缩小。原始文件不会被修改，因此一旦你验证了压缩后的版本，就可以删除它。

步骤 5：将 QCOW2 与 KVM / virt-manager 一起使用

要将磁盘附加到 KVM 环境中的虚拟机：

1. 将文件移动到默认镜像目录：

sudo mv output-image.qcow2 /var/lib/libvirt/images/

2. 打开 virt-manager（虚拟机管理器）。

3. 点击 新建虚拟机。

4. 选择 导入现有磁盘镜像。

5. 浏览到你的 QCOW2 文件并通过配置 CPU 和 RAM 完成设置。

如何在 Windows 上将 OVA 转换为 QCOW2

Windows 本身不支持 OVA 或 QCOW2，但你有一个选择，无需切换到 Linux 机器：使用 Windows Subsystem for Linux (WSL) 或 qemu-img 的本地 Windows 版本。

前提条件

在开始之前，请确保你已具备以下条件：

• 一个有效的 .ova 文件： 从 VMware、VirtualBox 导出的文件，或下载的供应商设备。
• 足够的磁盘空间： 转换后的 QCOW2 文件可能与 OVA 中声明的虚拟磁盘大小一样大，因此请留出额外空间。
• 已安装 7-Zip： 方法 2 解压 OVA 归档文件时需要。如果没有，请从 7-zip.org 下载。
• 管理员访问权限： 安装 WSL 或在系统驱动器上运行转换命令时需要。

方法 1：使用 WSL（推荐）

WSL 允许你在 Windows 上直接运行 Linux 工具，这使得它成为最可靠的方法。这些命令与 Linux 工作流程中的命令相同。

1. 安装 WSL： 以管理员身份打开 PowerShell 并运行：

wsl --install

这将默认安装 WSL 2 和 Ubuntu。出现提示时重新启动你的机器。如果 Ubuntu 已安装，请跳至步骤 2。

2. 安装 qemu-utils： 在你的 WSL Ubuntu 终端内，运行：

sudo apt update && sudo apt install qemu-utils -y

3. 访问你的文件： Windows 驱动器在 WSL 下挂载在 /mnt/ 目录下。要导航到 C: 盘上的 Downloads 文件夹：

cd /mnt/c/Users/YourName/Downloads/

4. 解压并转换： 遵循上面 Linux 部分中相同的 tar 和 qemu-img 步骤。

方法 2：使用 qemu-img Windows 原生二进制文件

如果你不想使用 WSL，可以使用 qemu-img 的独立 Windows 版本。

1. 下载工具： 从 QEMU 官方网站或 Cloudbase Solutions 版本获取适用于 Windows 的 qemu-img 二进制文件。将归档文件解压到诸如 C:\qemu\ 的文件夹中。
2. 解压 OVA： 在 7-Zip 中右键单击你的 .ova 文件，然后选择 提取到当前位置。这将解压出 .vmdk、.ovf 和 .mf 文件。
3. 运行转换： 在包含你的 VMDK 的文件夹中打开 PowerShell 或 命令提示符，然后运行：

   .\qemu-img.exe convert -p -f vmdk -O qcow2 "source-disk.vmdk" "output-disk.qcow2"

方法 2 的局限性： qemu-img 的 Windows 二进制文件在更新和性能方面可能落后于 Linux 版本。对于生产用途或大型磁盘，WSL 是更可靠的选择。

Windows 上的常见问题

• 文件路径中的空格： 如果你的路径包含空格（例如 C:\Virtual Machines\），除非你用双引号将路径括起来，否则命令将失败，如上所示。
• 长路径错误： Windows 有最大路径长度限制。如果转换意外失败，请将 .vmdk 移动到一个短路径，例如 C:\temp\，然后重试。
• 权限被拒绝： 如果你在处理系统驱动器上的文件，请以管理员身份打开 PowerShell。
• 转换速度慢： NTFS 文件处理使得磁盘写入比在 Linux 上慢。一个 50 GB 的磁盘可能需要几分钟。这是预期行为。

如何为 Proxmox 将 OVA 转换为 QCOW2

Proxmox VE 是 OVA 迁移最常见的目标之一。Web 界面没有直接的 OVA 导入选项，但 Proxmox 提供了可靠处理此过程的命令行工具。

方法 1：直接在 Proxmox 主机上转换

这种方法避免了从本地机器上传转换后的大型磁盘。相反，你先传输较小的 OVA，然后直接在主机上解压和转换。

1. 上传 OVA： 使用 SCP 客户端，如 WinSCP 或 scp 命令，将 OVA 传输到你的 Proxmox 主机。一个安全的目标位置是 /tmp/。

2. 通过 SSH 连接到 Proxmox： 以 root 身份连接：

ssh root@<your-proxmox-ip>

3. 解压并转换：

tar -xvf your-appliance.ova
qemu-img convert -p -f vmdk your-disk.vmdk -O qcow2 managed-disk.qcow2

4. 将磁盘导入到虚拟机： 将 100 替换为你实际的虚拟机 ID，将 local-lvm 替换为你目标存储的名称：

qm importdisk 100 managed-disk.qcow2 local-lvm

方法 2：直接 OVA 转换

某些版本的 qemu-img 可以读取 OVA 的 TAR 包装器并直接转换，而无需先手动解压 VMDK：

qemu-img convert -p your-appliance.ova -O qcow2 output.qcow2

这仅在 OVA 包含单个虚拟磁盘时才能可靠地工作。如果设备有多个磁盘，此方法可能会失败或仅转换第一个磁盘。如有疑问，请使用方法 1。

方法 3：使用 qm importovf（原生 Proxmox 导入）

Proxmox 包含一个内置命令，可以读取 .ovf 配置文件并自动创建虚拟机，包括 CPU 和 RAM 设置。

1. 解压 OVA：

tar -xvf appliance.ova

2. 运行导入： 将 100 替换为你的虚拟机 ID，将 local-lvm 替换为你的存储名称：

qm importovf 100 ./appliance.ovf local-lvm --format qcow2

常见错误： 如果你看到“invalid host resource”，则表示 OVF 引用了一个在你的 Proxmox 主机上不存在的网络名称（例如“VM Network”）。你可以安全地忽略它，并稍后在 Web UI 中手动配置网络接口。

何时使用此方法： 当你希望 Proxmox 根据 OVF 文件自动配置虚拟机设置时，qm importovf 是最佳选择。如果你希望自己控制虚拟机配置，请使用方法 1。

Proxmox 导入后检查清单

导入磁盘后，在 Proxmox Web UI 中完成以下步骤之前，虚拟机将无法启动：

• 附加磁盘： 转到虚拟机的 硬件 选项卡。找到 未使用的磁盘 条目，双击它，然后点击 添加。
• 设置启动顺序： 转到 选项 > 启动顺序。勾选导入的磁盘并将其移动到列表顶部。
• 检查 BIOS 类型： VMware 虚拟机通常使用 UEFI，而 Proxmox 默认使用 SeaBIOS。如果虚拟机找不到可启动磁盘，请转到 硬件 > BIOS，将 默认 (SeaBIOS) 切换到 OVMF (UEFI)。
• 重新配置网络： 迁移后网络接口名称可能会发生变化。通过 Proxmox 控制台登录并更新你的网络配置——例如，在 Ubuntu 上编辑 /etc/netplan/*.yaml，或在基于 RHEL 的系统上编辑 /etc/sysconfig/network-scripts/。

附加内容：如何为 EVE-NG 将 OVA 转换为 QCOW2

网络工程师通常需要一个 QCOW2 镜像来在 EVE-NG（下一代模拟虚拟环境）中运行虚拟防火墙和路由器，例如 Palo Alto、FortiGate 或 Cisco 设备。

转换步骤与 Linux 方法相同，但 EVE-NG 对文件夹名称和磁盘文件名称有严格的要求。请严格按照这些要求操作，否则节点将无法显示或正确启动。

1. 创建设备目录： EVE-NG 期望每个节点类型都位于 /opt/unetlab/addons/qemu/ 下其自己命名的文件夹中。文件夹名称应与你在 EVE-NG 中配置的镜像名称匹配。例如，对于 Palo Alto PAN-OS 9.0.1：

mkdir -p /opt/unetlab/addons/qemu/paloalto-9.0.1/

2. 上传并解压 OVA： 通过 SCP 将你的 OVA 传输到设备目录，然后解压：

tar -xvf your-appliance.ova

3. 转换并重命名磁盘： EVE-NG 要求磁盘文件命名为 virtioa.qcow2 或 hda.qcow2，具体取决于节点类型。一步完成转换和命名：

qemu-img convert -p -f vmdk appliance-disk1.vmdk -O qcow2 virtioa.qcow2

4. 修复权限： 每次添加镜像后运行此命令。它会设置正确的所有者和权限，以便 EVE-NG 虚拟机管理程序可以读取该文件：

/opt/unetlab/wrappers/unl_wrapper -a fixpermissions

跨虚拟化平台 V2V 迁移：超越手动转换

本指南中介绍的命令行方法适用于一次性转换。但是，如果你正在管理一个更大的迁移——将数十个虚拟机从 VMware 环境迁移到 KVM 或 Proxmox，或者在数据中心之间转移工作负载——手动解压和转换很快就会变得耗时且容易出错。

格式不兼容只是挑战的一部分。在过渡期间保持生产系统运行、迁移后验证数据完整性以及处理旧操作系统都增加了复杂性，仅靠 qemu-img 无法解决。

i2Move 是一个统一的迁移平台，专为这些场景而构建。它支持跨物理、虚拟和云环境的无中断实时迁移，无需手动提取磁盘或执行格式转换步骤。

i2Move 的关键特性

• 零停机迁移： i2Move 结合了块级和文件级复制技术，可以在不关闭生产工作负载的情况下迁移正在运行的系统。你的虚拟机在整个过程中保持在线。
• 跨平台覆盖： 支持 P2V、V2V、V2P、物理到云以及虚拟到云的迁移。无论你是从 VMware 迁移到 KVM、整合数据中心，还是将工作负载转移到公有云，该平台都能处理环境差异。
• 旧操作系统支持： 手动 QCOW2 转换的一个实际限制是，较旧的操作系统在迁移后常常由于驱动程序不匹配而无法启动。i2Move 自动处理驱动注入和 BIOS/UEFI 转换，从而提高了在异构硬件上的启动成功率。
• 内置验证： 迁移后，i2Move 执行端到端的数据集验证。这消除了检查手动转换的磁盘是否完整所带来的不确定性。
• 安全传输： 数据使用 AES/SM4 加密传输，并支持带宽控制和断点续传——这在跨慢速或不稳定的网络链路迁移大型磁盘时非常有用。

对于需要大规模迁移或无法承受过渡期间停机的团队来说，i2Move 提供了一条比手动转换更可控、更可审计的路径。

如果你正在重新考虑你的虚拟化基础设施，数据保护是问题的另一面。一旦你的虚拟机在新平台上运行，i2Backup 提供跨物理服务器、虚拟机和数据库（包括 Proxmox 和 KVM 环境）的集中备份。对于可用性至关重要的工作负载，i2Availability 添加了实时复制和自动故障转移，以在主机宕机时保持服务运行。

点击按钮获取 Info2soft 解决方案的免费试用！

常见问题解答

问 1：我可以直接转换 OVA 到 QCOW2 而不解压吗？

有时可以。如果 OVA 包含单个磁盘，并且你运行的是较新版本的 qemu-img，直接转换是可行的。也就是说，首先解压 TAR 文件是更安全的方法——它可以让你确认要使用哪个 VMDK 文件，尤其是当设备包含多个磁盘时。

问 2：QCOW2 比 VMDK 更好吗？

这取决于平台。VMDK 是 VMware 环境的标准格式。QCOW2 针对基于 KVM 的虚拟机管理程序（如 Proxmox）进行了优化，并提供原生压缩、内置快照支持和更高效利用磁盘空间的写时复制行为。如果你运行的是 KVM 或 Proxmox，QCOW2 是更好的选择。

问 3：如何将 CentOS QCOW2 镜像转换回 OVA？

没有单一命令可以完成这个操作。这个过程包括两步：首先，使用 qemu-img 将 QCOW2 转换为 VMDK，然后将该 VMDK 导入 VirtualBox 或 VMware 并导出为 OVA。

转换命令是：

qemu-img convert -p -f qcow2 -O vmdk input.qcow2 output.vmdk

问 4：转换需要多长时间？

这取决于磁盘速度和虚拟磁盘大小。一个 40 GB 的 VMDK 在 NVMe 驱动器上通常需要 2 到 5 分钟完成转换。在传统 HDD 上，预计时间会显著延长。qemu-img 中的 -p 标志会显示一个进度条，让你不会干等。

问 5：我可以从 QCOW2 转换回 OVA 吗？

可以。使用 qemu-img 将 QCOW2 转换回 VMDK，然后使用 VMware Workstation 或 VirtualBox 将 VMDK 打包成 OVF/OVA 归档文件。这些步骤基本上是本指南所涵盖步骤的逆过程。

结论

将 OVA 转换为 QCOW2 归结为几个一致的步骤：解压归档文件，使用 qemu-img 转换 VMDK，验证输出，然后将磁盘附加到目标虚拟机。你正在使用的平台——Linux、Windows 或 Proxmox——会稍微改变工具，但核心过程保持不变。

在你完成之前，有几件事值得记住：

• 转换后始终运行 qemu-img info 以确认输出文件有效。
• 如果转换后的磁盘比预期大，请使用第二次 qemu-img 传递来压缩它。
• 在 Proxmox 上，不要跳过导入后检查清单——启动顺序和 BIOS 类型是迁移的虚拟机无法启动的两个最常见原因。
• 对于 EVE-NG，在运行 fixpermissions 之前，请根据官方社区文档仔细检查文件夹名称和磁盘文件名称。

对于一次性迁移，本指南中的手动方法实用且免费。如果你要迁移多个虚拟机或需要在过渡期间保持生产系统在线，像 英方软件 的 i2Move 这样的专用迁移平台可以消除大量手动工作，并为过程添加内置验证。