简介《VMware Workstation运行qcow2镜像操作手册》面向需在桌面虚拟机中验证qcow2镜像的开发、测试与运维人员重点解决VMware Workstation无法直接运行qcow2时如何借助qemu-img完成格式转换并启动麒麟V10系统的问题。资源包共1个doc文档约3.77MB内容紧凑便于按需查阅。文档覆盖环境准备、工具版本匹配、虚拟机创建与系统安装等环节交代VMware Workstation 15.x、qemu-img 9.1.0及Kylin-Server-10-SP1镜像的配合方式并提示虚拟磁盘采用单文件存储等配置细节可帮助读者减少重复试错。该手册已有2029人学习适合用作qcow2镜像本地运行、测试环境搭建与操作排错的参考。1. qcow2 落到 VMware 上为什么双击打不开得先过一道转换手头拿到一个 qcow2 镜像多数人的第一反应是把它拖进 VMware Workstation 双击打开——结果什么也不会发生运气差一点会弹一句「无法识别的磁盘格式」。这不是软件坏了是格式不对口qcow2 是 QEMU/KVM 体系里的写时复制磁盘格式带引用计数和内部快照VMware Workstation 只认 vmdk 家族。中间那道桥就是 qemu-img它把 qcow2 逐簇读出来、按 vmdk 的描述符和 extent 结构重新排布一遍VMware 才肯把它当一块普通硬盘接上去。这篇笔记拆的就是这条链路装 qemu-img、转盘、建虚拟机、挂盘、装麒麟 V10以及真正会把人卡住的几个现场。手里已经有现成 qcow2、又必须在桌面虚拟机上跑起来的运维和测试人员可以照着走一遍。2. 环境准备VMware 15.x 与 qemu-img 9.1.0 各自管哪一段2.1 分工一个离线造盘一个在线跑盘这两个工具的职责边界要先掰清楚否则后面出问题很容易找错方向。qemu-img 是纯离线的镜像处理工具它只在文件层面读写 qcow2、raw、vmdk、vhdx 这些格式不需要 CPU 支持虚拟化也不需要装驱动甚至可以在一个没有图形界面的 Linux 跳板机上跑完再把 vmdk 拷回 Windows。VMware Workstation 负责的是另一半提供虚拟芯片组、虚拟磁盘控制器、虚拟网卡、固件BIOS 或 UEFI把 vmdk 当成一块物理硬盘接到虚拟主板上。手册里给的组合是 VMware Workstation 15.x 加 qemu-img 9.1.0这是个验证过的搭配不是硬绑定。VMware 15.x 对应硬件版本 15能正常识别 monolithicSparse 和 twoGbMaxExtentSparse 两种 vmdk 子格式qemu-img 9.1.0 生成的 vmdk 描述符里 hwversion 默认是 4向下兼容到很老的版本。真正的版本雷区在另一端如果你图省事用了某个发行版自带的 qemu-img 2.x-o subformat的可选值会少几个adapter_type参数也可能不被识别转出来的盘挂上去会报描述符损坏。还有一点值得提前说qemu-img 装在哪台机器上不重要但转换过程是纯 I/O 密集型的。源镜像在机械盘上、目标盘又在同一块机械盘上等于让磁头来回跑速度会掉到 20 MB/s 以下。条件允许的话源和目标分开放或者干脆在一台 NVMe 的 Linux 机器上转完再传。2.2 qemu-img 的两种装法Windows 直装与 Linux 包管理Windows 下最省事的是 weilnetz 的 64 位构建包下载qemu-w64-setup-*.exe双击安装默认路径是C:\Program Files\qemu。装完之后必须在系统环境变量 Path 里追加这个目录否则命令行里敲 qemu-img 会提示不是内部或外部命令。加完记得新开一个命令行窗口已经开着的窗口不会重新加载环境变量。# 新开一个 PowerShell 或 CMD 窗口后执行 qemu-img --version # 期望输出形如 # qemu-img 9.1.0 (v9.1.0-xxxxx) # Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers这里第一个要看的是版本号第一位是不是 9第二个要看的是这条命令能不能正常返回而不是报错。如果返回的是「不是内部或外部命令」九成是 Path 没生效去「系统属性 → 环境变量 → 系统变量 → Path」里确认那行路径在不在以及有没有多打一个反斜杠。Linux 下更简单主流发行版都有现成的包# Debian / Ubuntu 系 sudo apt update sudo apt install -y qemu-utils # RHEL / CentOS / 麒麟系 sudo dnf install -y qemu-img # 验证同时确认支持的输出格式里有 vmdk qemu-img --version qemu-img -h | grep -i vmdk参数含义上没什么弯弯绕但有一个细节qemu-utils和qemu-img是两个不同的包名Debian 系用前者RHEL 系用后者装错了会提示找不到包。另外在麒麟 V10 这类国产化系统上源里带的版本可能偏老如果qemu-img --version出来是 4.x 甚至 2.x转换普通 qcow2 够用但要做 vmdk 的 subformat 精细控制就得自己编译或者用静态包。提示Path 里带空格的路径Program Files在命令行直接调用时要加引号或者干脆先cd到镜像所在目录再用完整路径调用可执行文件能少踩一类莫名其妙的报错。2.3 用 qemu-img info 给镜像做一次开机前体检转换之前先看清楚手里这个东西到底是什么这一步能省掉后面一大半的返工。qemu-img info会输出格式、虚拟容量、实际占用、簇大小、backing file 等关键字段加上--outputjson更好解析。qemu-img info --outputjson kylin-base.qcow2返回的 JSON 里有几个字段要逐个看format必须是qcow2。有些文件后缀写着 .qcow2实际内容是 raw用这个字段能一眼识破。格式判断错了convert 时指定的-f也会跟着错转出来的盘就是一堆垃圾。virtual-size虚拟盘容量也就是客户机里看到的硬盘大小。这个数字必须和源环境的磁盘规格对得上对不上说明镜像被裁剪过或者拿到的是差分盘。actual-size或disk size实际占用。稀疏盘的这个值会远小于 virtual-size属于正常现象不代表镜像残缺。backing-filename这个字段不为空说明拿到的是差分盘它依赖一个基础盘才能读全。直接 convert 时 qemu-img 会把整条链拍平输出一份完整盘这是好事但如果 backing 文件不在同一目录convert 会直接报Could not open backing file。差分盘这个坑值得单独说一句。qcow2 的差分盘在 KVM 环境里常用来做快速克隆母盘放一处、子盘放一处。拿到子盘却忘了拷母盘转换必定失败。补救办法有两个把母盘按原来的相对路径一起拷过来或者用qemu-img rebase -u -b 新路径 子盘把 backing 路径改掉-u表示不安全模式、只改元数据不搬数据速度很快。体检的最后一步是查一致性qemu-img check -f qcow2 kylin-base.qcow2输出No errors were found on the image.就可以放心转。如果出现leaked clusters说明有簇被标记占用但没有引用属于常见的小损坏加-r leaks可以修复。要是报corrupt或者引用计数严重不符那就别硬转了先找原始备份转出来的盘大概率起不来。3. 镜像转换-f / -O / -o / -p 四个参数各决定什么3.1 最小可用命令与逐参数拆解一条能跑通的转换命令长这样看着简单但每个位置写错都会得到不同的失败姿势# qcow2 转单文件稀疏 vmdk带进度显示 qemu-img convert \ -f qcow2 \ -O vmdk \ -o subformatmonolithicSparse,adapter_typelsilogic \ -p \ kylin-base.qcow2 \ kylin-base.vmdk-f qcow2是显式声明源格式。不写这一项 qemu-img 会自己探测探测逻辑靠读文件头魔数绝大多数情况没问题但当文件头被别的数据覆盖过、或者镜像做过不完整的截断探测会给出错误结论接着整个转换就在错误的解析器上跑结果不可预期。花两秒写上换一份确定性。-O vmdk指定目标格式这个没什么可商量的。要注意的是目标文件名后缀qemu-img 不会根据后缀猜格式-O写什么就是什么后缀只是给人看的。写成kylin-base.vmdk而-O raw最后得到一个名字叫 vmdk 的 raw 文件挂上去必定失败。-o后面跟的是目标格式的私有选项逗号分隔。对 vmdk 来说最关键是两个subformat决定文件形态和稀疏策略adapter_type决定描述符里记录的控制器类型提示。-p是进度条。别小看这个参数几十 GB 的镜像转起来少则几分钟多则半小时没有进度显示的时候完全分不清是卡住了还是在正常工作很多人就是在这一步忍不住 CtrlC留下一个半截的残废文件。转换命令执行完之后工作目录里应该只多出一个kylin-base.vmdkmonolithicSparse 的情况下。如果看到一堆kylin-base-s001.vmdk、kylin-base-s002.vmdk说明 subformat 没生效或者写错了落到了默认的分片格式上。3.2 subformat 与 adapter_type 的搭配表这两个选项的组合决定了 VMware 那边能不能顺利认盘值得单独列一张表对着选。subformat文件形态Workstation 15.x 支持适用场景monolithicSparse单个 .vmdk稀疏分配原生支持直接挂首选桌面单机迁移monolithicFlat.vmdk 描述符 -flat.vmdk 数据文件支持靠描述符定位需要外部工具直接读平面数据twoGbMaxExtentSparse每 2GB 一个分片文件支持但文件多易丢目标分区单文件大小受限twoGbMaxExtentFlat每 2GB 一个平面分片支持老式归档、教学演示streamOptimized单文件压缩偏向只读能开写入性能差且有兼容问题OVA 导出、归档分发不写 -o默认随 qemu-img 版本变化不稳定不建议赌adapter_type的可选值是ide、buslogic、lsilogic默认lsilogic。它影响的是 vmdk 描述符里记录的几何参数柱面/磁头/扇区以及 VMware 打开时给出的控制器建议。adapter_type对应 VMware 控制器客户机内核驱动建议lsilogicLSI Logic SAS / Parallelmptspi、mptsas默认首选现代内核都有buslogicBusLogicBusLogic只在很老的内核上才需要ideIDEata_piix除非客户机内核极老否则别选选ide最常见的后果不是起不来而是起来之后磁盘性能极差因为 IDE 模拟路径长、队列深度浅。有人迁移完觉得虚拟机卡排查半天 CPU 和内存最后发现是 adapter_type 选错了。还有一个容易被忽略的搭配问题adapter_type必须和 VMware 虚拟机设置里实际选的控制器类型一致。转换时写了lsilogic虚拟机里却配了 SATA 或者 NVMe虽然 VMware 有时也能认但描述符里的几何参数和实际控制器对不上会在某些分区表上触发出容量识别错误客户机里lsblk看到的盘比实际小一圈。3.3 转换后的三道校验转完不要急着往 VMware 里挂先做三步校验能挡掉大部分低级错误。第一道比虚拟容量# 源盘和目标盘的 virtual-size 必须完全一致 qemu-img info kylin-base.qcow2 | grep -i virtual qemu-img info kylin-base.vmdk | grep -i virtual两个数字差一个字节都说明转换过程有问题可能是源盘读到了坏簇也可能是目标分区空间不够导致写入被截断。第二道看目标文件的实际大小是否合理。monolithicSparse 转换后的文件大小约等于源盘的actual-size如果比源盘的 virtual-size 还大说明稀疏特性丢了整个盘被撑满了虽然能用但白白浪费空间。第三道反向挂回 qemu 验证可读性# 让 qemu 以 vmdk 格式打开刚转出来的文件读一下分区表 qemu-img info -f vmdk kylin-base.vmdk # 更进一步把 vmdk 当块设备映射出来看分区 sudo qemu-nbd --connect/dev/nbd0 -f vmdk kylin-base.vmdk sudo fdisk -l /dev/nbd0 sudo qemu-nbd --disconnect /dev/nbd0qemu-nbd这一段的作用是把 vmdk 挂成 Linux 的块设备fdisk -l能列出分区表就说明文件结构完整、分区信息没丢。这一步尤其适合在真正开机前就发现问题——如果这里就报分区表损坏那 VMware 里必然也起不来不用浪费时间排查引导。用完一定要--disconnect否则 nbd 设备会一直被占着。3.4 耗时、空间与中断处理转换速度基本由磁盘 I/O 决定跟 CPU 关系不大。经验值机械盘 20–40 MB/sSATA SSD 150–250 MB/sNVMe 400–800 MB/s。一个实际占用 50GB 的 qcow2在 NVMe 上大约 4–6 分钟在机械盘上可能接近 40 分钟。空间预留上目标盘所在分区至少要有「源盘实际占用 × 1.2」的空闲空间。稀疏盘在写入过程中会临时展开尤其是转换中途如果遇到大量非零数据块占用会快速上升。空间不够时的表现是转换跑到一半报No space left on device然后留下一个语义上不完整但文件大小看着挺正常的 vmdk这种文件挂上去往往能识别、能开机但跑到某个位置就 I/O 错误属于最难查的一类问题。注意转换中途中断CtrlC、断电、磁盘满留下的目标文件必须删掉重转不要试图在原文件上续传。qemu-img convert 没有断点续传机制残留文件的描述符和 extent 对不上能挂上纯属运气。4. VMware 侧落地建虚拟机、挂盘、改 vmx 的三步硬操作4.1 先分路线直接启动 vmdk还是先装 ISO 再挂盘这一步选错了后面全是无用功。手册里写的顺序是「先建虚拟机 → 装麒麟 V10 → 再运行 qcow2 镜像」这条路线属于第二种情况不是唯一解。路线 A直接启动qcow2 里已经是一个完整的、可引导的麒麟系统你只是想在 VMware 里把它跑起来。做法是新建虚拟机时选「稍后安装操作系统」建完之后删掉默认磁盘把转换好的 vmdk 挂上去开机。这条路线最快也最考验源盘的引导配置有没有跨平台问题。路线 B先装 ISO 再挂盘qcow2 里的系统起不来、需要救援或者你只是想把 qcow2 当数据盘读出来。做法是用 Kylin-Server-10-SP1 的 ISO 装一个干净系统装完再添加一块硬盘指向转换好的 vmdk进去挂载分区拷数据。两条路线在创建虚拟机这一步的操作是一样的分歧点在「磁盘」这一屏。判断依据很简单qemu-nbd映射出来之后能不能看到完整的/boot和根分区以及分区表是 GPT 还是 MBR。4.2 创建虚拟机时的五个关键选项新建虚拟机向导里选项不少真正影响能不能开机的只有五个。固件类型要跟源盘的分区表对上。源盘是 GPT EFI 系统分区ESP虚拟机就必须选 UEFI源盘是 MBR就选 BIOS。选错的表现很有辨识度GPT 盘配 BIOS 固件开机直接进「no bootable device」MBR 盘配 UEFI 固件会掉进 EFI Shell 或者提示找不到启动项。判断方法是在 Linux 上用fdisk -l看Disklabel type是gpt还是dos。磁盘控制器选 SCSI类型 LSI Logic跟转换时的adapter_typelsilogic对齐。这一步在向导的「自定义硬件」里改默认可能是 SATA 或 NVMe要根据源系统的内核模块情况决定。挂载已有磁盘时向导会问「保留现有格式」还是「转换」。一定选保留。选转换的话 VMware 会用自己的逻辑再写一遍磁盘结构对于从 qcow2 转来的盘这一步很容易丢掉分区对齐信息而且耗时很长完全是白做功。「存储为单个文件」这个选项只对新建虚拟磁盘有效。手册里提到它是因为路线 B 在装 ISO 时需要新建一块系统盘这时候选单个文件确实省事避免目录里堆一堆 s001、s002 分片搞混。但如果你挂的是已有 vmdk这个选项是灰的不用在这儿纠结。处理器那一栏如果虚拟机里要跑容器或者嵌套虚拟化需要勾上「虚拟化 Intel VT-x/EPT 或 AMD-V/RVI」。不勾的话客户机里egrep -c (vmx|svm) /proc/cpuinfo返回 0容器运行时直接报错。4.3 手工改 vmx 把已有磁盘挂上去图形界面有时候不给力尤其是挂载路径里带中文或者空格的时候。最稳的办法是关掉虚拟机直接用文本编辑器改.vmx配置文件。.vmx是纯文本键值对以#开头的行是注释解析器会跳过。# 关闭虚拟机后编辑 .vmx以下为关键片段 scsi0.present TRUE scsi0.virtualDev lsilogic scsi0:0.present TRUE scsi0:0.fileName kylin-base.vmdk scsi0:0.deviceType scsi-hardDisk scsi0:0.mode persistent # 固件类型源盘是 GPT 就写 efiMBR 写 bios firmware efi efiBootOrder 0000scsi0.virtualDev决定控制器型号可选值有lsilogic、buslogic、pvscsi、ahci、nvme。这里有个性能与兼容性的权衡pvscsi是半虚拟化控制器吞吐和 IOPS 明显好于lsilogic但它需要客户机内核里有vmw_pvscsi模块。从 KVM 迁过来的系统initramfs 里通常只有 virtio 系列驱动没有 pvscsi配上去就是开机时VFS: Unable to mount root fs on unknown-block或者直接 kernel panic。稳妥起见先用lsilogic把系统跑起来进去之后再补驱动、换控制器。scsi0:0.deviceType必须写scsi-hardDisk。写成disk、hardDisk这些都会被静默忽略虚拟机启动后设备列表里没有那块盘但配置文件看着「像是对的」极具迷惑性。scsi0:0.mode有三个值persistent写入立即落盘、undoable关机丢弃、nonpersistent关机丢弃且不询问。做迁移验证的阶段建议用persistent避免关机时一个误点把刚配好的环境丢了。efiBootOrder这个字段在 VMware 15.x 里是按枚举顺序排列的启动设备列表写0000表示第一块可引导设备。如果机器上有多个 EFI 分区可以写成0000,0001按优先级尝试。改完 vmx 之后重新打开虚拟机如果 VMware 弹窗提示「此虚拟机可能已被移动或复制」选「我已复制该虚拟机」。这个弹窗的触发原因是 vmdk 描述符里记录的路径或者 UUID 和当前 .vmx 里的对不上。选错成「我已移动」会让 VMware 把网卡 MAC 重新生成一遍客户机里基于 MAC 绑定的网络配置就全废了。4.4 从 KVM 迁过来的两项必修如果源 qcow2 是从 KVM 环境里拷出来的两项配置必须改否则系统起不来或者起来没网。第一项是 virtio 驱动缺失。KVM 里的系统盘一般挂在 virtio-blk 上设备名/dev/vda内核启动参数root和/etc/fstab里大多写的也是/dev/vda或者对应的 UUID。VMware 没有 virtio-blk 控制器客户机内核在 initramfs 阶段根本找不到这块盘表现是卡在dracut-initqueue timeout然后掉进 emergency shell。修复要靠路线 B用 ISO 引导进救援模式chroot 到原系统把新控制器驱动塞进 initramfs。# 在救援环境里假设原系统根分区挂在 /mnt/sysroot chroot /mnt/sysroot /bin/bash # 确认当前内核版本 uname -r # 重建 initramfs显式加入 SCSI 和 SATA 驱动 dracut --force \ --add-drivers mptspi mptsas ahci \ /boot/initramfs-$(uname -r).img \ $(uname -r) # 用 UUID 重写 fstab 的根分区条目避免设备名变化导致挂载失败 blkid /dev/sda2dracut的三个参数里--add-drivers是关键它保证mptspiLSI Logic Parallel和mptsasLSI Logic SAS被编进早期用户空间。ahci是给 SATA 控制器兜底的加进去不会有害。--force表示覆盖已有镜像。重建完检查一下lsinitrd /boot/initramfs-$(uname -r).img | grep mptspi有输出才算成功。fstab和 grub 里的root都要改成UUID形式因为mptspi控制器下设备名通常是/dev/sda但换成pvscsi或者加了第二块盘之后顺序会变。UUID 是文件系统级别的标识不随控制器和插槽变化。grub 这边用grub2-mkconfig -o /boot/grub2/grub.cfg重新生成或者手工改/etc/default/grub里的GRUB_CMDLINE_LINUX。第二项是网卡名对不上。KVM 里 virtio-net 的设备名一般是ens3或eth0VMware 的e1000e在麒麟 V10 上通常枚举成ens33或ens160。NetworkManager 的 connection 名字和ifcfg-*文件名都是绑在旧设备名上的新系统起来之后nmcli device status里能看到设备但状态是disconnected因为这些设备没有任何 connection 匹配上。# 看看现在实际有哪些设备 nmcli device status # 看现有 connection 绑的是哪个设备名 nmcli -f NAME,DEVICE connection show # 把已有 connection 改绑到新设备名 nmcli connection modify ens3 connection.interface-name ens33 # 重新激活 nmcli connection up ens3如果系统里启用了 cloud-init还有一层坑cloud-init 靠 instance-id 判断要不要重新跑网络配置阶段镜像拷贝过来之后 instance-id 没变cloud-init 会认为「这台机器已经配置过了」跳过网络初始化。这时候nmcli改完可能重启又回去了。处理办法是先cloud-init clean --logs清掉状态再重启让 cloud-init 重新生成一遍配置。5. 避坑与排查五个把虚拟机搞成黑匣子的现场5.1 转换直接报 Could not open backing file现象qemu-img convert刚启动就退出错误信息里带Could not open backing file: No such file or directory目标目录里什么都没生成。原因源 qcow2 是差分盘qemu-img info的backing-filename字段指向一个基础盘而那个文件不在当前目录或者路径已经失效。从 KVM 环境打包镜像时只拷了子盘、没拷母盘是最常见的触发方式。解决先qemu-img info --outputjson确认 backing 文件的原始路径然后二选一——把母盘按原相对路径拷到对应位置或者用qemu-img rebase -u -b /新路径/母盘.qcow2 子盘.qcow2把引用改到新位置。改完再跑一次qemu-img check确认链完整最后才 convert。5.2 挂上 vmdk 开机直接进 EFI Shell现象虚拟机开机屏幕上是Shell提示符或者一行No bootable device found没有任何系统引导迹象。原因固件类型和源盘分区表不匹配。qcow2 里的系统原本是 UEFI GPTVMware 虚拟机却配了 BIOS 固件BIOS 找不到 MBR 里的引导代码只能交差。反过来 MBR 盘配 UEFI 固件同样找不到 ESP 分区。解决在 Linux 上用fdisk -l 源盘看Disklabel typegpt就改 vmx 里的firmware efidos就改成firmware bios。改完别急着开机顺手检查一下 vmx 里有没有残留的bios.bootOrder字段有的话删掉避免和efiBootOrder打架。5.3 卡在 dracut-initqueue timeout现象开机走了内核引导日志刷到dracut-initqueue[xxx]: Warning: dracut-initqueue timeout - starting timeout scripts反复几次之后掉进dracut:/#的紧急 shell。原因客户机内核的 initramfs 里没有当前虚拟磁盘控制器的驱动。从 KVM 迁移过来的系统initramfs 里只有 virtio_blk、virtio_pci 这些VMware 配的lsilogic需要mptspipvscsi需要vmw_pvscsi两者都没编进去内核在早期用户空间阶段枚举不到根设备。解决走路线 B 用 ISO 进救援模式chroot 之后dracut --force --add-drivers mptspi mptsas ahci重建 initramfs。如果确定要长期用 pvscsi就把vmw_pvscsi也加进--add-drivers重建完再改 vmx 的scsi0.virtualDev。改完在紧急 shell 里可以直接验证ls /sys/module | grep mpt看模块在不在。5.4 磁盘容量显示只有一半或者为零现象系统能起来但lsblk看到的盘容量远小于预期或者df -h里根分区大小对不上更严重的直接报 I/O error。原因三种可能。一是转换时目标分区空间不足写入被截断vmdk 描述符里声明的 capacity 和实际 extent 长度不符。二是用了twoGbMaxExtentSparse但中间某个分片文件丢了或者没拷全VMware 读到缺失的分片就停在那儿。三是 vmdk 描述符里的几何参数柱面数和分区表里的 CHS 记录冲突多见于很老的 MBR 盘。解决先用vmware-vdiskmanager -R 目标.vmdk尝试修复描述符。修不好就重转重转时确认目标分区空闲空间够源盘实际占用 × 1.2并且改用monolithicSparse避开分片丢失的风险。容量问题不要试图在 VMware 里靠「扩展磁盘」修扩出来的空间和原分区表对不上只会更乱。5.5 开机后网络起不来nmcli 显示 disconnected现象系统正常登录ip a能看到网卡设备但没分配 IPnmcli device status里设备状态是disconnectedping外网不通。原因KVM 到 VMware 的网卡设备名变了ens3变成ens33或ens160原有的 NetworkManager connection 绑在旧设备名上匹配不上任何实际设备。如果系统里跑了 cloud-init还有一层instance-id 没变cloud-init 认为网络已经配置过跳过初始化阶段手动改的配置重启后可能被覆盖回去。解决先用nmcli connection modify 连接名 connection.interface-name 新设备名改绑再nmcli connection up 连接名。如果重启后又回到 disconnected执行cloud-init clean --logs清状态再重启。改完用nmcli -f NAME,DEVICE,STATE connection show确认连接和设备对上了别只看ip a有设备就以为好了。6. 快照与收尾验证qcow2 的内部快照迁不过去怎么办前面一路顺下来系统能开机、能登录很多人到这儿就收工了。真正容易在后面翻车的是快照这一块。qcow2 的快照是内部快照多个状态内嵌在同一个文件里靠引用计数管理。qemu-img convert只导出当前活动层也就是你qemu-img info看到的那个状态历史快照一个都不会带过去。有人以为转完 vmdk 之后在 VMware 里能看到原来的快照列表打开一看空空如也然后开始怀疑转换是不是失败了——其实没失败是格式本身就不支持这种迁移。如果原环境里的快照有保留价值正确做法是在 KVM 侧先把每个快照的合并视图分别导出来一个快照一条命令各转一份 vmdk到 VMware 里当成多块独立的盘挂载。合并导出用qemu-img convert -l snapshot名-l参数指定要导出的快照层不写就导出当前层。这一步做完几份 vmdk 之间是完全独立的互相没有依赖也不存在链式关系。到了 VMware 这边快照机制是外部链式的拍一次快照就在旁边生成一个-000001.vmdk增量文件虚拟机配置自动指过去。这个差异带来一个操作习惯上的调整——vmdk 的快照链一旦变长合并consolidate会花很长时间而且合并过程中如果磁盘空间不够会卡死。我的习惯是迁移完成、系统验证通过之后立刻拍一个干净快照当基线之后所有折腾都在这个基线之上做出问题直接回滚比留着七八个中间状态省心得多。收尾验证不要只看「能进桌面」。我一般会按固定的几条过一遍检查项命令期望结果磁盘容量lsblk各分区大小与源环境一致根分区挂载df -h /挂载点正确使用率正常网卡状态nmcli device status设备 state 为 connected失败单元systemctl --failed输出为空或仅为已知无关项引导日志journalctl -b -p err无持续刷屏的硬件错误文件系统dmesg | grep -i ext4无 I/O error、无 remount read-only这张表我基本是机械执行的不看结果好坏只求每次迁移完走一遍。血泪经验来自一次赶时间的迁移系统起来了、能登录、能上网就直接交付了两天后对方反馈跑批任务莫名中断查下去是根分区被内核 remount 成只读原因是转换时目标盘空间不足导致某个 extent 长度不对dmesg里早有EXT4-fs error在刷只是当时没看。从那以后我每次迁完都强制走一遍上面这张表尤其是journalctl -b -p err和dmesg这两条宁可多花十分钟也不想在交付之后被叫回去查一个本来五分钟就能发现的问题。希望帮到你。本文还有配套的精品资源点击获取