★ FEATURED ARTICLE 1. 先别重装搞懂 “active / running 失败” 到底在告诉你什么如果你也遇到过这种情况Kali 虚拟机在 VMware、VirtualBox 或者 KVM 管理界面里明明显示active/running但打开控制台却黑屏、卡在开机动画、SSH 永远连不上或者虚拟机进程还在但系统已经成了一块“砖”不用急着删掉重装。这类问题我排查过很多次大部分时候不是 Kali 镜像坏了也不是虚拟化平台坏了而是我们误读了“运行状态”这四个字。先说一个核心概念active和running只是虚拟化平台或者 systemd 给你看的“进程存活”信号。虚拟机管理面板显示 running只代表 QEMU、VMware VMX 或 VBoxHeadless 这个进程还在跑Kali 内部某个服务显示 active (running)也只代表 systemd 认为这个服务没有退出。但进程活着不等于系统活得好更不等于桌面、网络、SSH 都能正常工作。很多“active 中 running 失败”的场景其实是虚拟机进程没有崩但 guest 内部的启动流程卡死或者某个关键服务起不来。所以遇到这个状态第一反应应该是“分层定位”先判断是虚拟化层的问题、内核引导的问题还是桌面/服务的问题。接下来我会把每层怎么查、怎么修都拆开讲附带可以直接照抄的命令和参数。1.1 先区分“虚拟机状态”和“系统服务状态”很多人把两件事搞混了。virsh list --all或 VMware 主界面显示的 running是虚拟机生命周期状态Kali 里systemctl status ssh输出的 active (running)是 systemd 管理的服务状态。前者只说明虚拟机进程还没退出后者只说明某个单元仍在运行。两者都可能“假阳性”。我举一个真实的例子Kali 在虚拟化平台里已经显示 running但你到虚拟机里执行systemctl --failed看到一堆单元处于 failed 状态比如lightdm、NetworkManager-wait-online或networking。这就是典型的“虚拟机没崩溃但关键服务没起来”。如果你只是看着管理面板的 running 图标就会误以为系统正常继而怎么排查都找不到点。还有一种更隐蔽的情况虚拟机面板显示 running但 Kali 内核早就 panic 了只是 QEMU/VMware 进程没退出所以面板不刷新。你看到的是一个永远不会变化的黑屏或者最后几行内核日志。这时候必须让 guest 的内核日志能传到宿主机否则永远不知道里面发生了什么。1.2 把故障分成三层定位效率直接翻倍我习惯把这类故障分成三层第一层虚拟化层。包括 VMX/VMDK 配置错误、VT-x/AMD-V 没开启、宿主机 Hyper-V 冲突、磁盘空间不足、虚拟机固件模式BIOS/UEFI不匹配。第二层Guest 内核层。包括 GRUB 引导参数错误、initramfs 损坏、显卡驱动加载失败、文件系统损坏、内存不足导致 OOM。第三层桌面/服务层。包括 LightDM 起不来、Xorg 无法识别虚拟显卡、SSH 未启用、NetworkManager 没接管网络。每一层的问题表现都可能是“active 中 running 失败”。如果不分层你会在一个地方死磕很久。我见过有人为了修 VMware 3D 加速导致的黑屏去重装显卡驱动结果问题其实只是 VMX 文件里的mks.enable3d FALSE被改坏了。2. 先收集证据再谈修复日志比直觉可靠排错最忌讳的就是凭感觉。虚拟机状态显示 running 却失败你首先要拿到三份东西宿主机侧的虚拟机日志、guest 侧的内核日志、guest 侧的 Xorg/服务日志。这三份日志收集齐了90% 的问题都能直接看出答案。2.1 从宿主机侧抓虚拟机日志不同虚拟化平台日志位置不一样VMware Workstation日志在虚拟机目录下的vmware.log。路径一般是文档\Virtual Machines\虚拟机名\vmware.log。重点搜Panic、Failed、vcpu-0、SVGA、MKS这些关键词。KVM/libvirt日志在/var/log/libvirt/qemu/虚拟机名.log宿主机上用sudo tail -f /var/log/libvirt/qemu/kali.log实时看。VirtualBox日志在~/.config/VirtualBox/Machines/虚拟机名/Logs/VBox.log重点看有没有 “Guru Meditation” 或者 “Host memory low”。你不需要读懂全部日志先把报错行前后 20 行截下来。比如 VMware 里常见的VMX错误多半是配置损坏SVGA相关错误多半是显卡设置问题Host guest memory相关错误多半是内存不够。一个小技巧在 Windows 宿主机上跑 VMware 时如果打开虚拟机直接报“无法连接到虚拟机。请确保您有权运行该程序、访问该程序使用”优先看服务权限和 Hyper-V 冲突而不是看 Kali 内部。这个问题经常出现在 Windows 开启内存完整性或 Device Guard 之后VMware 的虚拟化模块无法加载虚拟机进程起一半就退。2.2 从 guest 侧抓内核日志串口是最强手段如果 Kali 卡在引导早期你无法登录系统也就看不到/var/log。这时候要用串口把内核日志导出来。在 GRUB 菜单里选中 Kali 内核那一项按e进入编辑模式找到linux开头的那一行在末尾加上consolettyS0,115200n8然后按Ctrlx启动。接着在宿主机侧用串口连接KVM 下执行sudo virsh console kaliQEMU 命令行下用-serial mon:stdio启动VMware 里需要先添加一个串行端口选择“输出到命名管道”再用 PuTTY/telnet 连接到管道。这样内核启动过程中任何 panic、卡死、驱动加载失败都会实时打印。我遇到过一例 Kali 安装后“running 但黑屏”的问题串口日志里其实早就写着BUG: unable to handle page fault是虚拟化平台给的内存映射有问题换一种显卡模型立刻恢复。2.3 用“最小启动”验证硬件兼容性等日志到手后再做一次“最小启动”把 Kali 的虚拟机配置降到最低只保留单核 CPU、2GB 内存、一个虚拟网卡、一块虚拟显卡禁用声卡、USB 控制器、3D 加速、共享文件夹。然后从 Kali ISO 或 Live 模式启动。这个动作的目的不是让你以后用最低配置跑 Kali而是为了缩小变量。如果最小配置能进系统说明问题出在某一项虚拟硬件上再逐项加回来直到复现问题。这比瞎猜快得多。3. 高频根因与针对性修复先查这五个地方根据我自己的排错记录Kali 虚拟机显示 running 却启动失败90% 都集中在五个地方。你按顺序查命中率非常高。3.1 虚拟显卡和 3D 加速导致的黑屏或启动卡死这是最常见的一种。Kali 默认桌面环境对图形要求不低但虚拟平台提供的显卡不一定兼容。表现通常是虚拟机进程 running控制台黑屏或者能到登录界面但一点就花屏还有的会卡在“Loading...”。你可以看到 Xorg 日志里有no screens found或Failed to load module vmwgfx。处理方式VMware 里关闭“加速 3D 图形”。菜单路径是“虚拟机 - 设置 - 显示器”取消勾选“加速 3D 图形”显卡类型改成“VMware SVGA II”显存至少给 128MB。KVM 里virsh edit kali找到video段把model typeqxl改成model typevirtio或者反过来试一试。不同的 Kali 版本对virtio-vga和qxl的兼容性不一样两个都试一下记住改完要重启。如果还是黑屏在 GRUB 启动参数里追加内核参数nomodeset。这个参数会强制内核不做显卡模式切换配合 VMware SVGA 或 QXL 驱动能绕过很多花屏问题。我自己踩过的坑是在 KVM 里给 Kali 开了 3D 加速结果启动后控制台黑屏但 SSH 是通的。一开始以为是系统问题后来用串口看到是vmwgfx驱动尝试分配显存失败改回virtio-vga后正常。3.2 CPU 虚拟化没开或嵌套虚拟化缺失Kali 里的很多工具需要虚拟化支持比如某些安卓模拟器、docker 的某些场景。如果宿主机没有给虚拟机开 VT-x/AMD-VKali 在运行到需要虚拟化的指令时就会报错甚至直接卡死。VMware 里虚拟机设置 - 处理器 - 勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”。注意这个选项默认可能是关闭的特别是用“快速创建”方式建的虚拟机。KVM/QEMU 里CPU 模式建议设成host-passthrough这样 guest 能直接继承宿主机的虚拟化特性。需要用virsh edit kali改cpu modehost-passthrough/。Windows 宿主机特别容易踩坑如果系统开启了 Hyper-V、WSL2、内核隔离、内存完整性会跟 VMware Workstation 抢虚拟化通道。表现为 VMware 启动虚拟机时报“无法启用虚拟机平台”或者“VMware Workstation 和 Hyper-V 不兼容”。解决方法是临时关闭 Hyper-V 相关功能再去虚拟机功能里取消“虚拟机监控程序平台”然后重启。如果你必须同时用 WSL2 和 VMware那一般优先考虑换用 VirtualBox 6.1 以上的版本它对 Hyper-V 的共存处理比旧版好很多。3.3 内存和磁盘空间意外不足Kali 默认桌面环境很吃内存官方建议至少 2GB实际跑起来 4GB 才算舒服。如果给的内存太小内核启动到一半就可能 OOM系统进程被杀然后控制台冻结但 hypervisor 进程还活着面板自然显示 running。宿主机侧先看两样东西df -h free -h如果根分区满了虚拟机半虚拟化驱动或者交换文件无法创建启动也会失败。VMDK/QCOW2 这类动态扩容磁盘表面看起来文件只有几十 GB但实际使用中可能突然涨满。尤其是给 Kali 跑一些容器或者抓包任务时磁盘增长极快。如果内存和磁盘都没问题再进 Kali 内部看dmesg | grep -i oom。如果在日志末尾看到Out of memory: Killed process说明就是内存不够给虚拟机加内存即可。3.4 GRUB 引导参数、固件模式不匹配很多时候 Kali 不是起不来而是起来得太安静出错信息被quiet splash遮住了。GRUB 默认的引导参数里带着quiet和splash在虚拟机上这些参数没有意义反而会把关键错误淹没在开机动画后面。建议直接去掉。同样是在 GRUB 里按e编辑把linux那一行末尾的quiet splash删掉也可以换成systemd.log_leveldebug然后按Ctrlx启动。这样你能直接看到 stop 到哪一步是挂在[ OK ] Started...还是[FAILED] Failed to start...一眼定位。固件模式不匹配也比较隐蔽。有的 Kali 镜像安装时用了 UEFI但虚拟机配置里固件设置成 BIOS或者反过来。VMware 里在“虚拟机设置 - 选项 - 高级 - 固件类型”里可以改KVM 里要改bootloader相关配置。判断方法很简单启动时如果出现Boot failed: Not a bootable disk或者卡在EFI Shell多半就是固件模式不对。这种情况虚拟机进程也在 running但系统根本没引导起来。3.5 网络和 SSH 服务压根没起来还有一种“running 失败”是指 SSH 连接失败。管理面板显示虚拟机 running但你用终端连不上 22 端口。这不一定代表 Kali 没启动可能是 SSH 服务没启用或者网络配置有问题。进入虚拟机控制台后执行systemctl status ssh systemctl status NetworkManager ip a如果ssh显示 inactive 或 failed先启用sudo systemctl enable --now ssh如果NetworkManager没起来手动拉起然后ip a看网卡有没有拿到地址。另一个坑是 Kali 新版本默认关闭 root 远程登录sshd_config里PermitRootLogin可能是prohibit-password。如果你非要用 root 远程登需要改成yes再重启 ssh。但更推荐的还是先建一个普通用户来连。4. 两个真实案例的完整排查过程我不想只给你讲理论下面是两段我实际处理过的过程命令和配置都是可以直接照抄的。4.1 案例一VMware Workstation 里 Kali 黑屏状态却显示“正在运行”场景很典型Windows 宿主机的 VMware Workstation Pro 里装了 Kali某天启动后控制台全黑但虚拟机列表里状态一直是“正在运行”。客人机里有没有系统SSH 连不上鼠标也看不到。我第一步先看 VMware 的vmware.loggrep -i svga\|panic\|failed vmware.log日志里没有明显的 panic但看到了几行 SVGALib 相关的提示。我判断问题出在显示适配器于是把虚拟机的 3D 加速关掉虚拟机设置 - 显示器 - 取消“加速 3D 图形”显存改为 128MB。然后进 GRUB 去掉quiet splash并额外加了nomodeset。因为 3D 加速关闭后内核自带的 DRM 驱动可能还会尝试模式切换而 SVGA 在nomodeset下能更稳定地输出到控制台。重启后Kali 直接出图形登录界面。之后我又把 3D 加速重新打开确认是 3D 加速与当前内核的vmwgfx驱动冲突。这不代表 3D 加速永远不能用而是说明你的 Kali 内核版本和 VMware 的 SVGA 驱动不匹配要么升级 VMware要么降级内核要么就保持关闭。4.2 案例二libvirt 里“running”但 VNC 黑屏、SSH 连不上另一个场景是 KVM 宿主机上跑 Kalivirsh list --all显示 running但virt-manager的 VNC 画面黑屏SSH 也连不上。我用串口查看发现内核其实启动到了登录界面只是 VNC 视频输出没生效。执行sudo virsh edit kali找到video配置段把显卡模型从qxl改成virtiovideo model typevirtio heads1 ram16384 vgamem16384 / /video然后sudo virsh destroy kali再sudo virsh start kali。注意改虚拟机硬件配置后最好 destroy 再 start而不是在 guest 里直接重启否则部分设备模型不会重新加载。同时我注意到systemctl status ssh是 failed原因是 Kali 的/etc/ssh/sshd_config里有重复配置导致 sshd 拒绝启动。把重复的ListenAddress注释掉后systemctl restart ssh就能正常连接了。这个案例最大的启发是SSH 连不上和 VNC 黑屏看起来像两个大问题但其实是两个小问题叠加。逐个日志排查后十几分钟就解决了。5. 常见问题速查表与避坑建议最后整理一个速查表遇到相似症状可以直接对应处理不用从头看日志。症状可能根因优先检查/处理控制台黑屏但虚拟机面板显示 running显卡驱动/3D 加速冲突关闭 3D 加速显卡改为 SVGA 或 virtio加nomodeset串口/内核日志停在Loading initial ramdiskinitramfs 损坏或磁盘空间不足Live CD 修复 initramfs或扩大磁盘VMware 打开虚拟机直接报无法连接Hyper-V/内核隔离冲突关闭 Hyper-V、内存完整性重启KVM 中virsh list显示 running但virsh console无输出串口未启用或未配置参数在 GRUB 加consolettyS0,115200n8SSH 连不上控制台能用ssh 未启用/sshd_config 错误systemctl enable --now ssh检查配置卡在登录界面循环LightDM/Xorg 崩溃看/var/log/Xorg.0.log切换显示管理器开机后磁盘满系统只读动态磁盘用尽清理 扩容df -h确认虚拟机状态反复 running/paused宿主机内存不足增加宿主机内存或减少 VM 内存有几个避坑心得必须说第一不要反复硬重启虚拟机。很多人在 Kali 卡死时直接点“重置”这非常容易让 ext4 文件系统损坏。正确做法是先用串口或日志定位问题实在不行就挂载 Live CD 去 fsck别拿虚拟机当物理机硬搞。第二改 VMX 或 XML 配置前先备份。VMware 的 VMX 文件只有几 KB但里面任何一行错误都可能导致虚拟机起不来。KVM 的 XML 也是同理改之前用virsh dumpxml kali kali.xml.bak存一份出问题能秒回滚。第三不要追求最新内核。Kali 是滚动发行版内核更新很频繁新内核在虚拟化环境下偶尔会有驱动回退问题。如果你的 Kali 之前跑得好好的某次升级后突然 active/running 但进不了桌面优先检查/var/log/apt/history.log回退到旧内核往往比花几个小时排查驱动更简单。第四善用“最小启动”。隐藏变量永远是排错的大敌。把虚拟机裁剪到只剩 CPU、内存、网卡、显卡反复做加减法比一次性开十几项虚拟硬件然后一起猜要高效得多。再补充一个非常实用的习惯所有的虚拟机日志我都会单独建一个目录存起来文件名按日期写到。因为这类运行状态问题经常不是一次性故障而是系统升级后再次出现。有历史日志对照你能很清楚地看到是哪次升级、哪个配置变更导致了崩溃。这比每次重新排查要省几倍时间。我个人在实际排查这类问题时的体会是active和running这两个状态只是“指路牌”它们告诉我们虚拟机的进程还活着但真正的故障藏在系统日志的细节里。记住不要相信状态图标要相信控制台输出和系统日志。按上面这套方法绝大多数 Kali 虚拟机“active 中 running 失败”的问题都能在两小时内解决而且下次再遇到你一定能比第一次快得多。
阅读完成 · 觉得有帮助？
