解决VM虚拟机卡成PPT的问题！

Hashan
326 阅读5分钟

前言
公司内部安排一个任务
任务听起来很简单：抓一台办公电脑，“逼”它兼职当个局域网小服务器。

计划很美好：装个VM，塞个Linux进去，搞定！

现实很骨感：

  • 安装Linux？VM直接表演“思想放空”——卡住！仿佛在说：“今天不想上班。”
  • 历经九九八十一难（重启N次），好不容易装好了...
  • 敲个命令？Linux也学起了葛优躺——卡！卡！卡！比树懒还悠闲。

内心OS：  我是谁？我在哪？这玩意儿是服务器还是老爷车？！😤

 烦死了！必须解决它！（抄起键盘，准备战斗💻⚔️）

解决方案 一

关闭windows的Hyper-V服务

image.png

image.png

image.png

解决方案 二

上面的操作无法解决此问题，那么继续操作方案二！

image.png

image.png

image.png

image.png

5.设置Hyper-V服务 为关闭状态。 windows 命令行 开启\关闭 虚拟化Hyper-V 以管理员身份打开终端 运行命令

开启：bcdedit /set hypervisorlaunchtype auto 然后重启
关闭：bcdedit /set hypervisorlaunchtype off 然后重启

源文章： VMware虚拟机经常性卡死，打开运行一段时间后卡死，CPU占比增至100% - MXT16 - 博客园

正片开始

使用Deepseek，理解原理

为什么Hyper-V服务开启，影响虚拟机呢？

  1. Hyper-V 改变了 Windows 的运行模式：

    • 当 Hyper-V 启用时，即使你没有创建任何 Hyper-V 虚拟机，Windows 操作系统本身也会变成一个运行在 Hyper-V 根分区上的特殊虚拟机。这意味着 Windows 不再是直接运行在物理硬件（裸机）上。
    • Hyper-V 作为 Type-1 Hypervisor (裸机管理程序)  接管了硬件资源的管理权（CPU、内存、I/O设备等）。所有操作系统（包括宿主 Windows 本身）都必须通过 Hyper-V 层才能访问硬件。

  2. 其他虚拟机软件 (VMware Workstation, VirtualBox) 是 Type-2 Hypervisor (宿主型管理程序)：

    • 这些软件设计初衷是运行在一个标准的操作系统（如 Windows）之上，由宿主操作系统负责直接管理硬件。
    • 它们依赖于宿主操作系统提供的硬件访问接口（如 CPU 虚拟化指令 VT-x/AMD-V）来高效运行虚拟机。

  3. 冲突的核心：硬件虚拟化资源的竞争

    • CPU 虚拟化指令 (VT-x/AMD-V)： 现代 CPU 提供硬件辅助虚拟化指令集（Intel VT-x, AMD-V），这是高效运行虚拟机的关键。当 Hyper-V 启用时，它独占了这些硬件虚拟化功能。VMware/VirtualBox 等软件就无法直接、完全地访问这些硬件加速功能。

    • 结果：  其他虚拟机软件被迫在以下两种低效模式下运行：

      • 软件模拟 (Emulation)：  不使用硬件加速，完全用软件模拟 CPU 指令，速度非常慢。

      • 兼容模式 (如 VMware 的 “Hypervisor 平台” 兼容模式 / VirtualBox 的 Hyper-V 后端)：  这是一种妥协方案。VMware/VirtualBox 的虚拟机不是直接运行在物理硬件上，而是运行在 Hyper-V 创建的子分区中。这就形成了嵌套虚拟化：

        • 物理硬件 -> Hyper-V (Type-1) -> 宿主 Windows (根分区) -> VMware Workstation (Type-2) -> 客户机操作系统。
        • 或者更直接地：物理硬件 -> Hyper-V (Type-1) -> VMware Workstation 的虚拟机 (作为 Hyper-V 的子分区)。

  4. 嵌套虚拟化带来的性能损失：

    • 额外的抽象层：  每次硬件访问（CPU指令、内存读写、磁盘I/O、网络I/O、显卡操作）都需要经过更多的软件层（VMware/VirtualBox 层 + Hyper-V 层）进行转换和处理，增加了开销。
    • 上下文切换：  CPU 需要在宿主 OS、Hyper-V、VMware/VirtualBox 进程、客户机 OS 之间进行更频繁、更复杂的上下文切换，消耗 CPU 时间。
    • 内存开销：  管理两层虚拟化需要更多的内存开销（影子页表、额外缓冲区等）。
    • I/O 延迟：  磁盘和网络访问需要经过多层虚拟化驱动，路径变长，延迟显著增加，吞吐量下降。这是卡顿感的重要来源之一。
    • CPU 调度复杂性：  Hyper-V 和 VMware 都有自己的 CPU 调度器，嵌套运行时调度策略可能冲突或不协调，导致客户机 CPU 响应不及时。
    • 显卡性能损失：  3D 加速和视频性能受影响最大。原本可以通过 VMware SVGA / VirtualBox Guest Additions 获得接近原生的图形性能，但在 Hyper-V 之上运行时，图形指令需要经过更长的路径，性能大幅下降，导致界面卡顿、视频播放不流畅、3D 应用几乎不可用。
    • 中断处理：  硬件中断需要经过更多层的处理和路由，效率降低。

  5. 资源争用：

    • Hyper-V 本身会占用一定的系统资源（CPU、内存），即使没有运行任何 Hyper-V 虚拟机。
    • 宿主 Windows 运行在 Hyper-V 之上，本身也会有一点性能损耗。
    • 这些都会导致可供 VMware/VirtualBox 及其虚拟机使用的物理资源相对减少。

总结

  1. Hyper-V 抢位置：  它启动后，Windows 自己都变成了它管理的“虚拟机”。
  2. 硬件加速被独占：  Hyper-V 独占了让虚拟机跑得快的 CPU 硬件加速功能。
  3. 其他虚拟机被迫“绕路”：  VMware/VirtualBox 无法直接走“快车道”，只能走效率低下的“慢车道”（软件模拟或套娃式虚拟化），导致卡顿。
avatar
文章
阅读
粉丝