KVM虚拟化实战：从硬件检查到部署运维全指南

接上次的话题，继续把 KVM 虚拟化这块聊透。上一篇主要讲了 KVM 的基本原理和安装前的准备，这一篇我打算直接上手，把从零搭建一套完整 KVM 虚拟化环境的全过程、中间踩过的坑、以及几个高频故障的处理思路全部捋一遍。

先说清楚这篇适合谁。如果你手里有台物理服务器或者一台配置还不错的 x86 台式机，想把它变成一台能同时跑 Windows、Linux 等多套系统的宿主机；或者你是在国产化环境下用麒麟 v10 ARM 版，被 KVM 安装折腾得够呛；又或者你在用 VMware Workstation 时遇到“此平台不支持虚拟化的 Intel VT-x/AMD-V”这类嵌套虚拟化报错——这篇的内容都会对你有帮助。

KVM 给人的第一印象往往是“命令行为主、门槛高”，但实际上现在 KVM 的生态已经非常成熟，配合 libvirt 和 virt-manager，很多操作完全可以图形化完成。这篇不会只给你贴一堆命令，我会把每一步背后的原理讲明白，比如为什么要做桥接网卡、为什么 CPU 直通要谨慎、ARM 平台和 x86 平台的差异点在哪里。这样下次你自己遇到新问题，也能顺着思路去排查，而不是遇到报错就到处搜。

1. 动手前的硬件体检：CPU虚拟化到底开了没

1.1 为什么KVM必须依赖硬件虚拟化

很多人装 KVM 失败，第一步就栽在一个非常基础的问题上：CPU 的虚拟化功能根本没有开启。KVM 全称是 Kernel-based Virtual Machine，它和纯软件模拟方案（如 QEMU 的 TCG 模式）不同，KVM 直接利用 CPU 提供的硬件虚拟化扩展指令集。x86 平台上就是 Intel 的 VT-x 和 AMD 的 AMD-V，ARM 平台上是 ARMv8 的 Virtualization Extensions。

如果没有这些硬件指令集，KVM 模块根本无法加载，因为虚拟机的特权指令执行、内存虚拟化（EPT/NPT）都需要硬件配合。有人问过“KVM 能不能像 VirtualBox 那样纯软件跑”，答案是不行，KVM 从设计上就是硬件虚拟化方案。所以第一步永远是确认 CPU 虚拟化功能已经开启，而不是急着安装软件包。

1.2 三分钟检查宿主机虚拟化支持状态

在 Linux 系统下，检查方法有很多，我给三个最常用的，从简到繁：

bash复制# 方法一：查看 /proc/cpuinfo 中的标志位
grep -E "(vmx|svm)" /proc/cpuinfo

# 方法二：使用 kvm-ok 工具（在 cpu-checker 包里）
sudo apt install cpu-checker -y
sudo kvm-ok

# 方法三：使用 libvirt 自带的诊断工具
sudo virt-host-validate

方法一里，vmx 是 Intel 的虚拟化标志位，svm 是 AMD 的。如果 grep 结果为空，说明 CPU 虚拟化功能没有在 BIOS/UEFI 中开启，或者 CPU 本身不支持。方法三的 virt-host-validate 更全面，它不光检查 CPU 虚拟化，还会检查 KVM 模块是否加载、IOMMU 是否开启、嵌套虚拟化是否可用等，信息很全，建议第一次部署时先跑一遍。

如果确认 BIOS 里已经开启 VT-x/AMD-V，但 grep 查不到标志位，那大概率是虚拟机嵌套虚拟化的问题，这个我在后面第 4 节单独讲。

1.3 服务器环境与品牌机 BIOS 的开启差异

这里要提醒一下，家用主板和服务器主板的虚拟化开关位置差异很大。家用主板一般叫 “Intel Virtualization Technology”、“SVM Mode”，在 Advanced/CPU Configuration 下面。但服务器平台不一样，比如戴尔的 PowerEdge 服务器，VT-x 相关的选项在 System BIOS -> Processor Settings 下，叫 “Virtualization Technology”；惠普的服务器则在 Advanced -> Processor Options 里。

有次我在一台服务器上无论如何都开启不了虚拟化，后来发现是 BIOS 版本太旧，刷新固件后选项才出现。如果你在 BIOS 里找不到虚拟化开关，排查顺序是：确认 CPU 型号是否支持 -> 检查 BIOS 版本是否有已知问题 -> 确认是不是在物理机上而不是虚拟机里（服务器本身的虚拟化功能被占用了）。

注意：检查完后记得确认 KVM 内核模块是否加载成功，lsmod | grep kvm，如果看到 kvm_intel 或 kvm_amd 就说明模块没问题。如果加载失败，查看 dmesg | tail 的输出，大部分情况会直接告诉你原因。

2. 从零到一：Ubuntu 22.04 下的 KVM 完整部署

2.1 软件包选型与 libvirt 的架构定位

这一部分以 Ubuntu 22.04 为例。安装 KVM 虚拟化栈时，很多人只知道装 qemu-kvm，结果装完发现不对劲——没有一个统一的管理入口，虚拟机创建、销毁全要手动敲 qemu-system-x86_64 命令。这其实是因为现代 KVM 的架构里，QEMU 只是底层模拟器，真正方便的上层管理靠的是 libvirt。

libvirt 是一套虚拟化管理 API，它统一管理 KVM、Xen、QEMU、LXC 等多种虚拟化方案的虚拟机生命周期。virt-manager 是它的图形化前端，virsh 是命令行前端。三者关系你可以简单理解成：KVM 是引擎，libvirt 是变速箱和控制系统，virt-manager/virsh 是你手里的方向盘。没有 libvirt，KVM 也能跑，但操作体验会退化到石器时代。

所以在 Ubuntu 22.04 上，我推荐下面这套安装组合：

bash复制sudo apt update
sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst virt-manager -y

逐个解释一下这些包的作用：qemu-kvm 提供底层模拟器；libvirt-daemon-system 负责把 libvirtd 服务注册为系统服务；libvirt-clients 提供 virsh 等客户端工具；bridge-utils 提供网桥管理工具 brctl，做桥接网络时要用；virtinst 提供 virt-install 命令行安装虚拟机的工具；virt-manager 是图形化管理界面。

2.2 启动服务与用户权限的坑

装完后，第一件事是启动 libvirtd 服务并设为开机自启：

bash复制sudo systemctl enable --now libvirtd
sudo systemctl status libvirtd

但这里有个新手极容易踩的坑：直接用 virsh list 会报 “failed to connect to the hypervisor” 或者 “Permission denied”。这不是服务没启动，而是当前用户不在 libvirt 或 kvm 用户组里。libvirtd 默认对 socket 文件有权限控制，普通用户没有访问权限。

解决办法是把自己的用户加入相关用户组，然后重新登录：

bash复制sudo usermod -aG libvirt $USER
sudo usermod -aG kvm $USER
# 重新登录或执行 newgrp libvirt
newgrp libvirt

我见过有人因为没做这一步，跑去改 /etc/libvirt/libvirtd.conf 的 unix_sock_group 和 unix_sock_rw_perms，其实默认配置就是合理的，加入用户组就够用了。改配置反而容易把权限搞乱。

2.3 快速验证：用 virsh 创建第一个虚拟机

为了验证整套环境是否正常，我建议先创建一台不需要安装系统的小虚拟机测试一下。用 virt-install 可以做到：

bash复制sudo virt-install \
  --name test-vm \
  --memory 1024 \
  --vcpus 1 \
  --disk size=5 \
  --cdrom /dev/null \
  --os-variant ubuntu22.04 \
  --boot hd \
  --import

这段命令的意思是：创建一个 1GB 内存、1 核 CPU、5GB 磁盘、从硬盘启动且不挂载安装介质的虚拟机。核心参数都很直白，--import 表示不安装系统，直接导入现有磁盘。如果命令执行后虚拟机成功启动（虽然会因为没有系统而引导失败，但虚拟机创建和运行机制没问题），说明 KVM 环境是通的。

--os-variant 参数建议每次创建时都指定，它决定了虚拟机的 ACPI 表、虚拟硬件配置细节，对 Windows 等系统尤其重要。记不住系统变体名字可以用 osinfo-query os 查询。

3. 网络是灵魂：桥接模式与默认 NAT 的取舍

3.1 默认的 virbr0 NAT 网络有什么局限

libvirt 安装完成后，默认会创建一个叫 virbr0 的虚拟网桥，虚拟机通过这个网桥走 NAT 方式上网。用 ip addr show virbr0 能看到它的 IP 一般是 192.168.122.1。

NAT 模式对于测试环境完全够用，虚拟机可以访问外网，但外面的机器访问不到虚拟机。这在很多场景下很尴尬：比如你在虚拟机里搭了一个 Web 服务，想从局域网里另一台电脑访问，NAT 模式下做不到，除非做端口转发。做端口转发又涉及使用 iptables 规则操作宿主机上的 INPUT 链，比较麻烦，而且宿主机重启后规则可能丢失。

3.2 桌面板宿主机如何用 bridge-utils 配置桥接网卡

如果你的宿主机是 Linux 桌面系统，配置桥接的经典方法是自己建一个桥，然后物理网卡接入桥内。这里给一个基于 netplan 的配置方案（Ubuntu 22.04 默认使用 netplan，配置文件在 /etc/netplan/ 下）。

首先看一下当前网卡名称，假设是 enp3s0，然后编辑 /etc/netplan/ 下的 yaml 文件：

yaml复制network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
      dhcp6: false
  bridges:
    br0:
      interfaces: [enp3s0]
      dhcp4: true
      dhcp6: true

然后执行 sudo netplan apply。这里要特别提醒：如果你是通过 SSH 远程操作服务器，用 netplan 配置桥接时一定要小心，一旦配置错误可能直接断网。稳妥的做法是先在本地控制台或者带外管理（IPMI/iDRAC/iLO）里操作，或者准备一个 cron 脚本定时回滚配置。

服务器场景建议用 /etc/network/interfaces 方式（ifupdown），配置逻辑一样但管理方式不同。无论用哪种，核心都是：物理网卡不再配置 IP，IP 配置到网桥接口上，虚拟机虚拟网卡直接挂到网桥上，这样虚拟机和宿主机就在同一个二层网络中，可以获得局域网内的 IP。

3.3 virt-manager 中手动添加桥接网卡的实操

图形化工具 virt-manager 中，创建虚拟机时网络选择默认是 “NAT”。如果你已经建好了 br0 网桥，在虚拟机的 NIC 设置里，把 “Network source” 改为 “Bridge device”，然后在下面的下拉框里选 br0 即可。

连接方式里还有一个选项是 “Host device” 直通物理网卡，这种模式下虚拟机直接独占一张物理网卡。它的性能和隔离性最好，但一张网卡只能同时被一台虚拟机使用。宿主机有多个物理网卡时，可以把其中一个直通给对网络性能要求高的虚拟机。

提示：不管用哪种方式，创建完虚拟机后都要进虚拟机里确认 IP 是否正常获取。如果用的是桥接模式但虚拟机拿不到 IP，优先排查宿主机上的 br0 是否正常工作，再看虚拟机网卡驱动是否识别。很多情况下是虚拟机的系统镜像里缺少 virtio 驱动，导致网卡设备无法识别。

4. 两个典型场景：ARM 国产化平台与嵌套虚拟化

4.1 麒麟 v10 ARM 版安装 KVM 的差异点

这两年国产化平台在政府、国企、教育行业用得很多，点名率最高的是麒麟 v10 的 ARM 版（主要是飞腾、鲲鹏平台）。在 ARM 平台上装 KVM，整体思路和 x86 差不多，但有几个明显的差异必须知道。

第一，软件包的名称和架构不同。ARM 平台上的 QEMU 包提供的是 aarch64 的模拟器，安装时命令基本一样：

bash复制sudo yum install qemu-kvm libvirt virt-install virt-manager

第二，ARM 平台里的虚拟机只能装 ARM 架构的系统（aarch64），不能像 x86 的 QEMU 那样通过 TCG 模拟 x86 客户机。这是因为 KVM 是硬件辅助虚拟化，虚拟机的 CPU 指令集必须和物理 CPU 保持一致。想在一台 ARM 服务器上跑 x86 的 Windows 系统，KVM 做不到（除非用纯软件模拟，但性能会差到不可用）。

第三，ARM 平台的虚拟化扩展（Virtualization Extensions）是 ARMv8 标准的一部分，但具体支持程度取决于 CPU 型号和固件。检查命令在 ARM 上同样可以用 grep -E "(virt)" /proc/cpuinfo，看到 virt 标志位说明硬件虚拟化已开启。

注意：麒麟 v10 是基于 openEuler 还是 CentOS 的系统，包管理器是 yum/dnf，不是 apt。网上很多 Ubuntu 的 KVM 教程在麒麟上直接就是无效的，至少安装命令全军覆没。一定先确认系统发行版和包管理器，再找对应教程。

4.2 嵌套虚拟化：在 VMware/KVM 里再开 KVM 的排查思路

“此平台不支持虚拟化的 Intel VT-x/AMD-V”是我这次在热搜里看到出现频率最高的报错。这个问题通常出现在：你在一台虚拟机里（比如 VMware Workstation 的虚拟机里）再安装 KVM 或再开嵌套虚拟化功能。

嵌套虚拟化的原理是：外层虚拟机监控器（Hypervisor）需要把 CPU 的虚拟化标志位透传给内层虚拟机。VMware Workstation 中开启方式是选中虚拟机 -> 虚拟机设置 -> 处理器 -> 勾选 “虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”。KVM 中嵌套虚拟化则需要检查内核模块参数：

bash复制# 确认当前是否启用嵌套虚拟化
cat /sys/module/kvm_intel/parameters/nested
# 如果返回 N，需要启用
echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm_intel.conf
sudo modprobe -r kvm_intel
sudo modprobe kvm_intel

注意 modprobe -r kvm_intel 会卸载模块，如果有正在运行的虚拟机会直接退出，所以只能在没有运行虚拟机的时候操作。另外 Windows 宿主机上玩 WSL2 时报 “请确保计算机固件设置中虚拟机平台已启用”，本质上也是同一类问题——在物理机上需要开启 BIOS 虚拟化，在虚拟机里需要在 Hyper-V 或 VMware/KVM 里开启嵌套虚拟化。

4.3 Windows 与 Linux 双视角：Win11 的 VBS 对 KVM 的影响

一个和嵌套虚拟化强相关的点：Windows 11 默认开启的基于虚拟化的安全（VBS，Virtualization-Based Security），它内部也使用 Hyper-V 作为基础，会占用虚拟化资源。你在 Windows 11 宿主机上跑 VMware Workstation，如果 VBS 没关，VMware 可能会报 VT-x 不可用或者嵌套虚拟化不支持。

解决办法是在“Windows 安全中心 -> 设备安全性 -> 内核隔离”里关闭内存完整性，或者通过注册表关闭 VBS：

powershell复制# 管理员权限执行
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f

这一点对很多想在 Windows 上折腾 KVM 虚拟机的人来说是个坑。我建议在 Windows 上折腾虚拟化时，先确认自己的场景是“纯测试”还是“生产使用”。纯测试用 VMware Workstation + 客户机里跑嵌套 KVM 足够了；但如果要在 Windows 上跑正式的 Linux 虚拟机，WSL2 或者 Hyper-V 可能是更合适的选择，没必要强行用 KVM。

5. 虚拟机创建进阶：virt-install 参数详解与配置示例

5.1 CPU 与内存：为什么不能无脑给满

创建 Windows 虚拟机时，很多人习惯性把 CPU 核心数和内存拉满，比如 16 核 vCPU、32GB 内存全给客户机。这是不推荐的。KVM 中 CPU 分配有两种模式：--vcpus 4 表示拓扑上 4 个 vCPU，宿主机调度器会把这 4 个 vCPU 映射到物理 CPU 上；--vcpus 4,maxvcpus=8 则允许之后热插拔。但你分配给虚拟机的内存和 CPU 越多，宿主机资源越紧张，特别是在跑多台虚拟机时，超额分配会导致 CPU 等待和内存交换。

我自己的经验是：Web 服务器类虚拟机给 1~2 核、1~2GB 内存就够用了；数据库类给 4 核、8GB 起步；Windows 桌面系统至少给 2 核、4GB 内存才流畅。可以先给一个下限值，跑起来后通过 virsh setvcpus 和 virsh setmem 动态调整（需要客户机支持热插拔和内存热添加）。

5.2 存储后端：qcow2 与 raw 的区别和选择

磁盘格式的选择很容易被忽略，但它直接影响性能和磁盘占用。raw 格式镜像就是完整的裸磁盘文件，性能最好，但占用的空间和虚拟磁盘大小一致，无法做快照（或者说快照支持不友好）。qcow2 格式支持稀疏文件分配（用多少占多少）、快照、压缩、AES 加密等特性，日常使用推荐优先选 qcow2。

virt-install 创建磁盘时默认就是 qcow2：

bash复制sudo virt-install \
  --name vm-win11 \
  --memory 8192 \
  --vcpus 4 \
  --disk path=/var/lib/libvirt/images/vm-win11.qcow2,size=100,format=qcow2,sparse=true \
  --os-variant win11 \
  --cdrom /path/to/win11.iso \
  --network bridge=br0,model=virtio \
  --graphics vnc,listen=0.0.0.0 \
  --noautoconsole

这里 path 指定镜像位置，size 是磁盘容量（GB），sparse=true 表示使用稀疏分配，model=virtio 指定网卡模型为 virtio。注意 Windows 系统安装时默认没有 virtio 驱动，你需要额外挂载 virtio-win 驱动镜像，否则安装时看不到磁盘和网卡。这是个非常容易卡住的点，我在第 6 节会详细讲。

5.3 图形化安装 Windows 虚拟机时的常见坑

用 --graphics vnc 启动后，可以用 VNC 客户端连接虚拟机进行安装。注意 listen=0.0.0.0 是让 VNC 监听所有网卡，生产环境慎用，因为 VNC 默认没有加密，相当于裸奔在网络上。更稳妥的方式是：

bash复制# 通过 virsh 查看 VNC 端口
sudo virsh vncdisplay vm-win11

这个命令会输出类似 :0 的端口号，对应的 TCP 端口是 5900 + 端口号，所以 :0 就是 5900。之后用 VNC 客户端连接 宿主机IP:5900 即可。本地桌面环境直接敲 virt-manager 打开图形界面操作会更直观。

安装系统的过程没什么可说的，进去按 Windows 安装向导走就行。真正的问题出现在 Windows 安装程序找不到任何磁盘的那一步——这是因为磁盘控制器默认是 virtio，Windows 安装镜像里没有内置 virtio 驱动。

解决办法是到 Fedora 官网下载 virtio-win 驱动 ISO（virtio-win.iso），在 virt-manager 中把光驱指向这个 ISO，然后在 Windows 安装界面里选择“加载驱动程序”，加载 virtio 的 vioscsi 或 viostor 驱动，磁盘就能识别出来了。这一步几乎是所有 Windows-on-KVM 新手必经的坑，提前准备好能省不少事。

6. 日常运维与性能调优的实战经验

6.1 virsh 常用命令与快照管理

创建好虚拟机后，你主要的操作入口就是 virsh 了。这里整理一份我平时用得最多的命令清单：

bash复制# 查看所有虚拟机状态
sudo virsh list --all

# 启动/关闭/强制关闭虚拟机
sudo virsh start vm-name
sudo virsh shutdown vm-name   # 发送 ACPI 关机信号
sudo virsh destroy vm-name    # 强制断电

# 设置开机自启（物理机开机后自动启动虚拟机）
sudo virsh autostart vm-name

# 创建快照（qcow2 格式支持）
sudo virsh snapshot-create-as vm-name snap1 "first snapshot"

# 还原快照
sudo virsh snapshot-revert vm-name snap1

# 查看虚拟机 VNC 显示端口
sudo virsh vncdisplay vm-name

# 编辑虚拟机 XML 配置
sudo virsh edit vm-name

快照功能是 qcow2 格式一个非常实用的特性。执行系统更新或安装重大软件前，先打个快照，出问题了直接还原，比什么备份方案都省事。virsh snapshot-create-as 创建快照时建议加上描述信息，方便识别。注意：raw 格式磁盘不支持这种简单位置的快照，得用 qemu-img 做外部快照，复杂度高不少。

6.2 性能调优：virtio 全线驱动与 CPU 调优

给 Linux 虚拟机装 virtio 驱动一般内核已经内置，但 Windows 虚拟机必须手动安装 virtio-win。装完后，磁盘控制器、网卡、显卡、内存气球驱动都能用上 virtio 模式，性能提升巨大——尤其是磁盘 IO，virtio-blk 比 IDE 模拟模式能快出好几倍。

CPU 调优方面，宿主机在虚拟机里输命令时经常听到一个概念叫 “CPU 限制”。默认情况下，KVM 会根据 vCPU 数量平均分配宿主机 CPU 时间，但如果你希望某台虚拟机有更强的计算优先级，可以用：

bash复制# 调整虚拟机 CPU 调度优先级（-1 为最高优先级）
sudo virsh schedinfo vm-name --set vcpu_period=100000 --set vcpu_quota=90000

vcpu_period 和 vcpu_quota 的含义可以理解为一个时间窗口内的 CPU 使用配额。100000 微秒（100ms）周期内，配额 90000 微秒意味着虚拟机最多使用 90% 的 CPU 时间。这个参数对控制多台虚拟机之间的资源抢占很直观，但一般场景下默认值已经够用，不用刻意调整。

6.3 性能监控：怎么判断宿主机是否超卖

KVM 的一个优势是允许 CPU 和内存超卖（overcommitment），也就是说所有虚拟机分配的 vCPU 总数和内存总量可以大于物理资源。这在跑大量轻量虚拟机时效率很高，但如果控制不好，一台虚拟机的突发负载会把整台宿主机拖垮。

常用的监控命令：

bash复制# 查看宿主机整体负载
uptime
top

# 查看每个虚拟机的 CPU 使用情况
virsh vcpuinfo vm-name
virsh domstats vm-name

# 查看内存使用
virsh dommemstat vm-name
free -h

我判断超卖是否过度的标准很简单：如果宿主机 top 里 %Cpu(s) 中 wa（I/O wait）长时间超过 10%，或者虚拟机内部响应明显变慢，说明存储或 CPU 已经吃紧，需要减少虚拟机数量或增加物理资源。另外用 virsh dommemstat 能看到每个虚拟机的实际内存使用量，如果大量虚拟机都在大量使用内存，注意宿主机 swap 使用情况。

7. 常见问题与排查技巧实录

7.1 启动报错模块“hv”启动失败

这个报错在 VMware 的嵌套虚拟化场景里很常见。完整报错是 “VMware Workstation 在此主机上不支持嵌套虚拟化。模块‘hv’启动失败。”出现这个报错时，说明你正在 VMware 的虚拟机里尝试开启 Hyper-V 或嵌套虚拟化。

排查方向有三步：第一，确认虚拟机设置里是否勾选了 CPU 的虚拟化选项（VT-x/AMD-V 透传）；第二，确认宿主机 Windows 的 Hyper-V 和 VBS 是否启用了，如果启用了，VMware Workstation 会优先使用 Hyper-V 的 API 而非原生 VT-x，导致嵌套虚拟化的行为改变；第三，如果前两步都没问题，试试在 VMware 虚拟机的 .vmx 文件里添加 vhv.enable = "TRUE" 来显式开启嵌套虚拟化。

7.2 虚拟机磁盘 IO 性能差，宿主机 CPU 也不涨

这个问题我遇到过很多次。表现是虚拟机里拷文件速度慢得离谱，但宿主机 CPU 占用率很低。大多数情况下是磁盘驱动没走 virtio，虚拟机还在用 IDE 模拟模式。Linux 虚拟机可以通过 lsblk -d -o name,trans 查看传输类型，看到 sata 或 ide 说明驱动没对。

修正是修改虚拟机 XML 中磁盘的 bus 属性，把 ide 或 sata 改成 virtio，或者直接在 virt-manager 的磁盘设置里改总线类型，改完后重启虚拟机生效。修改前要先确认 virtio 驱动已经可用，否则虚拟机会启动失败。

7.3 宿主机重启后虚拟机没有自动启动

这个属于配置遗漏。KVM 虚拟机的自动启动不是默认开启的，需要在创建后手动设置 virsh autostart vm-name。有一个容易误解的点：virsh autostart 只是让 libvirtd 启动时自动引导该虚拟机，并不代表虚拟机会在系统启动早期就运行。它依赖 libvirtd 服务正常启动后才开始。如果你用 netplan 配置网络时设置的是 “critical” 而不是 “best-effort”，网络服务启动失败可能导致 libvirtd 启动失败，进而虚拟机全部没起来。

提示：所有 KVM 运维操作尽量在 libvirtd 服务健康的情况下进行。遇到奇怪问题先看 systemctl status libvirtd 和 journalctl -u libvirtd -f，日志会给你明确的线索，比自己瞎猜高效得多。

7.4 网上很多教程说到 “去虚拟化” 是什么？

热搜词里出现 “vmware 25h2 去虚拟化文件下载” 这类词，我简单说一句：所谓“去虚拟化”通常是指在虚拟机里伪装硬件信息，让客户机检测不到自己是虚拟机。这类需求大多出现在跑某些对虚拟机环境敏感的软件时。但我不建议在这上面投入太多精力，一方面它涉及灰色用途，另一方面 KVM/VMware 本身已经提供了硬件直通、嵌套虚拟化等正规方案来解决大部分性能或兼容性问题。真正需要“去虚拟化”的场景少之又少。

附：Debian/Ubuntu 大版本差异与 KVM 兼容性速查

不同发行版对 KVM 的默认配置差异很大。我日常用的最多的是 Ubuntu 22.04 和 Debian 12，做一个简单的对比表方便你参考：

Debian 12 上唯一需要注意的坑是，装完 libvirt 后默认的 unix socket 权限组可能是 libvirt 而不是 libvirt-qemu，如果 virsh list 不认账，先看自己用户是不是在正确组里。

几点实操中的真心话

做 KVM 虚拟化三年多，最深的体会是：KVM 本身原理不复杂，难的是思路清晰和习惯良好。比如所有虚拟机镜像集中放在 /var/lib/libvirt/images 下，定期备份关键虚拟机的 XML 配置（virsh dumpxml vm-name > vm.xml），这些看起来很小的事，在系统出问题的时候能救命。

再有就是，如果你和我一样经常在 Windows 和 Linux 之间切换环境，一开始会被每台机器的虚拟化开关位置、嵌套虚拟化配置搞得头晕。我的建议是给自己列一个 checklist：物理机装 KVM 前先看 BIOS 虚拟化开关、看内核模块、看 /proc/cpuinfo；虚拟机里装 KVM 前先看嵌套虚拟化参数、看 VMware/KVM 的虚拟化透传设置。按这个顺序排查，九成以上的“装不上”问题都能解决。

最后一个实用技巧：virt-manager 里如果觉得每个虚拟机窗口一个一个开太乱，可以直接在宿主机的终端里跑 sudo virsh console vm-name 进入串口控制台。对 Linux 虚拟机来说，这比 VNC 还轻量，响应速度更快。前提是虚拟机里配置了 ttyS0 串口终端（Ubuntu Server 默认就带）。Windows 虚拟机就没这个福分了，老老实实用 VNC 或 RDP 吧。