虚拟机死循环重启？系统化排查与修复指南

虚拟机死循环重启？教你一招轻松解决

先描述一个很常见的场景：早上打开虚拟机，屏幕闪了几下，刚看到系统Logo，下一秒又重新回到开机界面，像钻进了没有出口的环形道。你能听到风扇声，能看见虚拟机的电源指示灯亮着，但系统就是进不去。更让人上火的是，前一天还好好的，你也没改任何东西，它就这样开始“作妖”了。

我是做虚拟化运维的，VMware Workstation、VirtualBox、还有那些跑在裸机上的虚拟化平台，前前后后折腾了十多年。这类“死循环重启”问题，我遇到过的次数多到都能写一本《虚拟机自救手册》了。说实话，一开始遇到我也慌，试过重装、试过恢复快照、甚至把整个虚拟磁盘删了重建，后来才发现，绝大多数情况下根本不用重装系统，按套路排查下来，半小时内基本就能救回来，有些情况甚至几分钟就能搞定。

这篇就把我的排查经验系统地拆开讲一讲。不管你是Windows还是Linux虚拟机，不管你用的是VMware还是VirtualBox，核心思路都是通用的。只要手头虚拟机出现过无限重启、卡在开机LOGO反复跳、或者系统更新完之后就像抽风一样拉起“重启—失败—再重启”的怪圈，这篇内容都能帮你少走弯路。

1. 分清症状：死循环重启到底有哪两种面孔

1.1 开机黑屏型：引导阶段无限转圈

第一种死循环，是虚拟机连系统桌面都没进，就一直在开机阶段打转。表现是黑屏上滚几行字，然后闪回开机LOGO，反复循环。这种问题通常出在引导层。

对Windows来说，可能是BCD引导配置损坏、磁盘分区表异常，或者更新中断导致引导文件不完整。对Linux来说，大概率是内核模块加载失败、/etc/fstab挂载出错，或者显卡驱动在启动阶段就让整个会话崩溃。

判断这种问题有一个很直观的技巧：观察屏幕上的报错停留时间。如果每次都是刚跑完BIOS自检就又重启，多半是硬件层面的虚拟设备配置冲突；如果能进入到系统加载界面才重启，那更像是系统内部的问题。

1.2 系统更新怪圈型：转一会儿就自动重启

第二种死循环，发生在系统更新阶段。你给虚拟机打了补丁，重启之后屏幕上出现“正在配置更新，请不要关闭计算机”，然后进度条卡了一半，紧接着自动重启，又回到同一个界面，如此往复。

这类问题最经典的代表就是Windows Server 2012更新死循环。Windows Server 2012 R2在安装月度累积更新时会执行比较久，如果磁盘空间紧张、权限有问题，或者补丁本身与某个组件冲突，更新程序会陷入“安装失败—回滚—再尝试”的死循环。关键是这个阶段你什么操作都做不了，鼠标转圈，屏幕提示别关机，可它自己偏偏一直重启，非常气人。

1.3 为什么老系统最容易踩这个坑

如果你细看网上一搜“虚拟机死循环重启”的求助帖，十有八九都带着Windows Server 2012、Windows 7虚拟机、老Linux内核这类关键词。原因并不复杂：老系统的更新机制没那么健壮，而且网上流传的旧镜像文件，往往还带着前一个装机者残留的配置问题。我下载过不少教学用的Windows Server 2012镜像，本身解压就有文件损坏，装完第一次更新就触发重启循环，这种情况一点都不稀奇。

所以先别急着怀疑虚拟化软件坏了，这一步要做的是把问题定位准确，然后对症下药。

2. 快速保命：出现死循环时的第一步抢救

2.1 日志先行：从vmware.log里挖第一手线索

遇到死循环重启，我建议你第一步先看日志，而不是急着点击“重启虚拟机”按钮。为什么？因为系统每次重启，都会在日志里留下故障现场。你多重启一次，现场就可能被覆盖一次。

VMware Workstation的日志位置在虚拟机的安装目录下，文件名是vmware.log。用记事本打开，搜索Fault、error、reset这些关键词，能看到是在哪一步触发了重启。VirtualBox的日志则在菜单栏里：选中虚拟机，点击“日志”标签，能看到完整的启动记录。这些日志能帮你确认重启是虚拟硬件层面的强制复位，还是系统内部的Blue Screen崩溃。

Windows系统本身也会记录事件日志，进入系统后用eventvwr.msc打开事件查看器，重点看“事件ID 41（Kernel-Power）”和“事件ID 6006/6008”，能告诉你上次关机是正常还是意外的。有一个特别容易被忽视的细节：Windows事件查看器里的“BugCheck”事件，后面一般跟着四个十六进制参数，那个就是蓝屏的bugcheck code。拿这个code上网一搜，往往比你看一整篇技术文档都管用。

2.2 硬重置后的临时保命法：关掉快速启动再说

如果虚拟机彻底进不去系统，只能硬重置。VMware里点“重新启动客户机”，如果没用，就“关闭电源”再开机。VirtualBox里则是点“重置”按钮。这一步操作完再开机，你会发现一部分虚拟机其实能正常进系统了，但如果你再次重启，问题又会出现。

这种情况，尤其是Windows虚拟机，八成和“快速启动”机制有关。快速启动是Windows 8之后默认开启的功能，原理类似冬眠：关机时并不真正退出内核，而是把内存映像写入磁盘。这个机制在物理机上容易出问题，在虚拟机上更容易出问题。虚拟磁盘的IO性能、快照机制、以及宿主机休眠状态，都会导致快速启动恢复失败，从而引发开机就重启的循环。

解决办法很简单：能进系统的话，打开控制面板—电源选项—选择电源按钮的功能，把“启用快速启动”取消勾选。如果已经进不去系统了，在WinRE的修复模式下选择“命令提示符”，执行一条命令：

powercfg /h off

这条命令能彻底关闭休眠文件和快速启动功能。我处理过的很多Windows虚拟机，关掉快速启动后，“重启一次好一次，关机再开又死”的现象就彻底消失了。

2.3 从宿主机往虚拟机粘贴命令的几个门道

在处理这些问题的时候，你大概率需要在虚拟机的命令行窗口里输入一大堆命令。手动敲既慢又容易错，能直接粘贴就粘贴。VMware如果已经安装并运行好open-vm-tools，宿主机和客户机之间可以直接共享剪贴板，文本复制粘贴顺滑得很。VirtualBox需要在虚拟机内安装增强功能包（Guest Additions），装好后也支持双向粘贴。

但许多虚拟机死循环状态下，桌面和网络都不通，粘贴功能也指望不上。我的习惯是：直接在Windows宿主机上把要用的命令写到一个txt文件里，然后在虚拟机还在Windows恢复环境阶段，用命令提示符把那段文件读出来：

type D:\cmd.txt

如果连盘符都不确定，先执行wmic logicaldisk get name列出所有盘符，再逐个尝试。这个方法虽然土，但确实是我在无数台虚拟机里验证过的地气做法。

3. Windows Server 2012 更新死循环的专项处理

3.1 症状与成因拆解：不是所有“更新重启”都是同一种病

Windows Server 2012更新死循环，算是所有死循环问题里最有“知名度”的一个。我见过一台配置完全没问题的Server 2012虚拟机，打完当月补丁后重启，直接卡进“配置更新30%”的界面，反反复复三天，最后更新程序自己把补丁回滚了才消停。有时候甚至回滚都不行，直接变成无限重启。

遇到这种情况，先按兵不动，不要再反复点击重启按钮。每重启一次，更新程序就多一次“重新尝试”的机会，反而会让问题更顽固。正确的姿势是：强制断电两次，让系统进入自动修复（WinRE）模式。如果进不到WinRE，就尝试在开机时按F8（需要提前关闭快速启动），或者在WinRE里打开命令提示符。

进入命令提示符后，先执行下面的命令，把系统引导成安全模式：

bcdedit /set {default} safeboot minimal

注意，执行完别忘了重启。这一次重启就进入纯命令行风格的安全模式，更新程序不会在安全模式下自动运行，相当于给系统争取到了一段“不被继续折磨”的珍贵时间。

3.2 标准修复三步走：停服务、清缓存、离线修复

安全模式进去后，打开命令行，依次执行这几条命令，把Windows Update相关服务全部停掉：

net stop wuauserv net stop bits net stop cryptsvc

然后进入Windows目录，把SoftwareDistribution目录重命名，这个目录是Windows更新缓存的存储位置。通常的做法是：

cd C:\Windows ren SoftwareDistribution SoftwareDistribution.bak ren System32\catroot2 System32\catroot2.bak

重命名的好处是，即便之前的缓存文件已经写坏了，系统也会在下次更新时重新创建一份，而不会去读坏数据。然后就轮到DISM出场了。如果这台虚拟机还能联网，执行：

dism /online /cleanup-image /restorehealth

如果网络不通，可以挂载当初的安装ISO，用里面的install.wim当修复源，命令写法稍微复杂一点，但核心参数不变：

dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:1 /limitaccess

最后把安全模式标记移除，重启进入正常模式：

bcdedit /deletevalue {default} safeboot shutdown /r /t 0

这套流程处理过很多更新死循环的虚拟机，总体成功率在八成以上。之所以要“清缓存重建”，是因为很多更新死循环的根源，就是更新缓存的某个文件损坏，更新程序一直去读、一直失败、一直重试。

3.3 治本选项：快照回滚与按批次打补丁

如果你在更新之前做过系统快照（snapshot)，处理起来就更简单了，直接回滚到更新前的状态，然后再重新打补丁。但回滚前记得先导出一份更新日志，否则你都不知道是哪个补丁惹的祸，回滚完依然会踩同一个坑。

从那次之后我养成了一个习惯：任何Windows Server虚拟机打补丁前，必拍快照。这个习惯看起来不起眼，但关键时候比什么都好用。有一句话我想说给所有新手听：快照不是给虚拟机“买保险”，而是给你自己一个无限次“后悔”的机会。更新出问题、误删文件、系统崩溃，只要有快照，十分钟之内就能回到出事前的状态，这种安全感是任何修复工具给不了的。

打补丁的时候也别心急，别一次性把当月补丁全部拉满。我建议先把补丁分两批：第一批装“累积安全更新”和“关键更新”，重启后稳定了，再装其他非安全更新。分区隔离能显著减少补丁之间的相互干扰，这个策略尤其在老系统上管用。

4. 虚拟机环境特有坑：配置、磁盘与驱动四大雷区

4.1 CPU和内存给得太“好”反而容易重启

死循环重启的锅，并不总是软件更新的。我在处理虚拟机问题时发现，不少虚拟机的死循环重启，根源出在“配置太好”：CPU核数给得过多，内存给得太满。

很多人潜意识里认为虚拟机性能越强越不容易出问题，其实不然。虚拟机每一个虚拟CPU，宿主机都要用线程去调度。如果你给Windows Server 2012分配了8个虚拟CPU，但宿主机本身只有4核8线程，那虚拟机的线程就会频繁抢占物理资源，操作系统自己就会被拖出明显的卡顿感。更新程序加载大量线程时，这种卡顿感会被放大，轻则任务停止响应，重则整个系统看门狗超时，强制复位。

我的经验是：Windows Server 2012打更新的时候，临时把虚拟CPU减到2—4核，内存预留2—4GB就够了。更新完再把资源加回去。这招看起来反直觉，但实测下来，更新过程的稳定性好了不止一星半点。

4.2 磁盘空间耗尽导致的“启动即重启”

另一个极其容易被忽视的坑：虚拟磁盘空间不足。Windows系统更新时需要释放临时文件、备份旧文件、写入新文件，如果C盘只剩三五百兆，更新程序写到一半空间不够了，Windows会把已写入的文件清掉，然后进入回滚状态。如果每种回滚路径也都需要空间，系统直接死循环重启。

所以我处理更新死循环时，开机进系统后的第一件事一定是检查磁盘剩余空间。在安全模式下，执行：

fsutil volume diskfree C:

看到剩余空间少得可怜，我会先把Windows临时文件清一清：

del /q /f /s %TEMP%\*.* cleanmgr /sagerun:1

再不行就用VMware的“扩展磁盘”功能，把虚拟磁盘容量调大。但这里有个坑：扩展虚拟磁盘大小后，你必须在客户机里用磁盘管理工具把新空间分配给你想要的分区，不然系统是看不到那些空间的。Windows Server 2012上用diskpart能很顺手地搞定：

diskpart list volume select volume C extend

extend命令会对相邻的未分配空间做扩容，整个过程几十秒，比重新迁移磁盘轻松多了。

4.3 Linux内核模块与显卡驱动不兼容

Linux虚拟机的死循环重启，们最常见的诱因是内核升级后和显卡驱动模块不匹配。特别是Ubuntu虚拟机黑屏进不去桌面、启动循环重启这些情况，基本都指向gdm或lightdm服务在启动时崩溃，而背后往往是NVIDIA或AMD虚拟机显卡驱动加载失败，系统在内核态直接panic重启。

解决思路：在GRUB菜单出现时，按下键盘的e键，在linux行末尾加上nomodeset参数，然后按F10引导。这个参数会临时禁用图形驱动的模式设置，让系统退回到基本的帧缓冲驱动，大概率能进入命令行界面。进入系统后，把损坏的显卡驱动卸载掉，再重新安装对应内核版本的驱动，问题通常就能解决。

Linux内核日志是定位这类问题的最好工具。如果能进命令行，执行：

journalctl -b -1

来查看上一次启动（-b -1代表倒数第一次）的日志。如果是引导阶段崩溃，你还能通过dmesg找到崩在哪一行。我处理过不少案子，最后的结论都是“内核版本升级，驱动没跟上”，所以Linux系统更新之前，我都会先去官方源确认新一轮内核能否顺利匹配现有驱动，如果没有把握就先做快照再说。

4.4 嵌套虚拟化与硬件加速选项误区

还有一个容易被忽略的虚拟化环境特有坑：VMware和VirtualBox默认都会开启硬件辅助虚拟化（如VT-x/AMD-V）。如果你的宿主机自身开启了Hyper-V、Windows沙盒等嵌套虚拟化功能，同时虚拟机又想使用硬件加速，这会触发深层冲突，导致虚拟机开机后直接进入反复重启的循环。

遇到了就打开虚拟机设置，找到“虚拟化引擎”相关选项，暂时禁用里面的“虚拟化Intel VT-x/EPT或AMD-V/RVI”勾选，再尝试启动。我在一家同事的Windows宿主机上遇到过类似情况，那次折腾了一下午，最后发现就是嵌套虚拟化冲突。值得一说的是，禁用硬件加速会降低一些运行性能，但换来回的稳定性绝对值得。

5. 死循环重启排查速查表与日常预防

5.1 一张表搞定：症状、根因、对策

写到这里，我把遇到过的死循环重启问题整理成一张速查表，贴到下面，方便大家对照排查。日常工作中遇到类似问题，我会先在文档里先比一圈，匹配上后再动手，能少走很多弯路。

这个表格看着简练，但每一条背后都有实际案例支撑。如果你觉得当下问题和表格里某一行特别像，照方抓药就行。

5.2 我踩坑总结的日常预防清单

说到底，“死循环重启”最让人崩溃的地方是被动。与其等虚拟机抽风了才去救，不如平时就做好防护。我从自己踩过的坑里总结了一些预防套路，分享给大家：

• 关键时刻必拍快照：任何系统更新、驱动升级、大版本迁移前，必须拍一个干净状态的快照。这个习惯救过我太多回了。
• 控制更新节奏：生产用途的虚拟机尽量别开启自动更新，手动分批更新，一次只更新一部分，重启验证后再进行下一批。
• 定期检查磁盘余量：Windows C盘和Linux根分区最好保留15%以上的剩余空间，这是给系统和更新缓冲留出的安全边界。可以用宿主机定时任务跑一个磁盘空间检查脚本，低于阈值就发告警。
• 更新前先看日志：Windows事件查看器里的错误日志和Linux的dmesg，建议养成熟练查阅的习惯。日志不光是事后追责用的，更是提前发现问题的最好参考。
• 禁用不必要的自动重启：Windows的“系统失败时自动重新启动”选项，我是常年关掉的。它一自动重启，你会连蓝屏代码都看不到，诊断无从谈起。

实际工作中，我现在遇到虚拟机死循环重启，第一反应不再是“完了又要重装系统”，而是冷静地先回答三个问题：是在哪个阶段重启的？日志说了什么？有没有快照可以回滚？思路一清晰，解决步骤自然就像流水线一样往下走，这种解决掉麻烦的踏实感，也算是这些年折腾虚拟机生涯里最大的收获之一了。