企业官网建设流程全解析

1. 为什么你需要吃透 domain XML

搞 KVM 虚拟化的朋友，十有八九都经历过这样的场景：虚拟机起不来，日志里一堆报错，最后定位到某个 XML 字段写错了；或者想给虚机加个网卡、挂块盘，用virt-manager图形界面点半天，结果发现底层改的还是那一坨 XML。说白了，domain XML 就是 KVM 虚拟机的“身份证 + 配置清单”，libvirt 靠它来定义一台虚机的全部硬件和行为。你把它读懂了，等于拿到了虚机的“源码级控制权”。

这篇文章面向的是已经上手过 KVM、用过virsh基本命令，但对 XML 里那些密密麻麻的标签还停留在“能看懂一半、改起来心虚”阶段的运维和开发同学。我会从整体结构讲到每个核心段落的实战用法，把 CPU、内存、磁盘、网络、设备直通这些高频配置逐个拆开，配上可直接抄的参数和踩坑经验。读完你至少能做到：拿到一份陌生 XML 能快速定位关键配置，手写一份能跑起来的虚机定义，遇到启动报错知道往哪个标签里找原因。

需要先明确一个概念：domain XML 不是 KVM 本身的格式，而是 libvirt 的抽象层。KVM 只认 QEMU 的命令行参数，libvirt 把那些参数翻译成 XML，再在启动时还原成 QEMU 命令。所以你改 XML 的本质，是在改 libvirt 生成 QEMU 命令的“配方”。理解这一层，很多字段为什么这么设计就通了。

2. domain XML 的整体骨架拆解

2.1 一份最小可用 XML 长什么样

先看结构，别急着记标签。一份 domain XML 的顶层就是一个<domain>根元素，里面按逻辑分成几大块：元信息（name、uuid、memory、vcpu）、系统信息（os、features）、设备清单（devices）、以及可选的电源管理、CPU 调优等。下面这份是我平时手写测试用的最小骨架，去掉注释基本能直接跑：

<domain type='kvm'> <name>test-vm01</name> <memory unit='MiB'>2048</memory> <vcpu placement='static'>2</vcpu> <os> <type arch='x86_64' machine='q35'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> </features> <devices> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/test-vm01.qcow2'/> <target dev='vda' bus='virtio'/> </disk> <interface type='network'> <source network='default'/> <model type='virtio'/> </interface> <graphics type='vnc' port='-1' autoport='yes'/> </devices> </domain>

这份骨架里，type='kvm'决定了用 KVM 加速而不是纯 QEMU 模拟；machine='q35'是芯片组型号，后面会细说为什么它比默认的 i440fx 更值得用。<devices>是重头戏，磁盘、网卡、显卡、输入设备全在里面。

2.2 元信息段的三个关键字段

<name>是虚机的唯一标识，virsh list里显示的就是它，改名要慎重，因为很多脚本和存储路径都依赖这个名字。<uuid>建议保留自动生成的，手动指定的话务必保证全局唯一，否则 libvirt 会拒绝加载。<memory>和<vcpu>看似简单，但有个细节：memory 的 unit 属性不写默认是 KiB，很多人写2048以为是 2G，实际只有 2M，虚机直接起不来。我习惯显式写unit='MiB'，省得自己坑自己。

<vcpu>的placement属性值得单独提一句。static表示 vCPU 绑定到物理核的映射关系由你手动指定（配合<cputune>），auto则交给 libvirt 调度。生产环境如果对延迟敏感，比如跑实时业务，建议用 static 加 cputune 做绑核；普通业务用默认的 auto 就行，别过度优化。

2.3 os 段与固件选择

<os>段里<type>的arch和machine两个属性决定了虚机的“主板”。arch一般就是宿主机的架构，machine常见的有i440fx和q35。i440fx 是老爷车，兼容性极好但只支持 PCI，不支持 PCIe；q35 是现代芯片组，支持 PCIe、原生 SATA、更好的电源管理。新装虚机我一律推荐 q35，除非你要迁移的老虚机是 i440fx 且不想折腾。

<boot>标签控制启动顺序，可以写多个，按顺序尝试。还有个<bootmenu enable='yes'/>能在启动时按 F12 调出菜单，调试装机时特别有用。如果是 UEFI 启动，<os>里还要加<loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>和对应的<nvram>，这块后面固件章节会展开。

3. CPU 与内存配置的深水区

3.1 CPU 模型与透传的取舍

<cpu>段是性能调优的核心。最简单的写法是<cpu mode='host-passthrough'/>，意思是把宿主机的 CPU 特性原样透传给虚机，虚机看到的 CPU 和物理机几乎一致，性能最好，适合同架构内网环境。但它的缺点是迁移受限——如果目标宿主机 CPU 型号不同，热迁移可能失败。

另一种是<cpu mode='custom' match='exact'>配合<model fallback='allow'>Skylake-Client</model>，指定一个具体的 CPU 模型，兼容性更好，适合集群里宿主机型号不统一的场景。选哪个取决于你的迁移需求：单机跑业务用 host-passthrough，集群里要漂移就用 custom 加一个较老的模型做基线。

还有个<feature>子标签可以精细控制，比如<feature policy='disable' name='hypervisor'/>能隐藏虚拟化标志，某些软件检测到自己在虚机里会拒绝运行，这个开关就派上用场了。

3.2 内存的 backing 与 hugepages

内存段除了大小，还有两个进阶玩法。一是<memoryBacking>里配置 hugepages：

<memoryBacking> <hugepages> <page size='2048' unit='KiB'/> </hugepages> </memoryBacking>

大页能显著降低 TLB miss，对数据库、缓存类负载提升明显。但前提是宿主机要预留大页，用echo 1024 > /proc/sys/vm/nr_hugepages之类的方式分配，否则虚机启动会报“无法分配大页”。

二是<memtune>里的hard_limit，限制虚机最大可用内存。注意这个值要留足余量，设得太紧会导致虚机被 OOM killer 干掉。我一般设成分配内存的 1.1 到 1.2 倍，给 QEMU 进程本身的开销留空间。

3.3 NUMA 亲和性配置

多路服务器上，NUMA 配置不当会让跨节点访存拖慢性能。<numatune>可以把虚机内存绑定到特定 NUMA 节点：

<numatune> <memory mode='strict' nodeset='0'/> </numatune>

配合<vcpu>里的<topology>和 cputune 的<vcpupin>，能做到 vCPU 和内存都在同一个 NUMA 节点内，访存延迟最低。判断是否需要这套配置，看你的业务是不是对内存带宽敏感——普通 Web 服务感知不强，但跑内存数据库就很有必要。

4. 磁盘与存储的实战配置

4.1 disk 标签的五个必填项

磁盘配置是改得最多的地方。一个<disk>至少要搞清楚五个属性：type（file/block/network）、device（disk/cdrom/floppy）、driver（name 和 type）、source、target。下面这份是 qcow2 文件盘的标准写法：

<disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none' io='native'/> <source file='/var/lib/libvirt/images/vm01.qcow2'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk>

cache和io两个参数是性能关键。cache='none'让 I/O 绕过宿主机页缓存，配合io='native'使用 Linux 的 native AIO，是生产环境最常用的组合。如果虚机里跑的是对数据安全要求极高的库，可以考虑cache='writethrough'，但性能会打折。千万别用cache='unsafe'，那是拿数据完整性换性能，宿主机一断电虚机文件系统就可能损坏。

4.2 总线类型怎么选

target的bus属性决定磁盘挂在哪条总线上，常见的有 virtio、scsi、sata、ide。virtio 性能最好，是 Linux 虚机的首选；Windows 虚机如果没有装 virtio 驱动，装机阶段得先用 ide 或 sata，装完驱动再切 virtio。scsi 配合 virtio-scsi 控制器能支持更多设备和更好的队列，适合挂多块盘的场景。

这里有个实操技巧：改 bus 类型时，target dev 的命名也要跟着改。virtio 用 vda/vdb，sata 用 sda/sdb，ide 用 hda/hdb。名字对不上，libvirt 会报设备冲突。

4.3 热插拔与磁盘扩容

线上扩容磁盘，不用关机。流程是先用qemu-img resize扩大镜像文件，再在虚机里扩展分区和文件系统。XML 层面如果只是改大小，其实不用动 XML，因为<source>指向的文件变了，虚机重启后自然识别新容量。但如果要新增一块盘，就得编辑 XML 加一个<disk>段，然后virsh attach-device热挂载。

热插拔有个坑：不是所有总线都支持热插拔。virtio 和 scsi 支持，ide 基本不支持。所以规划虚机时，如果预判到后期要动态加盘，一开始就选 virtio 或 scsi 总线。

5. 网络配置的三种模式与选型

5.1 默认 NAT 网络的 XML 写法

最常见的网络配置是走 libvirt 默认的 NAT 网络：

<interface type='network'> <source network='default'/> <model type='virtio'/> <mac address='52:54:00:xx:xx:xx'/> </interface>

type='network'表示引用 libvirt 管理的网络，source network='default'就是那个开箱即用的 NAT 网络。虚机能上网，但外部访问虚机需要配端口转发。model选 virtio 性能最好，Windows 虚机同样需要驱动。

5.2 桥接网络与 macvtap

要让虚机像物理机一样直接暴露在局域网，用桥接：

<interface type='bridge'> <source bridge='br0'/> <model type='virtio'/> </interface>

前提是宿主机上已经建好 br0 网桥，并把物理网卡挂进去。桥接模式下虚机拿到的是局域网 IP，外部可直接访问，适合对外提供服务的虚机。

macvtap 是另一种直通方案，type='direct'配合source dev='eth0' mode='bridge'。它性能接近桥接但配置更简单，缺点是宿主机和虚机之间默认不能直接通信，需要额外处理。选型上，需要宿主机-虚机互访就用 bridge，纯对外服务可以用 macvtap。

5.3 网卡多队列与 vhost

高流量场景下，单队列网卡会成为瓶颈。可以在<driver>里开启多队列：

<interface type='network'> <source network='default'/> <model type='virtio'/> <driver name='vhost' queues='4'/> </interface>

queues='4'表示开 4 个队列，一般设成和 vCPU 数相当。name='vhost'启用内核态的 vhost-net 加速，比用户态的 virtio 后端性能更好。这两个参数配合使用，能把网络吞吐拉高一个档次。改完记得在虚机里也确认网卡队列数，用ethtool -l查看。

6. 设备直通与图形显示

6.1 PCI 直通的关键步骤

把一块物理网卡或 GPU 直通给虚机，XML 里加的是<hostdev>：

<hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> </hostdev>

managed='yes'让 libvirt 自动处理设备从宿主机解绑和绑定到 vfio 驱动的过程。但前提是宿主机内核开启了 IOMMU，并且设备所在 IOMMU 组是干净的（组里没有其他关键设备）。查 IOMMU 组用ls -l /sys/kernel/iommu_groups/，如果一块网卡和一堆设备挤在一个组里，直通会失败，需要调整 PCI 插槽位置或加 ACS 补丁。

6.2 显卡与 VNC/SPICE 配置

图形输出段<graphics>决定你怎么连虚机控制台。VNC 最通用：

<graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics>

port='-1'加autoport='yes'让 libvirt 自动分配端口，避免冲突。SPICE 在图形体验和剪贴板共享上更好，但配置稍复杂，需要配合<channel>和<video>段。如果虚机是纯命令行使用，其实可以完全去掉 graphics，用串口 console 登录，省资源又安全。

6.3 输入设备与 USB 重定向

<input type='tablet'/>能让鼠标在 VNC 里定位准确，不加的话鼠标会漂移。USB 重定向需要<redirdev>配合 SPICE，把宿主机的 U 盘、加密狗透传给虚机。这块配置对做开发测试的同学很实用，但要注意 USB 控制器类型，q35 芯片组用ich9-ehci1系列，i440fx 用piix3-uhci。

7. 常见报错与排查速查

7.1 启动失败的典型原因

虚机起不来，先看virsh start的报错，再查/var/log/libvirt/qemu/<虚机名>.log。下面这张表是我这些年攒下来的高频问题：

7.2 XML 校验与热更新技巧

改完 XML 别急着启动，先用virt-xml-validate校验格式：

virt-xml-validate /etc/libvirt/qemu/vm01.xml

这个命令能抓出标签拼写错误、属性缺失这类低级问题。热更新用virsh edit直接改，保存后 libvirt 会尝试应用，能热生效的立即生效，需要重启的会提示。注意virsh edit改的是持久配置，如果虚机正在运行且改动无法热应用，重启后才生效，别以为改完就立刻起作用了。

7.3 我踩过的几个坑

第一个坑是 UUID 冲突。有次从别的宿主机拷贝了一份 XML 过来，忘了改 UUID，结果两台宿主机上虚机互相干扰。后来养成习惯，导入外部 XML 第一件事就是virsh define前先删掉 uuid 行让它重新生成。

第二个坑是磁盘路径用了相对路径。libvirt 对相对路径的解析基准不固定，有时按当前工作目录算，导致找不到镜像。所有 source 路径一律写绝对路径，这是铁律。

第三个坑是改完 CPU 模型后忘了清 nvram。UEFI 虚机换 CPU 模型，旧的 nvram 里存着启动项，可能导致启动异常。换 CPU 配置时顺手把 nvram 文件删了让它重建，能省不少排查时间。

8. 从 XML 到 QEMU 命令的验证思路

想确认自己的 XML 到底翻译成了什么 QEMU 命令，有个很实用的办法：启动虚机后，用ps -ef | grep qemu看进程参数，或者直接读/var/log/libvirt/qemu/<虚机名>.log，里面完整记录了 libvirt 拼出来的命令行。对照着看，你会发现 XML 里每个字段都能在命令行里找到对应项，比如<memory>对应-m，<vcpu>对应-smp，<disk>对应-drive。

这个对照过程对理解 XML 帮助极大。我当初就是靠反复比对，才搞明白cache和io到底怎么映射到 QEMU 的cache=和aio=参数。等你也能一眼看出 XML 和命令行的对应关系，基本就算把 domain XML 吃透了。后续再遇到新设备、新特性，无非是查一下它对应哪个 QEMU 参数，然后反推 XML 怎么写，路子就通了。