搞虚拟化运维的朋友应该都有过这种经历给KVM宿主机上的虚拟机做一次系统升级或者调试一个需要反复修改内核参数的测试环境改挂了就得从头装系统、重新部署应用。QEMU/KVM快照功能就是为了解决这类问题而存在的。它能在几秒钟之内把虚拟机的磁盘状态“定格”下来之后随便折腾出了问题一条命令就能回到录制时刻。这篇内容我从原理讲到命令实操覆盖virsh和qemu-img两种管理方式也把内部快照、外部快照、快照链、合并这几个高频场景都说清楚适合刚上手QEMU/KVM的运维也适合需要给开发环境做快速回滚的工程师参考。1. 快照到底拍的是什么写时复制机制白话版1.1 别再对着“快照”两个字望文生义很多人第一次接触快照会把它理解成“把整个磁盘完整复制一份”。如果真是这样一个20GB的系统盘快照就要占用20GB空间创建过程也得等上几分钟。qcow2格式的快照不是这么工作的它靠的是Copy-on-Write也就是写时复制。我用一个生活化的比喻来解释你把一份打印好的文档放桌上原稿不动另外拿一叠白纸放在旁边。接下来你只在白纸上写字、改内容原稿始终保持最初的样子。快照就相当于记录“这叠白纸刚开始使用时桌上那份原稿是什么状态”。之后你对虚拟机的每个写入操作都会被引导到新分配的数据块而原来的数据块原封不动地保留下来。这样快照本身只保存“哪些块被改了”的元数据和少量增量数据创建过程几乎瞬时完成空间占用也远小于整盘复制。对于qcow2格式的虚拟机磁盘来说快照的内部实现就是维护了一份“块映射表”。每次虚拟机要写入某个扇区时QEMU会检查这个扇区在快照前后是否指向了同一个物理块。如果这是快照之后的首次写入QEMU先把旧数据保留并标记为快照引用再把新数据写到新物理块。这套机制听着复杂但效果非常直接快照创建不需要暂停业务也不需要大量拷贝数据。1.2 内部快照和外部快照同一个词两种玩法QEMU/KVM语境下快照其实分为内部快照和外部快照很多人在这里栽过跟头。内部快照是把快照数据保存在虚拟机原本的qcow2镜像文件内部用qemu-img snapshot -c或virsh snapshot-create-as创建。它的优点是一个文件走天下不需要额外管理多个文件方便拷贝和归档缺点是快照多了之后镜像文件会越来越臃肿而且单个qcow2文件的完整性一旦损坏所有快照全部完蛋。外部快照则是创建一个新的qcow2镜像作为“覆盖层”原来的镜像文件转成只读的后端。虚拟机的后续写入全部落到新镜像上旧镜像就是那个时间点的完整状态。外部快照天然支持快照链每拍一次快照就往链上叠一层管理起来更灵活也是libvirt快照API更推荐的方式。我一开始做外部快照时总觉得别扭因为命令更繁琐还要记着后端镜像关系。但用久了就会发现外部快照对“多个快照分散在不同时间点、需要单独保留某个分支”的场景实在太合适。比如要测试一个新内核你就可以在主线快照上叠一层新镜像测试完不想要就直接丢弃覆盖层主线环境完全不受影响。1.3 磁盘快照与系统快照一个表讲清楚在virsh的快照语境里还必须区分磁盘快照和系统快照。系统快照不仅保存磁盘状态还会把虚拟机的内存状态一并保存。区别用一张表就能看明白对比项磁盘快照系统快照含内存保存内容虚拟磁盘数据磁盘数据内存/CPU寄存器状态虚拟机状态运行中或关机均可必须是运行中文件体积以增量数据为主额外增加一个与内存等大的状态文件恢复效果磁盘回到过去内存状态不保留连进程、临时数据一起还原适用场景文件级回滚、升级前的操作保护调试偶发故障、复现内存态问题理解了这个区别你就能根据自己的场景选择快照类型。日常做变更保护磁盘快照足够用还便宜调试那种“跑一段时间才出错”的bug系统快照能帮你把现场完整封存下来。2. 最顺手的方式virsh快照命令全流程2.1 创建快照一张命令搞定磁盘和内存我用virsh管理虚拟机比较多日常快照操作基本都在这一层完成。最常用的命令是virsh snapshot-create-as它可以把虚拟机的磁盘状态和内存状态一起保存下来。恢复的时候不光磁盘回到原来的样子连虚拟机当时开着哪些进程、内存里有什么数据都能还原对调试“偶发故障”非常有用。命令格式并不复杂virsh snapshot-create-as --domain win10-test \ --name pre-upgrade \ --description 升级显卡驱动前的快照 \ --disk-only --atomic注意这里我故意用了--disk-only只拍磁盘不拍内存。为什么因为包含内存状态的快照要求虚拟机必须是运行中的并且会把整个guest内存写入磁盘快照文件体积会明显变大创建过程也慢。而磁盘快照无论虚拟机开机还是关机都能拍日常回滚用得最多的就是它。如果你确实需要连内存一起拍把--disk-only去掉就行还可以加上--memspec指定内存状态文件的存放位置。我实测在内存8GB的虚拟机上面做全量系统快照大概多花十几秒和8GB的磁盘空间换来的是“恢复后完全恢复原状”的体验。做操作系统大版本升级之前我一般会拍一个完整系统快照升级出问题直接整体回滚连开机后的环境都不用在重新调。2.2 快照列表、查询与命名规范快照拍多了之后第一步永远是搞清楚当前有哪些快照、当前到底在哪个快照分支上。virsh snapshot-list --domain win10-test这个命令会列出所有快照的名称、创建时间、状态。还可以用--tree参数查看快照之间的父子关系尤其在看外部快照链时非常直观。另一个常用命令是virsh snapshot-current查看当前生效的快照。你还可以用virsh snapshot-info --domain win10-test --snapshotname pre-upgrade查看单个快照的详细信息包括它引用了哪些磁盘、是否有内存状态、是否处于当前分支。我习惯的做法是给快照名称带上语义化前缀比如pre-upgrade、pre-config、dev-20250401名字里包含“这个快照之前的系统状态是什么”。这样过几个月回来翻快照列表不用一个个看描述就能知道该回滚到哪个节点。千万别用snap1、snap2这种名字等列表里出现十几个快照之后你就知道为什么了。2.3 回滚快照回到录制时刻的正确姿势回滚命令看起来很简单virsh snapshot-revert --domain win10-test --snapshotname pre-upgrade但这里有几个细节值得注意。首先如果虚拟机正在运行revert操作会直接把它干停然后从快照恢复业务侧会有明显的中断。最好先virsh shutdown把系统正常关机或者你明确接受“直接回滚会丢失快照之后的所有变更”再执行。回滚之后快照之后做的所有磁盘修改都会消失内存里没有落盘的进程数据也一并丢失。这不是bug而是快照的语义就是这样回到过去就意味着放弃从过去到现在的一切改动。如果需要“回到过去但保留现在的某些文件”正确做法是先给当前状态也拍一个快照再用qemu-img或者挂载方式把需要的文件导出来而不是直接revert。直接revert恢复之后再去旧快照里捞文件操作路径就绕远了。2.4 删除快照的注意事项删除快照用virsh snapshot-delete。这里一个常见的坑是删除一个内部快照会把该快照之后、下一个快照之前的增量数据合并回主镜像这个过程需要时间和空间。如果镜像所在文件系统剩余空间不足删除操作可能失败或者出现磁盘文件暴涨的情况。我建议删除快照前先df -h看下镜像所在文件系统的剩余空间至少保留镜像大小20%以上的余量。外部快照链中的删除操作相对简单只要不删除链顶的活跃层直接把某个历史快照摘掉即可但要注意如果摘掉中间节点它的子孙节点会自动和后端重新建立关系底层数据没有真正删除只是不再被引用。想彻底释放空间还得靠后面要说的blockcommit或者blockcopy。3. 更底层的玩法qemu-img与外部快照链3.1 用qemu-img做内部快照virsh命令本质上是对libvirt API的封装最终调用的是QEMU的能力。如果你在裸QEMU环境或者想脱离libvirt直接操作镜像qemu-img就是主力工具。创建内部快照qemu-img snapshot -c pre-upgrade /data/images/win10-test.qcow2查看快照和恢复qemu-img snapshot -l /data/images/win10-test.qcow2 qemu-img snapshot -a pre-upgrade /data/images/win10-test.qcow2qemu-img的内部快照操作要求镜像格式必须是qcow2。如果虚拟机磁盘是raw格式qemu-img这一套直接不可用需要先转换成qcow2或者改用外部快照的方式。这里我要特别提醒用qemu-img做快照时一定要保证虚拟机处于静止状态或者至少磁盘写入处于稳定状态。最稳妥的办法是先在guest里执行sync或者干脆关机再拍。如果虚拟机正在频繁写入时强行做内部快照虽然QEMU会尽量保证一致性但极端情况下可能出现文件系统层面的不一致恢复后要fsck甚至可能丢数据。3.2 手工创建外部快照与快照链外部快照的核心是“覆盖镜像后端镜像”的组合。创建命令qemu-img create -f qcow2 -b /data/images/win10-test.qcow2 \ -F qcow2 /data/images/win10-test.snap1.qcow2这条命令创建了一个新的qcow2镜像snap1它的backing file指向原始镜像。虚拟机接着用snap1作为磁盘启动所有新增写入都会写到snap1里面原镜像变成只读的底座。这里有两个关键参数需要解释。-b指定后端镜像-F指定后端镜像的格式。很多新手会漏掉-F导致QEMU在打开镜像时要额外探测后端格式效率低而且可能误判。明确写-F qcow2可以让QEMU直接按qcow2格式访问后端少走弯路。继续在snap1上叠快照只需要重复同样的create命令将-b指向当前活跃的snap1。每叠一层快照链就多一个节点。这条链的查询可以用qemu-img info --backing-chain来查看qemu-img info --backing-chain /data/images/win10-test.snap2.qcow2它会从最顶层一路列出所有后端镜像。链太长了会影响性能因为QEMU每次读数据都要沿着链往回查读写路径变长。我的经验是快照链控制在3-5层以内超出后尽早把链合并。3.3 blockcommit合并快照释放空间外部快照链越长不仅性能下降管理也麻烦。合并链的正确姿势是用virsh blockcommit让libvirt把顶层活跃数据回写到后端镜像中。virsh blockcommit --domain win10-test --path vda \ --base /data/images/win10-test.qcow2 \ --top /data/images/win10-test.snap1.qcow2 \ --wait --verbose这个命令会把snap1中的数据合并进原始镜像之后snap1就不再被需要。合并过程中虚拟机通常可以保持开机状态QEMU会处理读写并发的问题但我不建议在业务高峰期做这种操作合并期间磁盘IO会比平时高很多。合并完成之后记得检查顶层镜像的backing file是否指向了合并后的底层。实际操作中我更多用virsh blockcommit把整个链合并成一个单层镜像操作简单一步到位。块拷贝blockcopy则适合要把快照链“摊平”导出成一个独立镜像的场景比如给另一个宿主机迁移虚拟机。命令大概长这样virsh blockcopy --domain win10-test --path vda \ --dest /export/win10-test-flat.qcow2 \ --wait --pivotblockcopy会把整个链读出来写成一个不含backing的扁平镜像导出的文件可以直接拿到别处使用。3.4 快照配合备份与容灾的场景延展快照不只是用来“回滚”它还是备份策略的重要组件。我经常采用“定时任务先打快照、再用qemu-img convert导出”的方式做每日备份qemu-img convert -O qcow2 -c /data/images/win10-test.snap1.qcow2 \ /backup/win10-$(date %F).qcow2如果不导出只是保留快照在原宿主机上一旦物理机磁盘损坏快照和镜像一起报销。所以快照是“操作保护”不是“灾备方案”。要想真正安全必须把快照导出到独立存储。这里有个容易忽略的点导出时一定用convert而不是直接复制qcow2因为带backing的文件复制后没有配套的后端镜像拿到新机器上根本起不来。另外如果你的虚拟机磁盘位于NFS或Ceph这类共享存储上创建快照时还要考虑存储端的快照能力。libvirt支持把外部快照和存储层面的快照结合先通知存储做底层快照再让QEMU切换镜像文件配合得当可以实现秒级快照且不影响性能。这块配置偏复杂生产环境用之前建议在测试环境完整演练一遍。4. 常见问题与排查实录4.1 快照创建成功但revert后系统起不来这是我最常被问的问题。大概率原因不是快照坏了而是虚拟机内部有“快照之外的状态”没有同步。比如你拍快照时没有使用--disk-only也没带内存但guest里的文件系统是ext4日志没有落盘恢复之后文件系统处于不一致状态。解决办法拍快照前在guest里执行sync或者干脆优雅关机后再拍。如果已经出现起不来的情况可以进入紧急模式用fsck修复。实测中大部分ext4/xfs的问题都能通过fsck -y解决Windows虚拟机的NTFS卷则麻烦一些可能需要chkdsk /f。我自己踩过一次最深的坑是在MySQL跑着业务的时候拍快照回滚后InnoDB数据文件不一致最后只能从binlog补数据。从那之后凡是数据库虚拟机拍快照前我一定先stop数据库或者至少flush tables with read lock。4.2 快照链太长导致虚拟机性能下降外部快照链超过10层之后虚拟机的随机读性能肉眼可见地下滑。原理也很简单每一次读IO都要逐层查找数据块是否在本层层数越高查找开销越大。QEMU虽然有l2 cache做优化但在高IO压力下缓存命中率还是会下降。遇到这种情况不要想着手动一层层删除直接用blockcommit把链合并成一层。操作前记得记录当前活跃层快照的位置合并后路径会变域定义里的磁盘路径要同步更新。我处理过一次最极端的案例一台测试机快照链叠了20多层合并完性能直接翻倍整个过程也就十几分钟。4.3 Windows guest快照回滚后网络配置异常Windows虚拟机快照回滚后偶尔出现网卡不识别、IP丢失的情况这通常是设备实例在快照前后被系统认为发生了变化。KVM环境里常见的原因是回滚后virtio网卡的PCI地址变了Windows重新枚举设备导致网络配置失效。我的处理经验是拍快照前在Windows的设备管理器中确认网卡驱动状态并把IP配置写成静态回滚后用PowerShell重新配置或者直接删除网络适配器让系统重新识别。还有一种更省事的办法给Windows guest打快照时连同内存状态一起保存恢复后系统认为自己从未关机设备枚举的动态变化会少很多。4.4 virsh snapshot-delete删不掉提示资源忙这个问题一般出现在外部快照链中你想删除的快照正在被当前活跃的覆盖层引用。libvirt不允许你直接删除链的中间节点因为破坏引用关系。解决方案是先创建一层新的外部快照把当前活跃层“封闭”掉再删除中间节点。或者用blockcommit把中间节点合并进后端再从链里摘除。不要尝试直接rm删除qcow2文件那会让整条链彻底失效。这里我吃过一次亏觉得文件没用了直接rm结果链上所有镜像全部变成孤儿状态虚拟机直接起不来。4.5 qemu-img info看到的backing file路径是绝对路径外部快照创建时-b指定的路径会原样记录在镜像文件的元数据里。假如你创建快照时用了/data/images/win10-test.qcow2后来整个目录迁移到/opt/vm/那么qcow2仍然会去/data/images找后端找不到就会报错。解决办法有两个一是创建时就约定统一路径后续不随意移动二是用qemu-img rebase修正后端路径qemu-img rebase -u -b /opt/vm/win10-test.qcow2 /opt/vm/win10-test.snap1.qcow2-u参数表示只更新路径映射不重写数据。迁移前先查好所有链里的引用路径统一修正能避免大量“镜像找不到”的问题。我现在的习惯是外部快照的镜像全部放在一个固定目录下路径里不包含版本号这样无论是回滚、迁移还是做备份路径问题都少很多。这套快照玩法我在开发环境和生产环境都实际跑了两三年个人体会是快照不该等出事才想起来用而应该形成习惯——每次系统升级、配置变更、应用部署之前花几秒钟拍一张磁盘快照。成本几乎为零收益是“可以大胆试错”的底气。最后再分享一个小技巧定期用virsh snapshot-list把宿主机上所有虚拟机的快照整理一遍删掉那些已经过期的临时快照。快照这东西跟临时文件一样攒着攒着就成了一堆没人认识的历史垃圾到时候想找真正的恢复点反而无从下手。好的快照管理是让每个快照都有明确的“用途”和“过期时间”。