企业官网建设流程全解析

装KVM这件事，敲下去的命令加起来不到十行，真正把人卡住的永远是装完之后那一步：virt-manager 打开了，虚拟机列表是空的；新建向导一路下一步，开机却是黑屏；或者干脆弹一句 Unable to connect to libvirt。我第一次装的时候在这句提示上耗了整整一个下午，最后发现原因简单到有点可笑——当前用户没被加进 libvirt 组，而我没有重新登录。

这篇东西写给两类人。一类是手里有一台 Ubuntu 或者 CentOS 系的机器，想用图形界面把 KVM 从零装起来，并且当天就能跑通第一台虚拟机；另一类是不满足于"命令能跑就行"，想知道每条命令、每个勾选项背后到底在干什么的人。全程围绕 kvm 的安装和图形化安装这两件事展开，不讲云平台、不讲容器编排，只讲本地虚拟化这条线。

1. 先把 KVM、QEMU、libvirt、virt-manager 这四层关系理清楚

1.1 同名的两个 KVM，先别走错门

KVM 这三个字母在市面上至少有两个完全不同的含义。一个是 Kernel-based Virtual Machine，也就是 Linux 内核自带的虚拟化模块，本文的主角；另一个是 Keyboard/Video/Mouse switch，键盘显示器鼠标切换器，就是那种一台显示器接两台主机、按个按钮切过去的硬件盒子。网上的热词里"kvm显示器共享器""怎么看kvm的8k认证"说的都是后者，和虚拟化一点关系没有。搜索的时候如果把这两类文章混着看，认知会被搅成一锅粥，所以先在自己的脑子里分个类。

本文讲的 KVM 是内核虚拟化那一支。它的特点是把虚拟化能力直接做进了 Linux 内核，配合 QEMU 做设备模拟，再由 libvirt 做统一管理接口，最后用 virt-manager 给你一个图形界面。这条链路是开源虚拟化里最成熟、资料最多、也最适合本地折腾的一条。

1.2 四层组件各自负责什么

很多人装到一半出问题，根子在于装错了层。这四层的关系拆开看其实很清楚：

• KVM：内核模块，通常叫kvm，加上 CPU 厂商对应的kvm_intel或kvm_amd。它提供的是 CPU 虚拟化能力，也就是让虚拟机里的指令能直接在物理 CPU 上跑，而不是靠软件一条条翻译。没有它，虚拟机照样能启动，但会退化成纯软件模拟，慢到让人怀疑机器坏了。
• QEMU：真正在跑的进程。你在ps aux里看到的qemu-system-x86_64就是它。磁盘、网卡、显卡、USB 这些设备的模拟全是 QEMU 干的活。KVM 加速开关是 QEMU 的一个启动参数，也就是说 QEMU 负责"躯壳"，KVM 负责"加速"。
• libvirt：管理中间层。它定义了一套统一的 XML 描述来表述虚拟机、网络、存储池，对外提供 API 和命令行工具virsh。有了它，你切换底层实现（QEMU/KVM、Xen、LXC）时上层配置基本不用改。同时它还负责任务隔离、权限控制、日志记录这些杂事。
• virt-manager：图形客户端。它本身不虚拟化任何东西，只是通过 libvirt 的接口把配置画成界面给你点。所以"virt-manager 连不上"和"KVM 没装好"是两件完全不同的事，排查方向也不一样。

我把它们的对应关系整理成一张表，装包的时候对照着看会清楚很多：

除了这四个，还有一个容易被忽略的替代品：cockpit-machines。它把虚拟机管理做进了 Cockpit 这个网页控制台里，适合那种只有 SSH、没有桌面的服务器。后面我会单独说怎么用它。

2. 装之前花五分钟做体检，能省掉一半返工

2.1 CPU 虚拟化开关与指令集检测

装 KVM 之前最该确认的一件事是：CPU 的虚拟化扩展到底开没开。Intel 平台叫 VT-x，AMD 平台叫 AMD-V，两者在 Linux 里分别对应vmx和svm两个 CPU flag。

# 看 CPU 是否暴露了虚拟化指令集 lscpu | grep -E 'Virtualization|vmx|svm' # 更直接：统计 flag 出现次数，返回 0 就是没开 grep -c -E 'vmx|svm' /proc/cpuinfo

如果这两条命令什么都看不到，别急着装包，先进 BIOS/UEFI 把虚拟化相关的选项打开。不同主板的叫法五花八门，常见的有 Intel Virtualization Technology、VT-x、SVM Mode、Secure Virtual Machine、AMD-V，部分品牌机还藏在 Advanced → CPU Configuration 这种二级菜单里。改完保存重启，再回来执行一遍上面的命令。

Ubuntu 上还有一个更省事的工具，叫cpu-checker：

sudo apt install -y cpu-checker kvm-ok

输出KVM acceleration can be used就说明一切就绪；如果提示信息里说 BIOS 把虚拟化关了，那就老老实实回去开。这个工具在排查"为什么虚拟机这么慢"的时候特别有用，因为它是一句话给结论的。

2.2 /dev/kvm 这个设备文件才是真正的通行证

指令集开了不等于立刻能用，还得看内核有没有把模块加载起来，以及设备节点在不在：

lsmod | grep kvm ls -l /dev/kvm

正常情况应该能看到kvm_intel或kvm_amd已经加载，并且/dev/kvm这个字符设备存在。如果模块没加载，手动加载一次：

sudo modprobe kvm sudo modprobe kvm_intel # AMD 平台换成 kvm_amd

/dev/kvm不在，或者权限不对，是后面一大堆奇怪现象的源头。这个设备的默认属主是 root、属组是 kvm，权限一般是crw-rw----。普通用户要想直接用，必须把自己加进 kvm 组，这一点在下一章还会详细说。

还有一个特殊情况值得提前知道：如果你当前这台 Linux 本身就是一台虚拟机，那么还需要宿主层面开启嵌套虚拟化。检查方式是对应平台的参数文件：

cat /sys/module/kvm_intel/parameters/nested # 输出 Y 或 1 表示已开启

返回 N 或 0 的话，需要在宿主的 KVM 模块参数里打开它，比如在/etc/modprobe.d/kvm.conf里写options kvm_intel nested=1再重新加载模块。顺手说一句，Windows 11 上的 WSL2 现在也支持嵌套虚拟化，/dev/kvm是能看到的，在里面装个 KVM 做实验完全可行，只是没有 systemd 全家桶、性能也打了折扣，适合练手不适合长期跑业务。

2.3 内存、磁盘和桌面环境这三项容易被低估

内存分配有个很常见的误区：一台 16GB 的机器，给虚拟机分了 14GB，结果宿主自己开始疯狂换页，整体体验反而崩了。我的经验是给虚拟机留出物理内存的六成左右，宿主至少保底 4GB 用于系统本身和 libvirt 的额外开销——每个 QEMU 进程除了你分配给虚拟机的内存，还会占用几百 MB 的额外空间。

磁盘这块，qcow2 格式的镜像文件是稀疏的，建的时候写 40GB，实际落盘可能只有几百 KB，所以不用担心"建盘即占满"。但宿主分区本身要留出余量，快照、内存转储、镜像扩容都吃空间。我一般会让镜像目录所在分区至少有 50GB 空闲。

最后是桌面环境。图形化安装 KVM 有两种理解方式：一种是用图形工具来管理 KVM，另一种是在图形界面的虚拟机控制台里装系统。这两种都需要一个能显示图形窗口的环境。物理机装了桌面自然没问题；如果是一台只有 SSH 的服务器，你有三个选择：装 Cockpit 用浏览器管理、把 virt-manager 的 X11 转发到本地、或者干脆用virt-install命令行加 VNC 客户端看画面。这三种我后面都会给具体做法，不强行推荐某一种。

3. Ubuntu 24.04 上的完整图形化安装链路

3.1 装包顺序与每个包的真实用途

Ubuntu 24.04 的软件源里，这一套包是齐的。我习惯一次性装完，但你要清楚每个包在干什么，出问题时才知道该卸谁：

sudo apt update sudo apt install -y \ qemu-system-x86 \ qemu-utils \ libvirt-daemon-system \ libvirt-clients \ virtinst \ virt-manager \ bridge-utils \ ovmf \ swtpm

逐个说清楚：qemu-system-x86是真正的模拟器主体；qemu-utils提供qemu-img这个建盘、转换、快照的工具，后面一定会用到；libvirt-daemon-system是守护进程加默认配置，libvirt-clients提供virsh和virt-host-validate命令；virtinst是virt-install的所在包，即使你全程用图形界面，某些向导内部也会调它；bridge-utils提供brctl，配网桥时用；ovmf是 UEFI 固件，建 Windows 11 或者要用 Secure Boot 的虚拟机必须装；swtpm提供软件 TPM 模拟，Windows 11 的硬件要求之一就是 TPM 2.0。

qemu-kvm这个包名现在在 Debian/Ubuntu 上是个过渡包，装上它会连带装qemu-system-x86，两种写法都能用，不用纠结。

3.2 libvirtd 到底该启哪个服务

装完之后启动服务这一步，不同版本差异很大。老路子是单体守护进程：

sudo systemctl enable --now libvirtd systemctl status libvirtd --no-pager

新一点的做法是把守护进程拆成模块化的几个：virtqemud管 QEMU、virtnetworkd管网络、virtstoraged管存储池、virtnodedevd管设备。有些发行版默认就走这一套，这时候你去systemctl status libvirtd会看到"服务不存在"之类的提示，很容易误判成装失败了。

稳妥的做法是先查一下系统里到底有哪个：

systemctl list-unit-files | grep -E 'libvirtd|virtqemud|virtnetworkd'

哪个存在就启哪个。如果走的是模块化那一套，通常把 socket 单元开起来就够了，它们会在有连接时按需拉起对应服务：

sudo systemctl enable --now virtqemud.socket virtnetworkd.socket virtstoraged.socket virtnodedevd.socket

这一步做完，用virsh验证一下管理通道是否通了：

virsh -c qemu:///system list --all

正常情况下会打印一个空表格，表头是 Id、Name、State。能打印出表头就说明 libvirt 已经能正常应答了；如果报连接失败或者权限错误，先别急着往下走。

3.3 用户组这步千万别跳过

接下来的操作是整篇里最容易被忽略、也最容易被误判成"软件坏了"的一步：把当前用户加进libvirt和kvm两个组。

sudo usermod -aG libvirt,kvm $USER

加完之后必须让组成员身份生效。newgrp libvirt可以立刻在当前终端里换一个带新组的 shell，但最干净的做法是注销重新登录，或者直接重启。我见过不止一个人加完组没重登，然后对着 virt-manager 的权限报错查了半天防火墙。

顺便把默认网络也处理掉。Ubuntu 上 libvirt 会自带一个叫default的 NAT 网络，多数情况是自动启动的，但 RHEL 系不一定：

sudo virsh net-list --all # 如果 State 是 inactive sudo virsh net-start default sudo virsh net-autostart default

3.4 打开 virt-manager 并验证功能完整

到这里就可以直接启动图形客户端了。终端里敲：

virt-manager

第一次打开会看到左侧有两行连接：QEMU/KVM和QEMU/KVM User session。这两个不是一回事。带 User session 的那个是以当前用户身份跑的、权限受限的会话，只能看到当前用户的虚拟机，网络配置能力也弱。默认应该双击QEMU/KVM那一行，也就是qemu:///system，这才是走系统级守护进程、能管网络和存储池的连接。

如果你在远程服务器上操作，本地没有桌面，那 Cockpit 这条路更省事：

sudo apt install -y cockpit cockpit-machines sudo systemctl enable --now cockpit.socket

然后用浏览器访问https://服务器地址:9090，登录后在左侧菜单里能找到"虚拟机"这一项。功能和 virt-manager 有差距，但建虚拟机、开关机、看控制台画面这些核心操作都有，对于纯服务器场景足够用。

4. CentOS Stream / RHEL / Rocky 系的差异点

4.1 组安装与包名对照

RHEL 这一系有个很好用的组包，一条命令把常用组件装齐：

sudo dnf install -y @virtualization

如果不想装组，手动装也完全可以：

sudo dnf install -y \ qemu-kvm \ libvirt \ libvirt-daemon-kvm \ virt-install \ virt-manager \ virt-viewer \ edk2-ovmf \ swtpm

注意这里的固件包叫edk2-ovmf，不叫ovmf；TPM 模拟除了swtpm还要装swtpm-tools才能用命令行配置。装完之后 RHEL 系自带一个非常好用的健康检查命令：

sudo virt-host-validate qemu

它会把 CPU 虚拟化、IOMMU、cgroup、设备权限这些项一条条列出来，PASS、WARN、FAIL 一目了然。看到 FAIL 就先按提示修，比盲目试错效率高得多。

RHEL 9 及以后的版本，默认走的也是模块化守护进程，不再依赖libvirtd这个大总管。这意味着网上很多老教程里的systemctl enable libvirtd会直接报错。这时候正确的做法是：

sudo systemctl enable --now virtqemud.socket sudo systemctl enable --now virtnetworkd.socket sudo systemctl enable --now virtstoraged.socket

4.2 SELinux 与防火墙对图形化管理的实际影响

Ubuntu 用户很少被 SELinux 折腾，RHEL 系就绕不开。默认策略下，libvirt 访问非标准路径的镜像文件会被拒绝，表现是虚拟机启动时报权限错误，但你去ls -l看文件权限明明是 777。正确的处理方式是给目录打上正确的标签：

sudo semanage fcontext -a -t virt_image_t "/data/kvm(/.*)?" sudo restorecon -Rv /data/kvm

如果要做网络存储，比如虚拟机镜像放在 NFS 上，还需要打开对应的布尔值：

sudo setsebool -P virt_use_nfs on

防火墙这块，本地用 virt-manager 看控制台画面完全不经过网络，不用管防火墙。只有要远程连到虚拟机的 VNC/SPICE 端口时才需要放行，但我的建议是别直接把 5900 这类端口开出去，用 SSH 隧道更安全也更省事：

ssh -L 5900:127.0.0.1:5900 user@宿主机

然后本地 VNC 客户端连127.0.0.1:5900就行。这样既不用改防火墙规则，也不用担心端口暴露的问题。

5. 用 virt-manager 建第一台虚拟机，每个选项都在做什么

5.1 新建向导里那几个容易点错的选项

点左上角的"创建新的虚拟机"，向导一共五步，每一步都有坑。

第一步是安装来源，选项有"本地安装介质""网络安装""导入现有磁盘映像""手动安装"。绝大多数人用第一个，选择 ISO 文件路径。这里有个细节：virt-manager 会自动探测 ISO 里是什么系统，然后自动填好系统类型。这个自动探测有时候会判断错，尤其是国产发行版和某些定制镜像。如果你知道要装什么，取消勾选"自动从安装介质/源检测"，手动在列表里选，会让后续的默认设备配置更合理。

第二步是内存和 CPU。这里有个反直觉的点：CPU 核心数给多了不一定快。虚拟机的 vCPU 数超过宿主物理核心数之后，调度开销会明显上升，尤其在做编译这种跑满多核的任务时。我的经验值是一台 8 核物理机，虚拟机给 4 个 vCPU 是舒适区；内存按前一章说的六成原则分配。

第三步是存储。默认会创建一个 qcow2 格式的镜像，放在/var/lib/libvirt/images下。这里有两个勾选项要留意：

• "为整个磁盘预分配"：勾上会立刻把整块盘的空间占满，换来的是写入时不需要动态分配、碎片更少、性能略好。家用和开发环境不勾，生产环境跑数据库可以考虑勾。
• "选择或创建自定义存储"：想放到别的路径、或者用已经存在的镜像文件，从这里进。

第四步是名称和网络。名称随便起，但别用中文和空格，有些底层脚本处理不了。网络选default，也就是那个 NAT 网络，先用它把系统装完，网络策略后面再调。

第五步有一个默认勾选的选项："在安装前自定义配置"。这个勾千万别取消，它是整篇里性价比最高的一个操作。

5.2 自定义配置界面里我会改的六处

勾上"安装前自定义配置"之后，会进入一个硬件列表界面。这里我按重要程度排个序，说说改什么、为什么改。

第一处是芯片组换成 Q35。在 Overview 那个页面里，把 Chipset 从 i440FX 改成 Q35。i440FX 是上世纪的架构，Q35 支持 PCIe、支持更现代的电源管理，对新系统兼容性更好。代价是老的 Windows XP 这类系统可能反而要留在 i440FX 上。

第二处是固件换成 UEFI。同样在 Overview 里，Firmware 从 BIOS 换成 UEFI x86_64 那一项（需要装了 ovmf 包才会出现）。装 Windows 11、装现代 Linux 发行版、想要 Secure Boot，都得走 UEFI。如果列表里只有 BIOS 选项，说明 ovmf 没装上，回去补装。

第三处是磁盘总线换成 virtio。找到 Disk 那一项，把 Bus 从 SATA 改成 VirtIO。virtio 是专门为虚拟化设计的半虚拟化驱动，性能比模拟出来的 SATA 控制器高一个档次。这里有个例外：装 Windows 的时候不能直接换，因为安装程序里没有 virtio 驱动，会看不到磁盘。正确做法是先挂一个 virtio-win 的驱动 ISO 作为第二个光驱，安装时手动加载驱动；或者先用 SATA 装完，进系统装好驱动再改回 virtio。

第四处是网卡模型换成 virtio。同理，性能更好。Windows 客户机同样需要 virtio 驱动，处理方式跟磁盘一样。

第五处是显卡模型。本地用默认的 QXL 就行，它和 SPICE 协议配合得最好，支持剪贴板共享和多显示器。如果是 Linux 客户机并且要跑图形加速，可以换成 virtio 系列；如果遇到黑屏，先把显卡换回 VGA 试试，这是最快的验证手段。

第六处是加一个 USB 控制器，型号选 USB 3.0（xhci）。不然后面想接 U 盘、想用 USB 重定向到虚拟机都做不了。

把这些改完，点"开始安装"，就进入正常的系统安装流程了。

6. KVM 网络这块，NAT、网桥、隔离网络分别什么时候用

6.1 默认 NAT 网络的工作方式

libvirt 的default网络本质上是在宿主机上建一个虚拟网桥virbr0，网段是 192.168.122.0/24，由 libvirt 自带的 dnsmasq 提供 DHCP 和 DNS，出网流量走宿主的 NAT 转发。

这套机制的优点是开箱即用、完全隔离、宿主重启后自动恢复。缺点也很明确：局域网里的其他机器访问不到虚拟机，因为虚拟机藏在宿主后面。想让外部访问，要么在宿主上做端口转发，要么老老实实配网桥。

端口转发用 nftables 或 iptables 都行，比如把宿主机的 2222 端口转到虚拟机的 22：

# 先给虚拟机在 DHCP 里固定一个 IP，避免重启后地址变了 sudo virsh net-update default add ip-dhcp-host \ "<host mac='52:54:00:aa:bb:cc' name='web01' ip='192.168.122.10'/>" --live --config # 加一条 DNAT 规则 sudo nft add rule ip nat PREROUTING tcp dport 2222 dnat to 192.168.122.10:22

MAC 地址在虚拟机的网卡详情里能看到。固定 IP 这一步很关键，不固定的话虚拟机重启换了个地址，转发规则就失效了，这种问题排查起来特别费时间。

6.2 手工配一个网桥，让虚拟机拿到局域网 IP

需要虚拟机在局域网里"像一台真实机器"一样存在时，网桥是唯一的选择。Ubuntu 24.04 默认用 netplan 管网络，配置文件放在/etc/netplan/下。假设物理网卡叫eno1，配一个桥接的 YAML 大概长这样：

network: version: 2 renderer: networkd ethernets: eno1: dhcp4: false dhcp6: false bridges: br0: interfaces: [eno1] dhcp4: true parameters: stp: false forward-delay: 0

然后应用：

sudo netplan try # 先试，120 秒内没断线再确认，比直接 apply 安全 sudo netplan apply

netplan try这个用法强烈建议养成习惯。远程改网络配置时，直接apply一旦写错就再也连不上了，只能去机房或者用带外管理救。try会在两分钟内自动回滚。

网桥建好之后，在 virt-manager 的虚拟机网络设置里，把"网络源"从"虚拟网络 default"改成"桥接设备 br0"，重启虚拟机就能拿到局域网的 DHCP 地址了。

有一个坑必须提前说：无线网卡基本没法做网桥。绝大多数无线驱动不支持桥接所需的混杂模式转发，硬配的结果是网络时通时断。这种情况下的替代方案是 macvtap，它能给虚拟机一个和宿主同网段的地址，但代价是宿主机和虚拟机之间默认不能直接通信（因为流量走的是不同的路径）。macvtap 在 virt-manager 里对应"网络源"里的"桥接设备"选项下面的 macvtap 模式，用之前想清楚这个限制能不能接受。

6.3 隔离网络：一个经常被忽略的好用模式

还有一种网络模式叫隔离网络，虚拟机之间能互相通信，但谁都出不了网，宿主机也进不去（除非加规则）。听起来像鸡肋，其实在做安全测试、复现恶意样本、搭建多机集群实验的时候非常有用——你肯定不希望实验用的机器能连到外面。

在 virt-manager 里可以通过"连接详情"→"虚拟网络"新建一个，转发模式选"隔离"；命令行做法是定义一个 XML：

<network> <name>isolated</name> <bridge name="virbr10"/> <ip address="10.10.10.1" netmask="255.255.255.0"/> </network>

用virsh net-define导入再启动即可。三种网络模式的对比我整理在这里：

7. 图形界面起不来、黑屏、卡死时的排查顺序

7.1 连不上 libvirtd 的三种典型报错

排查要按从底到上的顺序走，跳步会浪费大量时间。

第一层，先确认服务活着：

systemctl status libvirtd --no-pager # 或者模块化的 systemctl status virtqemud.socket --no-pager journalctl -u libvirtd -n 50 --no-pager

服务没起来的话，日志最后几行通常会写明原因，最常见的是配置文件语法错误或者端口被占。

第二层，确认virsh能连上：

virsh -c qemu:///system list --all

如果这里报Permission denied或者authentication failed，九成是用户组没生效。回去执行groups看看输出里有没有 libvirt 和 kvm，没有就重新加组再重登。

第三层，才是图形客户端的问题。virt-manager 报Unable to connect to libvirt qemu:///system时，先在终端里跑一遍同样的virsh命令。如果 virsh 能通而 virt-manager 不通，问题在图形端，通常是 DISPLAY 或 X11 授权的问题；如果 virsh 也不通，问题在服务端，回到前两层。这个二分法能省掉一大半瞎猜的时间。

7.2 虚拟机黑屏、极慢、启动失败的定位思路

黑屏是最常见也最好定位的一类问题。它的第一嫌疑人是显卡模型和显示协议不匹配。最快的验证方法是在虚拟机的硬件详情里，把显示协议从 SPICE 换成 VNC，顺手把显卡从 QXL 换成 VGA，然后重新开机。画面出来了，说明是驱动或协议的问题；画面还是黑的，往下查。

第二个要看的是 QEMU 的日志：

sudo tail -f /var/log/libvirt/qemu/虚拟机名字.log

这个日志里会记录固件加载失败、磁盘打不开、参数不合法这类底层错误，比图形界面弹出的提示详细得多。

虚拟机慢到不正常，八成是因为没走 KVM 加速，退化成纯软件模拟了。验证方法很直接：

virsh dumpxml 虚拟机名字 | grep -E "domain type|hypervisor"

看到<domain type='kvm'>才是走 KVM；如果是qemu，说明加速没启用，回头检查/dev/kvm和相关权限。

如果是镜像文件放在了/root或者家目录下导致启动失败，Ubuntu 上大概率是 AppArmor 拦的，dmesg | grep -i apparmor能看到denied记录。这里的建议很明确：别去改 AppArmor 规则放宽权限，把镜像放到标准路径下。改安全策略图一时省事，后续会埋更大的坑。

还有一种少见的失败：建 Windows 11 虚拟机时提示 TPM 相关错误。这是因为它要求 TPM 2.0，需要在虚拟机硬件里添加一个 TPM 设备，类型选"仿真设备"，后端选 swtpm，前提是swtpm包已经装好。

排错时对照这张表会快很多：

8. 装完之后值得立刻调的几处设置与存储取舍

8.1 存储池规划与 qcow2、raw 的取舍

默认镜像目录/var/lib/libvirt/images通常在根分区上，空间有限。正经用起来我第一件事就是加一块独立盘做成存储池：

# 假设新盘已经挂载到 /data sudo virsh pool-define-as vmpool dir --target /data/kvm/pool sudo virsh pool-build vmpool sudo virsh pool-start vmpool sudo virsh pool-autostart vmpool virsh pool-list --all

建完之后 virt-manager 的存储界面里就能选这个池了。这一步的价值在于：镜像和根分区解耦，快照、扩容、备份都清爽，也不容易把系统盘撑爆。

至于镜像格式，qcow2 和 raw 的关系可以用一个类比来理解。raw 就像一张没裁剪的原始照片，读写路径最短、性能最好，但文件一开始就是固定大小，浪费空间，而且 libvirt 层面的内部快照用不了。qcow2 像带索引的压缩包，支持稀疏分配（用多少占多少）、支持内部快照、支持压缩，代价是每次读写多一层元数据查找。开发、测试、需要频繁打快照的场景选 qcow2；跑数据库或者对 IOPS 敏感的业务盘选 raw。这不是绝对规则，量级不大的时候两者体感很难分辨。

建盘的命令顺手记一下：

qemu-img create -f qcow2 /data/kvm/pool/test01.qcow2 60G qemu-img info /data/kvm/pool/test01.qcow2

第二条命令会告诉你这个文件实际占用了多少空间，通常远小于 60G，这就是稀疏分配的效果。

8.2 显示协议、共享文件夹与几个性能开关

显示协议这块，SPICE 和 VNC 各有各的位置。SPICE 支持剪贴板双向复制、USB 重定向、多显示器、动态调整分辨率，体验接近本地桌面，缺点是客户端支持面窄；VNC 兼容性最好，什么客户端都能连，但没有剪贴板共享。我的习惯是本地开发用 SPICE，远程救急用 VNC。

共享文件夹是我踩过坑的地方。老一些的教程会让你加一个 9p 文件系统，做法是在硬件里添加 Filesystem，驱动选默认，源路径填宿主目录，目标路径填个标签名，然后客户机里：

sudo mount -t 9p -o trans=virtio share /mnt/share

9p 能用，但性能一般，大批量小文件传输会很慢。更新的方案是 virtiofs，性能好很多，代价是配置稍麻烦：需要客户机内存用共享模式，virt-manager里在 Overview 里把"共享内存"打开，然后文件系统驱动的类型选 virtiofs，宿主端还需要装上 virtiofsd。速度要求高就折腾 virtiofs，只是偶尔传个文件用 9p 就够了。

CPU 模式是一个经常被忽略但影响不小的设置。默认通常是host-model，它会根据宿主 CPU 自动挑一个兼容的型号；改成host-passthrough能把宿主 CPU 的特性完整透传给客户机，性能最好，代价是这台虚拟机的配置绑定了当前宿主的 CPU 型号，跨机器迁移会有问题。本地固定机器用 host-passthrough，需要迁移的场景用 host-model。

磁盘缓存模式在磁盘的高级选项里，常见的有writeback、none、directsync三种。writeback是默认值，性能好但宿主机突然断电时有丢数据的风险；none让 IO 走宿主页缓存，理论上断电更安全一些；directsync直接读写磁盘、绕过缓存，最安全但最慢。开发机用默认的 writeback 完全够，有数据可靠性要求的场景再往安全那头调。

快照这块最后提一句：内部快照只有 qcow2 支持，命令是virsh snapshot-create-as，用起来很方便，但它会把快照数据存在同一个镜像文件里，长期堆叠会让镜像膨胀、性能下降。我的做法是拍完快照做实验，实验完就删掉，不作为长期备份手段。真正的备份还是要把镜像文件复制出去。

8.3 我在实际使用中总结的几条经验

装完这一整套之后，有几个习惯我觉得比技术本身更重要。

第一，建虚拟机之前先想好它要活多久。如果只是个临时实验环境，别用默认的 60GB 磁盘，给 20GB 就够，用完直接virsh undefine --remove-all-storage删干净，不然半年后你会发现镜像目录里堆了几十个不知道干什么用的文件。

第二，给每台虚拟机在 DHCP 里固定 IP，哪怕它现在只用 NAT。一开始花十秒配好，比后面每次都去查 IP 强太多。

第三，virsh dumpxml是你的逃生舱。图形界面点错了、配置改崩了，先virsh dumpxml 名字 > backup.xml存一份当前状态，任何改动出问题都能用virsh define backup.xml回滚。这个命令我现在几乎是肌肉记忆，改任何关键配置前都会先跑一遍。

第四，别迷信图形界面。virt-manager 好用，但它能做的事情有限，比如热插拔设备、批量操作、精细的性能参数调整，命令行反而更直接。我的实际组合是：建虚拟机、看控制台用 virt-manager，日常开关机、查状态、改配置用 virsh。两套工具配合着用，效率比死守一个高得多。