Ubuntu 安装 virt-manager 实战：KVM 虚拟化与排错完整指南

装完 VirtualBox 又嫌它卡顿、又想在 Ubuntu 桌面上管理多台 KVM 虚拟机的人，最后多半都会走到 virt-manager 这条路上来。我最近刚好在一台 Ubuntu 工作站上重新走了一遍完整流程，从包安装到用户组权限，再到图形界面打不开、KVM 不可用这些经典报错，踩了一圈坑之后，想把整个过程中真正会用到的东西完整记录下来，而不是只丢一句sudo apt install virt-manager就结束。这篇东西围绕的就是在 Ubuntu 上安装 virt-manager 的完整实操链路，适合那些刚接触 Linux 虚拟化、想把虚拟机管理从命令行换成图形界面的朋友，也适合装完之后遇到各种稀奇古怪报错不知道从哪里查起的人。

1. 装之前先看硬件：KVM 究竟能不能用

1.1 virt-manager 与 KVM/QEMU/libvirt 的角色分工

很多人以为 virt-manager 是一个像 VMware Workstation 一样的“虚拟机软件”，装了它就能直接开虚拟机，这是理解上的一个坎。实际上 virt-manager 只是一个图形管理前端，真正干活的是一整套虚拟化栈。我用一个不太严谨但很好记的类比来说：KVM 是内核里的虚拟化引擎，解决的是“怎么让虚拟机直接跑在 CPU 上”的问题；QEMU 是模拟器，负责模拟出 CPU、内存、网卡、磁盘等设备；libvirt 是中间层 API，把底层的 QEMU/KVM 包成一个统一的服务；而 virt-manager 只是调用 libvirt 的一个图形界面。

所以你在 Ubuntu 上安装 virt-manager 时，后续的依赖会自动把qemu-kvm、libvirt-daemon-system、virtinst这些组件一起拉进来。如果你自己手动精简了源里的包，或者用了什么轻量版系统，只装 virt-manager 一个包很可能装上之后也起不来，因为缺了 libvirtd 后台服务。

1.2 CPU 虚拟化能力和 Ubuntu 版本检查

安装前第一件事不是敲命令，而是确认这台机器的 CPU 能不能跑硬件加速。在终端里执行下面这条命令：

egrep -c '(vmx|svm)' /proc/cpuinfo

如果结果是 0，代表 CPU 的虚拟化指令集没有暴露给系统，最常见的原因是 BIOS/UEFI 里没有开启 VT-x（Intel）或 AMD-V（AMD）。但如果在虚拟机里运行这套流程，那么还要检查一下是否开启了嵌套虚拟化，否则输出同样会是 0。这条命令本身不会给你任何报错信息，输出是 0 就是最直接的信号。

另外我习惯顺手看一下 KVM 内核模块有没有被加载：

lsmod | grep kvm

输出里能看到kvm_intel或kvm_amd字样，说明内核模块在正常工作。如果什么输出都没有，先别急着去修改 BIOS，可以试着先更新一下内核模块列表并重新加载，很多桌面版 Ubuntu 默认不会自动加载 KVM 模块，重启一次通常就正常了。

Ubuntu 版本方面，我个人建议用 22.04 LTS 以上的系统，仓库里的 virt-manager 版本比较新，对 Wayland 会话的支持也更好。如果你还在用 18.04 这种老版本，apt 拉到的 virt-manager 界面会比较老，而且 libvirt 的版本也偏旧，新一些的虚拟机配置选项会缺失。那种情况下我更建议参考第三章走源码安装，或者干脆把系统升级到 LTS。

1.3 我推荐的安装组合与“最小可用”原则

以前有段时间我习惯装一个“全家桶”，把 virt-viewer、virt-install、libvirt-clients 全部手动指定安装，后来发现 Ubuntu 的依赖解析已经处理得足够好了。全新系统上，你真正常做的其实就是一条命令：

sudo apt install virt-manager

apt 会自动拉上libvirt-daemon-system、libvirt-clients、qemu-kvm、virtinst这些核心依赖，环境已经是一个“最小可用”状态了。不需要额外装virt-viewer，因为 virt-manager 本身的图形窗口就提供了控制台功能。真正需要另外补的是后面要说的 guest agent 相关组件，那是装完以后的事情，跟安装环节无关。

2. 最快路径：一条 apt 命令拉起完整的图形化虚拟机管理环境

2.1 更新索引之后直接安装 virt-manager

实际操作中不要跳过apt update，因为软件源索引过期时，你可能会遇到“Package 'virt-manager' has no installation candidate”这种很迷惑的报错，实际上就是索引太旧了。标准流程是：

sudo apt update sudo apt install virt-manager -y

安装过程中 apt 会列出即将安装的依赖包清单。很多人从来不仔细看这一屏，但我觉得值得扫一眼，因为从中能看到 libvirt 后台服务、QEMU 模拟器这些关键组件是否在列。安装完成后先别急着启动图形界面，下面两步比启动界面更重要。

2.2 把当前用户加进 kvm 和 libvirt 用户组

这是最容易在安装之后被忽略、也是最容易引起权限报错的一步。virt-manager 启动时要连接/var/run/libvirt/libvirt-sock，而这个 socket 默认只允许 root 和 libvirt 组成员访问。普通用户直接跑virt-manager，大概率会看到一个连接失败的对话框，点开详情就是权限拒绝。

把当前用户加入相关用户组：

sudo usermod -aG kvm "$USER" sudo usermod -aG libvirt "$USER"

注意，这里的$USER会展开成当前登录用户名。执行完以后必须重新登录或者重启系统，组权限才会真正生效。如果不想重启又想在当前会话里验证，可以用newgrp libvirt和newgrp kvm临时切换身份，但这条命令只影响当前终端，图形界面启动时并不会继承，所以最稳妥的做法还是重新登录。

提示：如果你发现系统里没有libvirt组，说明libvirt-daemon-system可能没有装完整，先检查 libvirtd 服务再回来处理用户组。

2.3 验证 libvirtd 服务和 socket 是否正常

安装之后先验证后台服务，这一步能帮你把问题定位在“服务没启动”还是“前端配置不对”上。执行下面两条命令：

systemctl status libvirtd sudo virsh list --all

如果服务显示未运行，先启动并设置开机自启：

sudo systemctl enable --now libvirtd

virsh list --all的输出会显示一个空的虚拟机列表，这是正常现象，说明你已经成功连接上了 libvirt。如果这里直接报错，说明问题出在 libvirtd 服务本身，而 virt-manager 图形界面启动不了只是它的连带反应。这样排查的时候，思路就比一股脑去改图形界面配置清晰很多。

2.4 从命令启动和从菜单启动的实际差异

Ubuntu 桌面版的 GNOME 应用菜单里通常能看到“Virtual Machine Manager”的图标，点开即可。但很多人更喜欢在终端里直接输入：

virt-manager

这两种方式在效果上没有本质区别，但命令启动时会输出错误信息到终端，对排查问题特别友好。尤其是连接失败、权限拒绝这类错误，GUI 里只给一句笼统的提示，终端里却能直接看到底层的报错字符串，对定位问题帮助很大。我自己的习惯是前期调试阶段全部用终端启动，确认稳定以后再回到菜单启动。

3. 更折腾的选择：源码编译安装 virt-manager 到底值不值

3.1 什么情况下你需要源码安装而不是 apt

大多数用户完全不需要源码编译。但如果你遇到下面几种情况，就不能继续依赖 apt 了。

第一种情况是源里的版本太老。Ubuntu LTS 之所以叫 LTS，反过来就意味着软件版本迭代慢，像 virt-manager 这种更新频繁的管理工具，仓库里的版本可能比上游落后一年多。如果你特别需要新版才有的功能，比如某些 virtiofs 的优化或者 CPU 热插拔改进，apt 源是给不了你的。

第二种情况是你有定制需求。比如你想改 Python 代码逻辑，自己加一个按钮、改一段存储池的默认路径，这时候源码安装就是标配工作流了。

第三种情况是你用的不是 x86 架构，比如 arm64 的开发板上某些发行版源里根本没有 virt-manager 的二进制包，就只能源码编译。

如果你不属于上面几类，我建议跳过本章，毕竟源码编译的时间成本远超一条 apt 命令。

3.2 编译前的依赖准备与 deb-src 源

编译 virt-manager 需要 meson 和 ninja 这两个构建工具，还需要一堆 Python 和 GTK 相关的开发库。最省事的准备方式是用 apt 建立构建清单：

sudo apt build-dep virt-manager

这条命令会自动读取源码包里的构建依赖声明，然后把所有编译需要的头文件和库装好。但有个前提：你的软件源里必须启用了deb-src条目。如果执行时报错说找不到源码包，去看一下/etc/apt/sources.list，把源码源打开以后再apt update一次。这一步比较麻烦，但比对着编译报错一个个装库要快得多，我试过手装依赖，装到后面已经分不清哪个包属于哪个编译阶段了。

还有一类依赖是纯 Python 的运行时依赖，比如libvirt-python和libosinfo相关的 Python 绑定，建议用系统包管理安装而不是 pip，这样可以避免 pip 把包装到/usr/local导致和系统 Python 环境冲突的情况。

3.3 meson 构建三步走与安装后的路径问题

从官方发布页面拿到对应版本的源码包，解压以后可以看到 virt-manager 新版本已经切换到了 meson 构建体系。编译安装的完整流程是：

tar -xvf virt-manager-*.tar.xz cd virt-manager-*/ meson setup build meson compile -C build sudo meson install -C build

meson setup build会在当前目录下创建一个 build 子目录，所有编译产物都会放在里面，这个设计比老式的 autotools 干净很多，不会把源码目录搞得乱七八糟。meson compile编译完以后，meson install默认把文件装到/usr/local下，而不是/usr。

这就引出一个小坑：安装完成后which virt-manager可能仍然指向旧版本的一个可执行文件，或者干脆找不到命令。如果报错，检查一下/usr/local/bin是否在 PATH 里。另外，如果系统里已经用 apt 装过 virt-manager，源码装到/usr/local后，两个版本并存，启动菜单里的图标有可能指向旧版本，这时最好先把 apt 版本卸载掉再编译安装，避免给自己制造版本混淆问题。

3.4 apt 与源码安装的取舍对比

对你个人而言，如果只是想在 Ubuntu 桌面里开几个虚拟机做实验，apt 安装就是最优解，源码安装纯粹是给自己增加工作量。但如果你想深入理解 virt-manager 的架构或者想改几行代码，源码安装反而是最快的上手方式，因为整个工程的目录结构就摊在你面前，改完重新编译即可。

4. 装完最容易踩的三个坑：权限、图形界面和虚拟机起不来

4.1 libvirt 连接被拒绝：最常见的一定是用户组没生效

装完 virt-manager 后双击图标，结果弹出对话框说无法连接 libvirt，这种错误我见了太多回。通常的报错键信息是：

Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied

这时先不要怀疑系统出了什么大问题，绝大部分情况就三种原因：用户没加入libvirt组、加入了但当前会话还没重新登录、以及 libvirtd 服务没启动。

排查顺序我也会固定走一遍。先确认服务运行：

sudo systemctl status libvirtd

再确认当前用户在组里：

groups

如果你刚执行了usermod但输出里还是没有libvirt，那就别折腾了，去重新登录一次再看。这一步已经能解决八成用户的连接问题。

还有一小撮情况是 socket 文件权限特别奇怪，这时可以直接列出 socket 的权限状态：

ls -l /var/run/libvirt/libvirt-sock

正常状态应该是srw-rw----这样，属组是libvirt。如果权限对不上，说明之前手动改过 libvirtd 的配置，或者系统里装过多个 libvirt 版本互相覆盖了。

4.2 Wayland 环境下 sudo virt-manager 报 DISPLAY 错误

很多人在权限问题的帖子下面看到别人说“sudo virt-manager 可以”，就跟着敲。在旧版 X11 环境里这招可能好使，但在 Ubuntu 默认的 Wayland 会话里踩坑的概率极高，报错通常长这样：

cannot open display: :0

原理是 Wayland 会话的安全模型禁止 root 直接访问普通用户的图形显示接口。virt-manager 这个 GUI 程序一旦用 sudo 启动，就失去了访问显示服务的许可，自然弹不出窗口。

正确的做法依然是普通用户直接执行virt-manager，遇到需要管理员权限的 libvirt 管理操作时，由 polkit 在界面里弹窗要求输入密码，而不是把整个图形程序跑在 root 身份下。如果你确实需要在 root 图形界面里做特定操作，可以用pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY virt-manager这种折中写法，但我个人实际使用中几乎没遇到过这种需求，绝大多数人完全不需要把 virt-manager 跑成 root。

4.3 新建虚拟机时提示 KVM 不可用

这个坑在使用阶段出现，但根源往往是安装阶段没检查硬件。新建虚拟机的最后一步，或者在创建向导的 CPU 配置页，可能会看到“KVM is not available”提示。这里要分三个方向排查。

第一个方向是检查/dev/kvm是否存在，以及它的属主和权限：

ls -l /dev/kvm

正常应该显示root:kvm，权限是660。如果你当前用户不在kvm组，自然没有权限使用硬件加速。这也是我在第二章里反复强调要加kvm组的原因，很多教程只提libvirt组，导致新用户建虚拟机时全卡在这一步。

第二个方向是 CPU 虚拟化开关。上面提到过用egrep -c '(vmx|svm)' /proc/cpuinfo来检查，如果输出是 0，就需要进 BIOS/UEFI 开启 VT-x 或 AMD-V。这个问题在实体机上需要重启进 BIOS 才能解决，在虚拟机里则要检查宿主机的嵌套虚拟化设置。

第三个方向是 QEMU 自身的加速配置。virt-manager 默认会通过 libvirt 选择 KVM 加速模式，但如果你在创建虚拟机时不小心把虚拟 CPU 类型设成了非 KVM 直通模式，界面会退化成纯软件模拟，能启动但特别慢，而且不会显式地告诉你 KVM 不可用。这不算 bug，但很难察觉。遇到虚拟机极慢的场景可以用下面的命令确认虚拟机的实际运行模式：

sudo virsh dumpxml 虚拟机名称 | grep -i kvm

检查 XML 里的<type>标签，正常 KVM 加速时标签内容是hvm，且 domain 里的domain type会带kvm标识。

4.4 常见报错对照速查表

表格里列的这几个场景都是安装和使用 virt-manager 过程中出现频率最高的。最后一行关于存储文件权限的问题，下一章展开说。

5. 安装完成后的第一件事：把配套工具和虚拟机增强配好

5.1 顺手补装两个配套包

virt-manager 安装本身会带上virtinst，用来通过命令行创建带系统安装引导的虚拟机，因此通常不需要手动装。但不放心的情况下可以主动确认一下：

sudo apt install virt-viewer virtinst -y

virt-viewer的作用是提供一个轻量级的 SPICE/VNC 客户端，当你通过 SSH 远程管理宿主机时，用 virt-viewer 连接虚拟机控制台会比直接把 virt-manager 搬过去快得多。这两个包属于装了不吃亏、不装也多半不影响核心功能的类型。

5.2 virtio 驱动和客户机增强组件

安装完 virt-manager 只是宿主机的准备工作，虚拟机里默认的设备模拟都是标准硬件。如果想要虚拟机的性能更接近物理机，创建虚拟机时在磁盘总线、网卡模型这些位置选择virtio，可以显著降低虚拟化开销。Windows 客户机需要另外安装官方提供的 virtio-win 驱动镜像；Linux 客户机通常内核已经自带 virtio 驱动，不需要额外操作。

另一个值得装的东西是客户机里的 guest agent。对 Ubuntu 客户机来说，在虚拟机里面执行：

sudo apt install qemu-guest-agent

装好之后，virt-manager 界面上会更方便地显示虚拟机的 IP 地址、支持优雅关机等操作，而不是只能强制断电。很多人觉得 virt-manager 功能比 VirtualBox 少，其实只是没把客户机增强组件装全而已。

5.3 简单聊聊 Ubuntu 上 virt-manager 到底该怎么用最顺手

以我个人的使用习惯，装好 virt-manager 之后我不会立刻去调大量全局配置，而是用默认存储池建一台最小化的 Linux 虚拟机，跑通“创建—启动—连控制台—关机”整条链路，确认宿主机环境没有隐藏问题，然后才开始真正需要用的那几台虚拟机的搭建。

默认存储池路径是/var/lib/libvirt/images，这里必须强调的是：这个目录归 root 所有。如果你创建虚拟机时指定镜像文件放到这个路径下，virt-manager 会通过 libvirtd 进程来管理文件，所以并不存在普通用户写不了的权限问题。真正容易出问题的是自己改存储池路径到一个普通目录，然后又遇到 AppArmor 的访问限制，报出上面表格里那个 “Cannot access storage file”。因此新手阶段我强烈建议使用默认存储池路径，等熟悉了权限模型再自己创建自定义存储池。

最后提醒一个很多人忽略的地方：如果你是在带图形界面的 Ubuntu 桌面版上使用 virt-manager，GNOME 的电源管理可能会在虚拟机运行时休眠物理机，导致虚拟机被硬生生挂起。把桌面系统设成“永不待机”似乎和虚拟机管理没什么关系，但这其实是一个很隐蔽的影响因素。装好 virt-manager 之后顺手把这个设置确认一遍，能省掉后续不少莫名其妙的虚拟机状态异常。