虚拟化最佳实践 #

更改 VM Guest 或 VM 主机服务器的配置可能会导致数据丢失或状态不稳定。在做出任何更改之前，请务必先对文件、数据、图像等进行备份。如不备份，您将无法在数据丢失或配置错误后恢复原始状态。请勿在生产系统上执行测试或试验。

虚拟化环境的效率取决于众多因素。本指南将提供一些参考，帮助您在生产环境中配置虚拟化时做出正确选择。做任何事情都无法一劳永逸。在规划、测试和部署虚拟化基础结构时，应将硬件、工作负载、资源容量等所有因素都考虑在内。测试您的虚拟化工作负载对成功实施虚拟化至关重要。

SUSE 强烈建议使用 libvirt 框架来配置、管理和操作 VM 主机服务器与 VM Guest。该框架提供了一个适用于所有支持的虚拟化技术的统一界面（GUI 和外壳），因此比特定于超级管理程序的工具更容易使用。

我们不建议同时使用 libvirt 和特定于超级管理程序的工具，因为 libvirt 工具集可能无法识别使用特定于超级管理程序的工具进行的更改。有关 libvirt 的详细信息，请参见Book “虚拟化指南”, Chapter 8 “启动和停止 libvirtd”。

qemu-system-x86_64 与真正的 64 位 PC 硬件类似，支持运行 32 位或 64 位操作系统的 VM Guest。由于 qemu-system-x86_64 通常也可为 32 位 Guest 提供更佳性能，因此 SUSE 一般建议对 KVM 上的 32 位和 64 位 VM Guest 都使用 qemu-system-x86_64。已知 qemu-system-i386 可提供更佳性能的方案不受 SUSE 支持。

Xen 也使用 qemu 软件包中的二进制文件，但更倾向于使用 qemu-system-i386，qemu-system-i386 也可用于 32 位和 64 位 Xen VM Guest。为保持与上游 Xen 社区的兼容性，SUSE 建议对 Xen VM Guest 使用 qemu-system-i386。

Linux 以称为页的单元来管理内存。在大多数系统上，默认页大小为 4 KB。Linux 和 CPU 需要知道哪些页属于哪些进程。该信息储存在页表中。如果有大量进程在运行，则需要花更多时间来查找内存映射的位置，因为搜索页表需要时间。为加快搜索速度，发明了 TLB（转换后援缓冲区）技术。但在具有大量内存的系统上，TLB 也无法完全满足需求。为避免回退到普通页表（会导致发生缓存不命中情况，这将耗费大量时间），可以使用大页。使用大页将减少 TLB 开销和找不到 TLB 的情况 (pagewalk)。对于内存为 32 GB (32*1014*1024 = 33,554,432 KB)、页大小为 4 KB 的主机，TLB 具有 33,554,432/4 = 8,388,608 个项。使用 2 MB (2048 KB) 的页大小时，TLB 只有 33554432/2048 = 16384 个项，可大大减少找不到 TLB 的情况。

4.1.1 将 VM 主机服务器和 VM Guest 配置为使用大页 #

 

AMD64/Intel 64 CPU 体系结构支持大于 4 KB 的页，即大页。要确定系统上可用大页的大小（可以是 2 MB 或 1 GB），请查看 /proc/cpuinfo 输出中的 flags 行中是否包含 pse 和/或 pdpe1gb。

表 1︰ 确定可用的大页大小 #

 

CPU 标志	可用的大页大小
空字符串	没有可用的大页
pse	2 MB
pdpe1gb	1 GB

使用大页可以提升 VM Guest 的性能并减少主机内存的消耗。

默认情况下，系统使用 THP。要使系统上可以使用大页，请在引导时使用 hugepages=1 来激活大页，您也可以选择使用 hugepagesz=2MB（举例而言）来添加大页大小。

注意：1 GB 大页

1 GB 的页只能在引导时分配，之后将无法释放。

要分配和使用大页表 (HugeTlbPage)，您需要使用正确的权限挂载 hugetlbfs。

注意：大页的相关限制

大页虽然能够提供最佳性能，但也存在一些缺点。使用大页时，内存气球（请参见第 6.1.3 节 “virtio balloon”）、KSM（请参见第 4.1.4 节 “KSM 和页共享”）等功能将不可用，并且大页无法交换。

过程 1︰ 配置大页的使用 #

 

1. 将 hugetlbfs 挂载 /dev/hugepages：

   tux > sudo mount -t hugetlbfs hugetlbfs /dev/hugepages

2. 要为大页保留内存，请使用 sysctl 命令。如果系统的大页大小为 2 MB (2048 KB)，而您想要为 VM Guest 保留 1 GB (1,048,576 KB)，那么池中需要有 1,048,576/2048=512 个页：

   tux > sudo sysctl vm.nr_hugepages=512

   该值将写入 /proc/sys/vm/nr_hugepages，表示内核的大页池中当前持续存在的大页数量。被任务释放后，持续存在的大页将返回到大页池。

3. 通过运行 virsh edit CONFIGURATION 将 memoryBacking 元素添加到 VM Guest 配置文件中。

   <memoryBacking>
     <hugepages/>
   </memoryBacking>

4. 启动 VM Guest，检查主机是否使用了大页：

   tux > cat /proc/meminfo | grep HugePages_
   HugePages_Total:1     512
   HugePages_Free:2       92
   HugePages_Rsvd:3        0
   HugePages_Surp:4        0

   1	大页池的大小
   2	池中尚未分配的大页数量
   3	已承诺从池中分配但尚未进行分配的大页数量
   4	池中大于 /proc/sys/vm/nr_hugepages 中的值的大页数量。最大剩余大页数由 /proc/sys/vm/nr_overcommit_hugepages 控制

4.1.2 透明大页 #

 

利用透明大页 (THP)，您可以使用 khugepaged 内核线程动态分配大页，无需再手动管理大页的分配和使用。THP 对于采用连续内存访问模式的工作负载很有用。在运行采用连续内存访问模式的合成工作负载时，页错误可减少 1000 倍。反之，对于采用稀疏内存访问模式的工作负载（例如数据库），THP 可能表现较差。在这类情况下，比较好的做法可能是通过添加内核参数 transparent_hugepage=never 来禁用 THP，然后重构建 grub2 配置并重引导。使用以下命令校验是否已禁用 THP：

tux > cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

如已禁用，方括号中将会显示值 never，如上例中所示。

注意：Xen

THP 在 Xen 下不可用。

tux > sudo mount -t tmpfs tmpfs /var/lib/xenstored/

4.1.4 KSM 和页共享 #

 

内核同页合并 (Kernel Samepage Merging) 是一项内核功能，可以通过共享 VM Guest 共有的内存块来减少 VM 主机服务器上消耗的内存。KSM 守护程序 ksmd 会定期扫描用户内存，查找包含相同内容、可由单个写保护页替换的页。要启用 KSM 服务，请先确保软件包 qemu-ksm 已安装，然后运行以下命令：

tux > sudo systemctl enable --now ksm.service

或者，也可以运行以下命令来启动该服务：

tux > sudo echo 1 > /sys/kernel/mm/ksm/run

从 VM Guest 的角度而言，使用 KSM 的优点之一是所有 Guest 内存都受主机匿名内存支持。您可以共享 pagecache、tmpfs 或 Guest 中分配的任何类型的内存。

KSM 由 sysfs 控制。您可以在 /sys/kernel/mm/ksm/ 中查看 KSM 的值：

• pages_shared：正在使用的共享页数量（只读）。

• pages_sharing：正在共享页的站点数量（只读）。

• pages_unshared：为进行合并而反复检查的唯一页数量（只读）。

• pages_volatile：更改太快而认为无法合并的页数量（只读）。

• full_scans：已扫描所有可合并区域的次数（只读）。

• sleep_millisecs：ksmd 在下次扫描前应休眠的毫秒数。值过低会过度使用 CPU，导致消耗可以用于其他任务的 CPU 时间。我们建议将该值设为 1000 以上。

• pages_to_scan：在 ksmd 进入睡眠状态之前要扫描的当前页数。值过高会过度使用 CPU。我们建议先将该值设为 1000，然后根据在测试部署时观察到的 KSM 结果进行必要的调整。

• merge_across_nodes：默认情况下，系统会跨 NUMA 节点合并页。将此选项设为 0 会禁用此行为。

注意：使用案例

KSM 技术非常适合在运行同一个应用程序或 VM Guest 的多个实例时过量使用主机内存。当应用程序和 VM Guest 类型不一并且不共享任何共用数据时，最好禁用 KSM。为此，请运行：

tux > sudo systemctl disable --now ksm.service

或者，也可以运行以下命令来禁用该服务：

tux > sudo echo 0 > /sys/kernel/mm/ksm/run

在异类和同类混杂的环境中，可以在主机上启用 KSM，但要对每个 VM Guest 禁用 KSM。可以使用 virsh edit 在 VM Guest 的 XML 配置中添加以下内容来禁用 Guest 页共享：

<memoryBacking>
   <nosharepages/>
</memoryBacking>

警告：避免出现内存不足的情况

尽管 KSM 可以释放主机系统上的一些内存，但是管理员应当保留足够的交换来避免可共享内存减少时内存不足的情况。如果可共享内存的量减少，就会增加物理内存的使用量。

警告：内存访问延迟

默认情况下，KSM 会跨 NUMA 节点合并共用页。如果合并后的共用页现在位于较远的 NUMA 节点上（相对于运行 VM Guest vCPU 的节点），这样可能会降低 VM Guest 的性能。如果在 VM Guest 中发现内存访问延迟增加，请使用 merge_across_nodes sysfs 控制禁用跨节点合并：

tux > sudo echo 0 > /sys/kernel/mm/ksm/merge_across_nodes

<maxMemory1 slots='16'2 unit='KiB'>209715203</maxMemory>
  <memory4 unit='KiB'>1048576</memory>
<currentMemory5 unit='KiB'>1048576</currentMemory>

<memory model='dimm'>
  <target>
  <size unit='KiB'>524287</size>
  <node>0</node>
  </target>
</memory>

tux > virsh attach-device vm-name mem-dev.xml

系统通常使用交换来储存未充分使用的物理内存（用量较低或长时间未访问）。为防止系统内存不足，强烈建议设置最小交换。

tux > sudo echo 35 > /proc/sys/vm/swappiness

tux > free -h
total       used       free     shared    buffers     cached
Mem:      24616680    4991492   19625188     167056     144340    2152408
-/+ buffers/cache:    2694744   21921936
Swap:      6171644          0    6171644

vm.swappiness = 35

<memtune>1
  <hard_limit unit='G'>1</hard_limit>2
  <soft_limit unit='M'>128</soft_limit>3
  <swap_hard_limit unit='G'>2</swap_hard_limit>4
</memtune>

VM Guest 的储存空间可以是块设备（例如，物理磁盘上的分区），也可以是文件系统上的映像文件：

有关映像格式和维护映像的详细信息，请参见第 5 节 “VM Guest 映像”。

如果您的映像储存在 NFS 共享中，您应检查一些服务器和客户端参数来改进对 VM Guest 映像的访问。

nfs_server:/exported/vm_images1 /mnt/images2 nfs3 rw4,hard5,sync6, rsize=81927,wsize=81928 0 0

tux > sudo nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
6401066    198          0          0

主机 CPU“组件”在指派时将被“转换”为 VM Guest 中的虚拟 CPU。这些组件可能是：

4.5.2 VM Guest CPU 配置 #

 

本节介绍如何为 VM Guest 选择和配置 CPU 类型。您还将了解如何将虚拟 CPU 固定到主机系统上的物理 CPU。有关虚拟 CPU 配置和微调参数的详细信息，请参考 https://libvirt.org/formatdomain.html#elementsCPU 上的 libvirt 文档。

4.5.2.1 虚拟 CPU 型号和功能 #

 

可以为每个 VM Guest 单独指定 CPU 型号和拓扑。配置选项包括选择特定的 CPU 模型和排除某些 CPU 功能等。/usr/share/libvirt/cpu_map/ 目录中的文件列出了预定义的 CPU 型号。采用与主机类似的 CPU 型号和拓扑通常能提供最佳性能。可以通过运行 virsh capabilities 来显示主机系统 CPU 型号和拓扑。

请注意，如果更改了默认虚拟 CPU 配置，在将 VM Guest 迁移到硬件不同的主机时，需要关闭 VM Guest。有关 VM Guest 迁移的详细信息，请参见Book “虚拟化指南”, Chapter 11 “基本 VM Guest 管理”, Section 11.7 “迁移 VM Guest”。

要为 VM Guest 指定某个特定的 CPU 型号，请向 VM Guest 配置文件添加相应的项。下面的示例配置了具有固定 TSC 功能的 Broadwell CPU：

<cpu mode='custom' match='exact'>
  <model>Broadwell</model>
  <feature name='invtsc'/>
  </cpu>

对于与主机物理 CPU 最类似的虚拟 CPU，可以使用 <cpu mode='host-passthrough'>。请注意，host-passthrough CPU 型号可能与主机物理 CPU 并不完全相似，因为 KVM 默认会屏蔽任何不可迁移的功能。例如，invtsc 就不包含在虚拟 CPU 功能集中。虽然 libvirt 允许任意直通 KVM 命令行参数，但它并不直接支持更改默认 KVM 行为。仍以 invtsc 为例，您可以在 VM Guest 配置文件中使用以下命令行直通来实现主机 CPU（包括 invtsc） 的直通：

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
     <qemu:commandline>
     <qemu:arg value='-cpu'/>
     <qemu:arg value='host,migratable=off,+invtsc'/>
     </qemu:commandline>
     ...
     </domain>

注意：host-passthrough 模式

由于 host-passthrough 会向虚拟 CPU 公开物理 CPU 细节，因此无法迁移到不同的硬件。有关更多信息，请参见第 4.5.2.3 节 “虚拟 CPU 迁移注意事项”。

4.5.2.2 虚拟 CPU 固定 #

 

虚拟 CPU 固定用于将虚拟 CPU 线程限制到一组物理 CPU 。vcpupin 元素指定虚拟 CPU 可以使用的物理主机 CPU。如果未设置此元素且未指定 vcpu 元素的 cpuset 属性，则虚拟 CPU 可以自由使用任何物理 CPU。

虚拟 CPU 固定可提高物理 CPU 缓存命中率，对 CPU 密集型工作负载用处很大。要将虚拟 CPU 固定到特定的物理 CPU，请运行以下命令：

tux > virsh vcpupin DOMAIN_ID --vcpu vCPU_NUMBER
VCPU: CPU Affinity
----------------------------------
0: 0-7
root # virsh vcpupin SLE15 --vcpu 0 0 --config

最后一个命令会在 XML 配置中生成下面一项：

<cputune>
   <vcpupin vcpu='0' cpuset='0'/>
</cputune>

注意：NUMA 节点上的虚拟 CPU 固定

要将 VM Guest 的 CPU 和内存限制为一个 NUMA 节点，可以在 NUMA 系统上使用虚拟 CPU 固定和内存分配策略。有关 NUMA 微调的详细信息，请参见第 4.6 节 “NUMA 微调”。

警告：虚拟 CPU 固定和实时迁移

虽然 vcpupin 可以提高性能，但它可能会使实时迁移复杂化。有关虚拟 CPU 迁移注意事项的详细信息，请参见第 4.5.2.3 节 “虚拟 CPU 迁移注意事项”。

4.5.2.3 虚拟 CPU 迁移注意事项 #

 

选择包含所有最新功能的虚拟 CPU 型号可以提高 VM Guest 工作负载的性能，但通常会牺牲可迁移性。除非群集中的所有主机都包含最新的 CPU 功能，否则如果目标主机缺少新功能，迁移便可能会失败。如果比起最新的 CPU 功能，更为重要的是虚拟 CPU的可迁移性，那么应当使用标准化的 CPU 型号和功能集。virsh cpu-baseline 命令可帮助定义可以跨所有主机迁移的标准化虚拟 CPU。下面的命令（在迁移群集中的每台主机上运行时）会在 all-hosts-caps.xml 中说明所有主机功能的集合。

tux > sudo virsh capabilities >> all-hosts-cpu-caps.xml

您可以使用 virsh cpu-baseline 根据 all-hosts-caps.xml 中收集的每个主机的功能创建跨所有主机兼容的虚拟 CPU 定义。

tux > sudo virsh cpu-baseline all-hosts-caps.xml

生成的 CPU 定义可用作 VM Guest 配置文件中的 cpu 元素。

在逻辑层面上而言，虚拟 CPU 固定是一种硬件直通形式。固定会将物理资源与虚拟资源进行配对，也可能会给迁移带来问题。例如，如果请求的物理资源在目标主机上不可用，或者源主机与目标主机的 NUMA 拓扑不同，迁移将会失败。有关实时迁移的更多建议，请参见Book “虚拟化指南”, Chapter 11 “基本 VM Guest 管理”, Section 11.7.1 “迁移要求”。

NUMA 是 Non Uniform Memory Access（非一致性内存访问）的首字母缩写。NUMA 系统具有多个物理 CPU，每个 CPU 都附有本地内存。每个 CPU 还可以访问其他 CPU 的内存（称为“远程内存访问”），但速度比访问本地内存要慢得多。如果调节不当，NUMA 系统会对 VM Guest 性能造成负面影响。本节介绍了在 NUMA 主机上部署 VM Guest 时应当考虑的控制，不过最终微调取决于工作负载。在配置和部署 VM 时，始终要考虑主机拓扑。

SUSE Linux Enterprise Server 包含一个 NUMA 自动平衡器，该平衡器通过将内存放置在与处理它的 CPU 相同的 NUMA 节点上来尽力减少远程内存访问。此外，标准工具（例如 cgset）和虚拟化工具（例如 libvirt）提供了将 VM Guest 资源限制为物理资源的机制。

numactl 用于检查主机 NUMA 功能：

tux > sudo numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 72 73 74 75 76 77 78
79 80 81 82 83 84 85 86 87 88 89
node 0 size: 31975 MB
node 0 free: 31120 MB
node 1 cpus: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 90 91 92 93
94 95 96 97 98 99 100 101 102 103 104 105 106 107
node 1 size: 32316 MB
node 1 free: 31673 MB
node 2 cpus: 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 108 109 110
111 112 113 114 115 116 117 118 119 120 121 122 123 124 125
node 2 size: 32316 MB
node 2 free: 31726 MB
node 3 cpus: 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 126 127 128
129 130 131 132 133 134 135 136 137 138 139 140 141 142 143
node 3 size: 32314 MB
node 3 free: 31387 MB
node distances:
node   0   1   2   3
0:  10  21  21  21
1:  21  10  21  21
2:  21  21  10  21
3:  21  21  21  10

该 numactl 输出显示这是一个具有 4 个节点或单元的 NUMA 系统，每个节点或单元包含 36 个 CPU 和大约 32G 内存。virsh capabilities 也可用于检查系统 NUMA 功能和 CPU 拓扑。

4.6.1 NUMA 平衡 #

 

在 NUMA 计算机上，如果 CPU 访问远程内存，将会造成性能损失。NUMA 自动平衡功能会扫描任务的地址空间并取消页映射。这样做可以检测页是否正确放置，或者是否要将数据迁移到运行任务的本地内存节点。在定义的时间间隔内（使用 numa_balancing_scan_delay_ms 配置），该任务会扫描其地址空间中的下次扫描大小页数（使用 numa_balancing_scan_size_mb 配置）。在到达地址空间的末尾时，扫描器会从头重新开始。

较高的扫描率会导致较高的系统开销，因为必须捕获页错误，并需要迁移数据。但扫描率越高，当工作负载模式更改时，任务的内存迁移到本地节点的速度就越快。这样可最大限度减少远程内存访问对性能造成的影响。以下 sysctl 指令控制扫描延迟的阈值和扫描的页数：

tux > sudo sysctl -a | grep numa_balancing
kernel.numa_balancing = 11
kernel.numa_balancing_scan_delay_ms = 10002
kernel.numa_balancing_scan_period_max_ms = 600003
kernel.numa_balancing_scan_period_min_ms = 10004
kernel.numa_balancing_scan_size_mb = 2565

1	启用/禁用基于页错误的 NUMA 自动平衡
2	任务初始派生时用于任务的起始扫描延迟
3	扫描任务的虚拟内存的最大时间（以毫秒为单位）
4	扫描任务的虚拟内存的最小时间（以毫秒为单位）
5	某次给定的扫描需要扫描的页大小（以兆字节为单位）

有关更多信息，请参见Book “系统分析和微调指南”, Chapter 10 “自动平衡非一致性内存访问 (NUMA)”。

NUMA 自动平衡的主要目标是在相同节点的内存上重新安排任务（以便 CPU 跟随内存），或者将内存的页复制到相同的节点上（以便内存跟随 CPU）。

警告：任务布局

由于不同的任务之间可能会共享内存，因此并没有可定义运行任务的最佳位置的通用规则。为了获得最佳性能，建议将共享同一节点上的内存的任务分成一组。使用 # cat /proc/vmstat | grep numa_ 可查看 NUMA 统计信息。

4.6.2 使用 CPUset 控制器控制内存分配 #

 

cgroup cpuset 控制器可用于将进程使用的内存限制在一个 NUMA 节点。可用的 cpuset 内存策略模式有以下三种：

• interleave：此内存放置策略也称为轮替。对于需要将线程本地数据放到相应节点上的作业，此策略可提供显著的改进。当交错目标不可用时，它将被转移到另一个节点。

• bind：此策略仅将内存放到一个节点上，这意味着如果内存不足，分配将会失败。

• preferred：此策略应用首选项来向节点分配内存。如果此节点上没有足够的内存空间，则会回退到另一个节点。

您可以使用 cgset 工具（来自 libcgroup-tools 软件包）更改内存策略模式：

tux > sudo cgset -r cpuset.mems=NODE sysdefault/libvirt/qemu/KVM_NAME/emulator

要将页迁移到某个节点，请使用 migratepages 工具：

tux > migratepages PID FROM-NODE TO-NODE

要检查是否一切正常，请使用 cat /proc/PID/status | grep Cpus。

注意：内核 NUMA/cpuset 内存策略

有关详细信息，请参见内核 NUMA 内存策略和 cpusets 内存策略。另请查看 Libvirt NUMA Tuning（Libvirt NUMA 微调）文档。

4.6.3 VM Guest：NUMA 相关配置 #

 

libvirt 允许设置虚拟 NUMA 和内存访问策略。virt-install 或 virt-manager 不支持配置这些设置，需要使用 virsh edit 手动编辑 VM Guest 配置文件来完成该操作。

4.6.3.1 VM Guest 虚拟 NUMA 拓扑 #

 

创建类似于主机 NUMA 拓扑的 VM Guest 虚拟 NUMA (vNUMA) 通常可以提高传统的大型可扩展工作负载的性能。可以在 XML 配置中使用 numa 元素指定 VM Guest vNUMA 拓扑：

<cpu>
...
  <numa>
    <cell1 id="0"2 cpus='0-1'3 memory='512000' unit='KiB'/>
    <cell id="1" cpus='2-3' memory='256000'4
    unit='KiB'5 memAccess='shared'6/>
  </numa>
  ...
</cpu>

1	每个 cell 元素指定一个 vNUMA 单元或节点
2	所有单元都应具有 id 属性，用于在其他配置块中引用所需单元。如果没有，将按从 0 开始的升序为单元指派 ID。
3	属于节点一部分的 CPU 或 CPU 范围
4	节点内存
5	指定节点内存时所用的单位
6	可选属性，可控制将内存映射为共享还是私用。仅对支持大页的内存有效。

要查找 VM Guest 将其页分配到的位置，请使用 cat /proc/PID/numa_maps 和 cat /sys/fs/cgroup/memory/sysdefault/libvirt/qemu/KVM_NAME/memory.numa_stat.

警告：NUMA 规范

libvirt VM Guest NUMA 规范目前仅适用于 QEMU/KVM。

4.6.3.2 使用 libvirt 控制内存分配 #

 

如果 VM Guest 具有 vNUMA 拓扑（请参见第 4.6.3.1 节 “VM Guest 虚拟 NUMA 拓扑”），便可使用 numatune 元素将内存固定到主机 NUMA 节点。此方法目前仅适用于 QEMU/KVM Guest。请参见重要：非 vNUMA VM Guest了解如何配置非 vNUMA VM Guest。

<numatune>
    <memory mode="strict"1 nodeset="1-4,^3"2/>
    <memnode3 cellid="0"4 mode="strict" nodeset="1"/>
    <memnode cellid="2" placement="strict"5 mode="preferred" nodeset="2"/>
</numatune>

1	可用的策略包括 interleave（类似于轮替）、strict（默认）或 preferred。
2	指定 NUMA 节点。
3	指定每个 Guest NUMA 节点的内存分配策略（如果未定义此元素，则会回退并使用 memory 元素）。
4	对要应用设置的 Guest NUMA 节点寻址。
5	可以使用 placement 属性来指示域进程的内存放置模式，值可以是 auto 或 strict。

重要：非 vNUMA VM Guest

在非 vNUMA VM Guest 上，将内存固定到主机 NUMA 节点的命令如下例所示：

<numatune>
   <memory mode="strict" nodeset="0-1"/>
</numatune>

本例中从主机节点 0 和 1 分配内存。如果无法满足这些内存要求，启动 VM Guest 的操作将会失败。virt-install 也通过 --numatune 选项支持此配置。

警告：跨 NUMA 节点的内存和 CPU

您应当避免跨 NUMA 节点分配 VM Guest 内存，并防止虚拟 CPU 跨 NUMA 节点浮动。

QEMU 可识别源自其他虚拟化技术的某些储存格式。通过识别这些格式，QEMU 可以利用最初用于在这些其他虚拟化技术下运行的数据储存或整个 Guest。有些格式只支持只读模式。要以读取/写入模式使用它们，请使用 qemu-img 将它们转换为完全受支持的 QEMU 储存格式。否则，它们在 QEMU Guest 中将只能用作只读数据储存。

使用 qemu-img info VMGUEST.IMG 可获取有关现有映像的信息，例如格式、虚拟大小、物理大小、快照（如果有）。

注意：性能

建议将磁盘映像转换为 raw 或 qcow2 格式以获得较好的性能。

警告：无法压缩加密映像

创建映像时，无法在输出文件中使用压缩 (-c) 的同时指定加密选项 (-e)。

qcow2 和 qed 格式提供了一种创建基本映像（也称为后备文件）和在基本映像之上覆盖映像的方法。后备文件对于还原到已知状态并丢弃覆盖非常有用。如果向映像写入数据，后备映像将保持不变，所有更改都将记录在覆盖映像文件中。除非使用 commit 监视命令（或 qemu-img commit），否则后备文件永远都不会修改。

要创建覆盖映像，请运行以下命令：

root # qemu-img create -o1backing_file=vmguest.raw2,backing_fmt=raw3\
     -f4 qcow2 vmguest.cow5

警告：后备映像路径

您不应更改后备映像的路径，否则将需要对其进行调整。路径储存在覆盖映像文件中。要更新路径，应当创建一个从原始路径到新路径的符号链接，然后使用 qemu-img rebase 选项。

root # ln -sf /var/lib/images/vmguest.raw  /var/lib/images/SLE15/vmguest.raw
root # qemu-img rebase1-u2 -b3 /var/lib/images/vmguest.raw /var/lib/images/SLE15/vmguest.cow4

rebase 子命令告知 qemu-img 更改后备文件映像。-u 选项会激活不安全模式（请参见下面的注释）。使用 -b 来指定要使用的后备映像，映像路径是命令的最后一个参数。

rebase 有两种不同的运行模式：

• 安全：这是默认模式，执行真正的变基操作。安全模式是一种较为耗时的操作。

• 不安全：不安全模式 (-u) 只更改后备文件名和文件名的格式，而不检查文件的内容。如要重命名或移动后备文件，则应使用此模式。

常见的用法是使用后备文件来启动新的 Guest。假设我们有一个可以使用的 sle15_base.img VM Guest（未经任何修改的新安装）。这将是我们的后备文件。现在需要在更新后的系统和具有不同内核的系统上测试一个新软件包。我们可以使用 sle15_base.img，通过创建指向此后备文件 (sle15_base.img) 的 qcow2 覆盖文件来实例化新的 SUSE Linux Enterprise VM Guest。

在本例中，我们将为更新后的系统使用 sle15_updated.qcow2，为具有不同内核的系统使用 sle15_kernel.qcow2。

要创建这两个精简预配的系统，需使用带 -b 选项的 qemu-img 命令行：

root # qemu-img create -b /var/lib/libvirt/sle15_base.img -f qcow2 \
/var/lib/libvirt/sle15_updated.qcow2
Formatting 'sle15_updated.qcow2', fmt=qcow2 size=17179869184
backing_file='sle15_base.img' encryption=off cluster_size=65536
lazy_refcounts=off nocow=off
root # qemu-img create -b /var/lib/libvirt/sle15_base.img -f qcow2 \
/var/lib/libvirt/sle15_kernel.qcow2
Formatting 'sle15_kernel.qcow2', fmt=qcow2 size=17179869184
backing_file='vmguest-sle15_base.img' encryption=off cluster_size=65536
lazy_refcounts=off nocow=off

映像现在便可供使用，您可以在不变动初始 sle15_base.img 后备文件的情况下执行测试。所有更改都将储存在新的覆盖映像中。此外，您还可以使用这些新映像作为后备文件来创建新的覆盖。

root # qemu-img create -b sle15_kernel.qcow2 -f qcow2 sle15_kernel_TEST.qcow2

将 --backing-chain 选项与 qemu-img info 结合使用时，该命令将会递归返回关于整个后备链的所有信息：

root # qemu-img info --backing-chain
/var/lib/libvirt/images/sle15_kernel_TEST.qcow2
image: sle15_kernel_TEST.qcow2
file format: qcow2
virtual size: 16G (17179869184 bytes)
disk size: 196K
cluster_size: 65536
backing file: sle15_kernel.qcow2
Format specific information:
compat: 1.1
lazy refcounts: false

image: sle15_kernel.qcow2
file format: qcow2
virtual size: 16G (17179869184 bytes)
disk size: 196K
cluster_size: 65536
backing file: SLE15.qcow2
Format specific information:
compat: 1.1
lazy refcounts: false

image: sle15_base.img
file format: qcow2
virtual size: 16G (17179869184 bytes)
disk size: 16G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true

图 1︰ 理解映像覆盖 #

 

要访问映像的文件系统，请使用 guestfs-tools。如果系统上没有安装此工具，您可以使用其他 Linux 工具挂载映像。应避免访问不可信或未知的 VM Guest 的映像系统，因为这可能会导致安全问题（有关详细信息，请阅读 D. Berrangé 发布的帖子）。

5.3.1 打开 Raw 映像 #

 

过程 4︰ 挂载 Raw 映像 #

 

1. 要能够挂载映像，请找到一台空闲的循环设备。下面的命令会显示第一台未使用的循环设备（在本例中为 /dev/loop1）。

   root # losetup -f
   /dev/loop1

2. 将映像（在本例中为 SLE15.raw）与循环设备相关联：

   root # losetup /dev/loop1 SLE15.raw

3. 通过获取有关循环设备的详细信息来检查映像是否已成功与循环设备关联：

   root # losetup -l
   NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
   /dev/loop1         0      0         0  0    /var/lib/libvirt/images/SLE15.raw

4. 使用 kpartx 查看映像的分区：

   root # kpartx -a1 -v2 /dev/loop1
   add map loop1p1 (254:1): 0 29358080 linear /dev/loop1 2048

   1	添加分区设备映射。
   2	详细模式。

5. 现在挂载映像分区（在下面的示例中，挂载到 /mnt/sle15mount）：

   root # mkdir /mnt/sle15mount
   root # mount /dev/mapper/loop1p1 /mnt/sle15mount

注意：包含 LVM 的 Raw 映像

如果 raw 映像包含 LVM 卷组，您应当使用 LVM 工具挂载分区。有关详细信息，请参见 第 5.3.3 节 “打开包含 LVM 的映像”.

过程 5︰ 卸载 Raw 映像 #

 

1. 卸载映像的所有已挂载分区，例如：

   root # umount /mnt/sle15mount

2. 使用 kpartx 删除分区设备映射：

   root # kpartx -d /dev/loop1

3. 使用 losetup 解除设备关联：

   root # losetup -d /dev/loop1

您可以使用 filesystem 元素访问 VM Guest 中的主机目录。在下面的示例中，我们将共享 /data/shared 目录并将其挂载 VM Guest 中。请注意，对于 QEMU/KVM 驱动程序， accessmode 参数仅可与 type='mount' 搭配使用（ type 的大多数其他值专用于 LXC 驱动程序）。

<filesystem type='mount'1 accessmode='mapped'2>
   <source dir='/data/shared'3>
   <target dir='shared'4/>
</filesystem>

要在 VM Guest 上挂载 shared 目录，请使用以下命令：在 VM Guest 下，现在需要挂载 target dir='shared'：

root # mkdir /opt/mnt_shared
root # mount shared -t 9p /opt/mnt_shared -o trans=virtio

有关详细信息，请参见 libvirt 文件系统和 QEMU 9psetup。

为了提高 VM Guest 性能，建议在 VM Guest 中使用半虚拟化驱动程序。此类用于 KVM 的驱动程序的虚拟化标准是 virtio 驱动程序，它专为在虚拟环境中运行而设计。Xen 使用类似的半虚拟化设备驱动程序（例如 Windows* Guest 中的 VMDP）。

6.1.1 virtio blk #

 

virtio_blk 是磁盘的 virtio 块设备。要为块设备使用 virtio blk 驱动程序，请指定 bus='virtio' 属性（在 disk 定义中）：

<disk type='....' device='disk'>
    ....
    <target dev='vda' bus='virtio'/>
</disk>

重要：磁盘设备名称

virtio 磁盘设备命名为 /dev/vd[a-z][1-9]。如果从非 virtio 磁盘迁移 Linux Guest，您需要调整 GRUB 配置中的 root= 参数，并重新生成 initrd 文件，否则系统将无法引导。在运行其他操作系统的 VM Guest 上，可能还需要相应地调整或重新安装引导加载程序。

重要：通过 qemu-system-ARCH 使用 virtio 磁盘

运行 qemu-system-ARCH 时，请使用 -drive 选项来向 VM Guest 添加磁盘。请参见Book “虚拟化指南”, Chapter 34 “Guest 安装”, Section 34.1 “使用 qemu-system-ARCH 进行基本安装”中的示例。-hd[abcd] 选项不适用于 virtio 磁盘。

<interface type='network'>
    ...
    <model type='virtio' />
</interface>

<memory unit='KiB'>16777216</memory>
    <currentMemory unit='KiB'>1048576</currentMemory>
    [...]
    <devices>
        <memballoon model='virtio'/>
    </devices>

tux > virsh setmem DOMAIN_ID MEMORY in KB

tux > find /sys/devices/ -name virtio*
/sys/devices/pci0000:00/0000:00:06.0/virtio0
/sys/devices/pci0000:00/0000:00:07.0/virtio1
/sys/devices/pci0000:00/0000:00:08.0/virtio2

tux > find /sys/devices/ -name virtio* -print  -exec ls {}/block 2>/dev/null \;
/sys/devices/pci0000:00/0000:00:06.0/virtio0
/sys/devices/pci0000:00/0000:00:07.0/virtio1
/sys/devices/pci0000:00/0000:00:08.0/virtio2
vda

tux > udevadm info -p /sys/devices/pci0000:00/0000:00:08.0/virtio2
P: /devices/pci0000:00/0000:00:08.0/virtio2
E: DEVPATH=/devices/pci0000:00/0000:00:08.0/virtio2
E: DRIVER=virtio_blk
E: MODALIAS=virtio:d00000002v00001AF4
E: SUBSYSTEM=virtio

tux > find /sys/devices/ -name virtio* -print  -exec ls -l {}/driver 2>/dev/null \;
/sys/devices/pci0000:00/0000:00:06.0/virtio0
lrwxrwxrwx 1 root root 0 Jun 17 15:48 /sys/devices/pci0000:00/0000:00:06.0/virtio0/driver -> ../../../../bus/virtio/drivers/virtio_console
/sys/devices/pci0000:00/0000:00:07.0/virtio1
lrwxrwxrwx 1 root root 0 Jun 17 15:47 /sys/devices/pci0000:00/0000:00:07.0/virtio1/driver -> ../../../../bus/virtio/drivers/virtio_balloon
/sys/devices/pci0000:00/0000:00:08.0/virtio2
lrwxrwxrwx 1 root root 0 Jun 17 14:35 /sys/devices/pci0000:00/0000:00:08.0/virtio2/driver -> ../../../../bus/virtio/drivers/virtio_blk

tux > qemu-system-x86_64 -device virtio-net,help
virtio-net-pci.ioeventfd=on/off
virtio-net-pci.vectors=uint32
virtio-net-pci.indirect_desc=on/off
virtio-net-pci.event_idx=on/off
virtio-net-pci.any_layout=on/off
.....

为了获得 16 位色、高兼容性和更佳性能，建议使用 cirrus 视频驱动程序。

注意：libvirt

libvirt 会忽略 vram 值，因为视频大小已硬编码在 QEMU 中。

<video>
   <model type='cirrus' vram='9216' heads='1'/>
</video>

Virtio RNG（随机数字生成器）是作为硬件 RNG 设备向 Guest 公开的半虚拟化设备。在主机端，如果没有硬件支持，可以将其连接到多个熵来源之一（包括一台真正的硬件 RNG 设备和主机的 /dev/random）。Linux 内核包含 2.6.26 和更高版本的设备的 Guest 驱动程序。

系统熵收集自各种非确定性硬件事件，主要用于加密应用程序。虚拟随机数字生成器设备（半虚拟化设备）允许主机将熵传递到 VM Guest 操作系统。这将在 VM Guest 中产生更好的熵。

要使用 Virtio RNG，请在 virt-manager 中或直接在 VM Guest 的 XML 配置中添加 RNG 设备：

<devices>
   <rng model='virtio'>
       <backend model='random'>/dev/random</backend>
   </rng>
</devices>

主机现在应该在使用 /dev/random：

tux > lsof /dev/random
qemu-syst 4926 qemu    6r   CHR    1,8      0t0 8199 /dev/random

在 VM Guest 上，可使用以下命令检查熵的来源：

tux > cat /sys/devices/virtual/misc/hw_random/rng_available

可使用以下命令检查当前用于熵的设备：

tux > cat /sys/devices/virtual/misc/hw_random/rng_current
virtio_rng.0

您应在 VM Guest 上安装 rng-tools 软件包，启用该服务，然后将其启动。在 SUSE Linux Enterprise Server 15 下，执行以下命令：

root # zypper in rng-tools
root # systemctl enable rng-tools
root # systemctl start rng-tools

对每台主机应仅使用一种虚拟化技术。例如，不要在同一台主机上使用 KVM 和 Xen。否则可能会出现可用资源减少、安全风险增加，以及软件更新队列变长的问题。即使仔细配置了分配给每种技术的资源量，主机也可能会出现整体可用性降低和性能下降的情况。

应尽量减少主机上可用的软件和服务的数量。大多数默认安装的操作系统都没有针对 VM 的使用进行优化。因此请安装真正需要的组件，并去除 VM Guest 中的所有其他组件。

Windows* Guest：

Linux Guest：

QEMU 计算机类型定义与迁移和会话管理尤为相关的体系结构细节。随着对 QEMU 的更改或改进，新的计算机类型将会增加。出于兼容性原因，旧计算机类型仍然受支持，但是为了利用改进的功能，我们建议在升级时一律迁移到最新的计算机类型。

为 Linux Guest 更改 Guest 的计算机类型基本上是透明的。对于 Windows* Guest，我们建议截取 Guest 的快照或备份 Guest，以防出现 Windows* 在其检测到的更改的计算机类型上运行时有问题，随后用户决定还原到创建 Guest 时使用的原始计算机类型的情况。

注意：更改计算机类型

相关文档，请参见Book “虚拟化指南”, Chapter 15 “使用 virsh 配置虚拟机”, Section 15.2 “更改计算机类型”。

能否更改 VM Guest 的状态在很大程度上取决于操作系统。在生产环境中使用 VM Guest 之前，务必要测试此功能。例如，大多数 Linux 操作系统默认会禁用此功能，因此需要启用此操作（通常通过 PolKit）。

必须在 Guest 中启用 ACPI 才能正常关机。要检查是否已启用 ACPI，请运行以下命令：

tux > virsh dumpxml VMNAME | grep acpi

如果没有列显任何内容，则说明计算机上没有启用 ACPI。使用 virsh edit 在 XML 的 <domain> 下添加以下内容：

<features>
   <acpi/>
</features>

如果 ACPI 是在 Windows Server* Guest 安装期间启用的，那么仅在 VM Guest 配置中开启它并不够。有关更多信息，请参见 https://support.microsoft.com/en-us/kb/309283。

无论 VM Guest 的配置如何，始终都可以从 Guest 操作系统内部实现正常关机。

尽管您可以使用 qemu-system-ARCH 命令来指定键盘布局，但仍建议在 libvirt XML 文件中配置键盘布局。要在使用 vnc 连接到远程 VM Guest 时更改键盘布局，应编辑 VM Guest XML 配置文件。例如，要添加 en-us 键映射，请在 <devices> 部分添加：

<graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>

检查 vncdisplay 配置并连接到 VM Guest：

tux > virsh vncdisplay sles15 127.0.0.1:0

如果主机上除了 lo 以外没有为其他网络接口指派 IPv4 地址，spice 服务器监听的默认地址将不起作用。将会出现如下错误：

tux > virsh start sles15
error: Failed to start domain sles15
error: internal error: process exited while connecting to monitor: ((null):26929): Spice-Warning **: reds.c:2330:reds_init_socket: getaddrinfo(127.0.0.1,5900): Address family for hostname not supported
2015-08-12T11:21:14.221634Z qemu-system-x86_64: failed to initialize spice server

要修复此问题，可以使用本地 IPv6 地址 ::1 更改 /etc/libvirt/qemu.conf 中的默认 spice_listen 值。您也可以为每个 VM Guest 更改 spice 服务器监听地址，使用 virsh edit 向 graphics type='spice' 元素添加监听 XML 属性：

<graphics type='spice' listen='::1' autoport='yes'/>>

有时，使用 QEMU 命令行从 XML 文件启动 VM Guest 可能很有用。

tux > virsh domxml-to-native1 qemu-argv2 SLE15.xml3

tux > sudo virsh domxml-to-native qemu-argv /etc/libvirt/qemu/SLE15.xml
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
   QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name SLE15 -machine \
   pc-i440fx-2.3,accel=kvm,usb=off -cpu SandyBridge -m 4048 -realtime \
   mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 8616d00f-5f05-4244-97cc-86aeaed8aea7 \
   -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/SLE15.monitor,server,nowait \
   -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew \
   -global kvm-pit.lost_tick_policy=discard -no-hpet \
   -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 \
   -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 \
   -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 \
   -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 \
   -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 \
   -drive file=/var/lib/libvirt/images/SLE15.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none \
   -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 \
   -drive if=none,id=drive-ide0-0-1,readonly=on,format=raw  \
   -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,id=hostnet0  \
   -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:28:04:a9,bus=pci.0,addr=0x3,bootindex=1 \
   -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 \
   -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
   -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on

要基于 XML 文件创建新的 VM Guest，可使用特殊标记 qemu:commandline 来指定 QEMU 命令行。例如，要添加 virtio-balloon-pci，请在 XML 配置文件的末尾（</domain> 标记之前）添加此块：

<qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='virtio-balloon-pci,id=balloon0'/>
</qemu:commandline>