能无损转换但需干预：先用qemu-img info检查format（非streamOptimized才可直转）、disk/virtual size（精简盘会膨胀）、文件列表（-flat.vmdk才是真数据）；转换前必须关机、合并快照、卸载VMware Tools；命令须显式指定-f vmdk和源为-flat文件；streamOptimized需先用vmkfstools转；转完要校验格式、引导方式、磁盘挂载及权限。
能无损转换，但“无损”不等于“零干预”——漏掉快照合并、用错源文件、忽略流式格式，转完照样开不了机。
怎么确认手里的vmdk能不能直接用 qemu-img convert
别急着敲命令。先运行：qemu-img info your-disk.vmdk。重点看三行：
-
format字段：如果是vmdk且没带streamOptimized，大概率可直转；如果输出里有streamOptimized或Unsupported VMDK version，说明这是个 OVA 解包出来的流式镜像，qemu-img会读失败或转出异常大的 qcow2。 -
disk size和virtual size：前者是当前实际占用空间，后者是逻辑容量。如果两者差太多（比如 virtual size 是 100G，disk size 只有 5G），说明是精简置备盘，转换时目标磁盘可能膨胀到接近 virtual size，得预留足够空间。 - 文件列表：用
ls -lh *.vmdk看有没有-s001.vmdk、-flat.vmdk这类后缀。如果有，你手里那个.vmdk很可能只是描述符文件，真正数据在-flat.vmdk里——必须把-flat.vmdk当作源文件传给qemu-img convert，否则转出来的是空壳。
转换前必须做的三件事：关机、合并快照、删 VMware Tools
这些不是“建议”，是避免启动失败的硬性前提：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 虚拟机必须完全关机（不是挂起/休眠），否则文件系统可能处于脏状态，qcow2 启动后出现
EXT4-fs error或直接 kernel panic。 - 在 VMware 中删除或合并所有快照。如果只转换某个快照链中的子 vmdk（比如
vm-000001.vmdk），qemu-img 无法还原完整磁盘视图，结果是分区表错乱、GRUB 找不到/boot。 - 卸载
VMware Tools（尤其是 Linux 客户机）。它会注入专有 SCSI 驱动和 udev 规则，KVM 启动时内核找不到对应模块，卡在Waiting for /dev/disk/by-uuid/xxx。Windows 客户机也建议禁用 VMware PVSCSI 控制器，改用默认的 SATA 或 VirtIO。
转换命令怎么写才不出错
基础命令没错，但参数细节决定成败：
- 显式指定源格式：
qemu-img convert -f vmdk -O qcow2 source-flat.vmdk target.qcow2。加-f vmdk能绕过自动识别 bug，尤其对分片盘或老版本 vmdk 更稳。 - 加
-c参数启用压缩（仅对含大量零块的镜像有效）：qemu-img convert -c -f vmdk -O qcow2 source.vmdk target.qcow2。注意：Windows 系统盘压缩后可能影响 BitLocker 解密，慎用。 - 不要用通配符，比如
qemu-img convert *.vmdk—— 这会让 qemu-img 把多个文件当输入，报Invalid argument直接退出。 - 如果源是 streamOptimized 格式，先用 VMware 官方工具转一次：
vmkfstools -i source.vmdk -d thin intermediate.vmdk（需在 ESXi 主机或 Workstation 的 vmkfstools 环境下执行），再拿intermediate.vmdk去转 qcow2。
转完不能直接跑，还得校验和适配
转换完成只是中间态，KVM 环境下还有两处关键断点：
- 检查引导方式：
qemu-img info target.qcow2输出里看有没有compat: 1.1（支持 UEFI 启动）；如果客户机原是 BIOS+MBR，而 KVM 虚拟机配置了 UEFI 固件，会卡在黑屏。此时需用virt-install显式指定--boot bios。 - 验证磁盘是否可读：
qemu-system-x86_64 -drive file=target.qcow2,format=qcow2 -nographic启动进 rescue 模式，手动lsblk和mount /dev/sda1 /mnt看能否挂载根分区。挂不上？大概率是 VirtIO 驱动缺失，得进客户机装virtio-drivers（Windows）或确保内核含CONFIG_VIRTIO_BLK（Linux）。 - 别忽略权限问题：qcow2 文件属主要是
root:libvirt-qemu（Proxmox/Debian）或qemu:qemu（CentOS），否则 libvirtd 启动时报Permission denied on '/path/to/disk.qcow2'。
最常被跳过的其实是 qemu-img info 的二次校验——转完立刻再跑一遍，对比 virtual size 和 disk size 是否合理，format 是否真变成 qcow2。很多“转完开不了机”的案例，都是因为第一步就用了错误的源文件，但没人回头再看一眼输出。
