云计算虚拟化Libvirt Domain XML Format中文版—对照学习使用

说明

笔者于2023-2024年参与了云计算IaaS相关功能开发，需学习虚拟化、Libvirt 、KVM相关知识，对过往中使用的libvirt 内容进行翻译、方便使用和对照，现将内容共享。
内容中部分截图不方便倒腾，已删去原图。
联系方式： john2023@qq.com

资料源：

https://libvirt.org/formatdomain.html#general-metadata

部分术语及libvirt目标

为避免所用术语的歧义，以下是一些 libvirt 文档中使用的特定概念：(部分来源:redhat官方介绍https://www.redhat.com/zh/topics/virtualization)

• 节点(node)是单个物理机器
• 虚拟机监控程序(hypervisor)是一层(种)软件，允许将节点虚拟化为一组虚拟机(创建并运行VM)，这些虚拟机可能具有与节点本身不同的配置。——也叫VMM(Virtual Machine Monitor, 虚拟机监控器)
• 域(domain)是在由虚拟化监控程序提供的虚拟机上运行的网络实例(或在容器虚拟化情况下为子系统)。

注1：配备了虚拟机监控程序的物理硬件叫做主机(Host)，而使用其资源的虚拟机成为客户机(Guest)。这些虚拟客户机将计算资源(如 CPU、内存和存储器)视为一组可进行重新分配的资源。操作员可以控制 CPU、内存、存储器和其他资源的虚拟实例，以便虚拟客户机能在需要时收到所需资源。

libvirt 是目前使用最为广泛的对 KVM 虚拟机进行管理的工具和应用程序接口（API），而且一些常用的虚拟机管理工具（如virsh、virt-install、virt-manager等）和云计算框架平台（如 OpenStack、OpenNebula、Eucalyptus 等）都在底层使用 libvirt 的应用程序接口。

libvirt 是为了更方便地管理平台虚拟化技术而设计的开放源代码的应用程序接口、守护进程和管理工具，它不仅提供了对虚拟化客户机的管理，也提供了对虚拟化网络和存储的管理。尽管 libvirt 项目最初是为 Xen 设计的一套API，但是目前对KVM等其他 Hypervisor 的支持也非常的好。libvirt 支持多种虚拟化方案，既支持包括 KVM、QEMU、Xen、VMware、VirtualBox 等在内的平台虚拟化方案，又支持 OpenVZ、LXC 等 Linux 容器虚拟化系统，还支持用户态 Linux（UML）的虚拟化。

libvirt 作为中间适配层，让底层 Hypervisor 对上层用户空间的管理工具是可以做到完全透明的，因为 libvirt 屏蔽了底层各种 Hypervisor 的细节，为上层管理工具提供了一个统一的、较稳定的接口（API）。通过 libvirt，一些用户空间管理工具可以管理各种不同的 Hypervisor 和上面运行的客户机。

libvirt 的管理功能主要包含如下五个部分：

• 域的管理：包括对节点上的域的各个生命周期的管理，如：启动、停止、暂停、保存、恢复和动态迁移。也包括对多种设备类型的热插拔操作，包括：磁盘、网卡、内存和 CPU，当然不同的 Hypervisor 上对这些热插拔的支持程度有所不同。

• 远程节点的管理：只要物理节点上运行了 libvirtd 这个守护进程，远程的管理程序就可以连接到该节点进程管理操作，经过认证和授权之后，所有的 libvirt 功能都可以被访问和使用。libvirt 支持多种网络远程传输类型，如 SSH、TCP 套接字、Unix domain socket、支持 TLS 的加密传输等。假设使用最简单的 SSH，则不需要额外配置工作，比如：example.com 节点上运行了 libvirtd，而且允许 SSH 访问，在远程的某台管理机器上就可以用如下的命令行来连接到 example.com 上，从而管理其上的域。

  virsh -c qemu+ssh://root@example.com/system
  

• 存储的管理：任何运行了 libvirtd 守护进程的主机，都可以通过 libvirt 来管理不同类型的存储，如：创建不同格式的客户机镜像（qcow2、raw、qde、vmdk等）、挂载 NFS 共享存储系统、查看现有的 LVM 卷组、创建新的 LVM 卷组和逻辑卷、对磁盘设备分区、挂载 iSCSI 共享存储，等等。当然 libvirt 中，对存储的管理也是支持远程管理的。

• 网络的管理：任何运行了 libvirtd 守护进程的主机，都可以通过libvirt来管理物理的和逻辑的网络接口。包括：列出现有的网络接口卡，配置网络接口，创建虚拟网络接口，网络接口的桥接，VLAN 管理，NAT 网络设置，为客户机分配虚拟网络接口，等等。

• 提供一个稳定、可靠、高效的**应用程序接口（API）**以便可以完成前面的 4 个管理功能。

libvirt 主要由三个部分组成，它们分别是：应用程序编程接口（API）库、一个守护进程（libvirtd）和一个默认命令行管理工具（virsh）。应用程序接口（API）是为了其他虚拟机管理工具（如 virsh、virt-manager等）提供虚拟机管理的程序库支持。libvirtd 守护进程负责执行对节点上的域的管理工作，在用各种工具对虚拟机进行管理之时，这个守护进程一定要处于运行状态中，而且这个守护进程可以分为两种：一种是 root 权限的libvirtd，其权限较大，可以做所有支持的管理工作；一种是普通用户权限的 libvirtd，只能做比较受限的管理工作。virsh 是 libvirt 项目中默认的对虚拟机管理的一个命令行工具。

现在我们可以定义libvirt的目标：提供一个通用且稳定的层足以安全地管理节点上的域。

因此，libvirt 应该提供进行管理所需的所有 API，包括： 在虚拟机监控程序对这些操作的支持范围内，对域进行预配、创建、修改、监控、控制、迁移和停止。并非所有虚拟机监控程序都提供相同的操作；但如果某个操作对于至少一个特定虚拟机的域管理是有用的，那么在 libvirt 中提供这个操作是值得的。可以使用 libvirt 同时访问多个节点，但 API仅限于单个节点操作。节点资源操作是libvirt API范围的一部分，用于域的管理和预配，例如接口设置、防火墙规则、存储管理和通用预配API。Libvirt还将提供实现管理策略所需的状态监视API，不仅可以检查域状态，也可以公开本地节点的资源消耗。

这意味着以下子目标：

• 所有API都可以通过安全的API远程携带
• 虽然大多数 API 在虚拟机监控程序或主机操作系统方面都是通用的，但某些 API 可能针对单个虚拟化环境，只要语义对于从域管理角度进行操作是明确的
• API 应该允许高效、干净地执行管理节点上的域所需的所有操作，包括资源预置和设置
• API 不会尝试提供高级虚拟化策略或多节点管理功能，如负载平衡，但API应该足够支持在libvirt之上实现这些功能。
• API的稳定性是一个大问题，libvirt应该将应用程序与虚拟化框架较低级别预期的频繁更改隔离开来
• 被管理的节点可能位于与使用libvirt的hypervisor不同的物理机器上，因此libvirt支持远程访问，但只能通过使用安全协议来实现。
• libvirt将提供API来枚举、监视和使用托管节点上可用的资源，包括CPU、内存、存储、网络和NUMA分区。

因此，libvirt旨在成为更高级别管理工具和专注于单个节点虚拟化的应用程序的构建块(唯一的例外是涉及多个节点的节点之间的域迁移功能)。

域XML格式(Domain XML Format)

本节介绍了用于表示域的XML格式，根据运行的域的类型和用于启动域的选项，该格式有多种变体。有关hypervisor特定的详细信息，需参阅驱动程序文档:driver docs

注1：域(Domain) = VMInstance = 虚拟机 = guest客户机(个人理解)

1. 元素和属性概述(Element and attribute overview)

所有虚拟机所需的根元素都命名为 domain 。它有两个属性，type指定用于运行域的hypervisor。允许的值是特定于驱动程序的，包括"xen"、“kvm”、“hvf”(自8.1.0和QEMU 2.12起)、“QEMU"和"lxc”。第二个属性是id，它是运行的客户机(GUEST MACHINE，物理机上运行的虚拟机实例)的唯一整数标识符(unique integer identifier， UID)。非活动计算机没有id值。

1.1 通用元数据(General metadata)

<domain type='kvm' id='1'>
  <name>MyGuest</name>
  <uuid>4dea22b3-1d52-d8f3-2516-782e98ab3fa0</uuid>
  <genid>43dc0cf8-809b-4adb-9bea-a9abb5f3d90e</genid>
  <title>A short description - title - of the domain</title>
  <description>Some human readable description</description>
  <metadata>
    <app1:foo xmlns:app1="http://app1.org/app1/">..</app1:foo>
    <app2:bar xmlns:app2="http://app1.org/app2/">..</app2:bar>
  </metadata>
  ...

name

​ name元素的内容提供虚拟机的短名称。该名称应仅由字母数字字符组成，并且要求在单个主机范围内是唯一的。它通常用于构成存储持久配置文件的文件名。 从0.0.1开始

uuid

​ uuid元素的内容为虚拟机提供全局唯一标识符(Universally Unique IDentifier)。该格式必须符合 RFC 4122规范，例如 3e3fce45-4f53-4fa7-bb32-11f34168b82b。如果在定义/创建新机器时省略，则会生成随机 UUID。还可以通过SMBIOS 系统信息(1.3章节)规范提供 UUID。从0.0.1开始，sysinfo从0.8.7开始

genid

​ 自从4.4.0版本，genid元素可以用来添加虚拟机生成ID，该ID使用与uuid相同的格式公开128位加密随机整数值标识符，称为全局唯一标识符(GUID)。该值用于帮助在虚拟机重新执行已经执行过的操作时，通知guest OS(虚拟机中的操作系统)，例如：

• VM starts executing a snapshot—VM 开始执行快照

• VM is recovered from backup—虚拟机已从备份中恢复

• VM is failover in a disaster recovery environment—

  VM 在灾难恢复环境中进行故障转移

• VM is imported， copied， or cloned—虚拟机已导入、复制或克隆

​ guest OS会注意到这种变化，然后根据需要采取适当的反应，例如将其分布式数据库的副本标记为脏数据，重新初始化其随机数生成器等。

​ libvirt XML解析器会接受提供的GUID值，或者只是使用 ，在这种情况下，将生成一个GUID并保存在XML中。对于上述的转换，libvirt会在重新执行之前更改GUID。

titile

​ 可选的元素title为域的简短描述提供了空间。标题不应包含任何换行符。从0.9.10起。

description

​ description元素的内容提供了虚拟机的可读描述，libvirt 不会以任何方式使用此数据，它可以包含用户想要的任何信息。从0.7.2开始

metadata

​ 应用程序可以使用metadata节点以XML节点/树的形式存储自定义元数据。应用程序必须在其XML节点/树上使用自定义名称空间，每个名称空间只有一个顶级元素(如果应用程序需要结构，则它们的命令空间元素应该具有子元素)。自0.9.10起

1.2 操作系统启动(Operating system booting)

启动虚拟机的方法有很多种，每种方法都有各自的优点和缺点

1.2.1 BIOS引导加载程序(BIOS bootloader)

支持完全虚拟化的虚拟机监控程序可通过 BIOS 进行引导。在这种情况下，BIOS 有一个引导顺序优先级(软盘、硬盘、CDROM、网络)，用于确定在哪里获取/查找引导映像。

<!-- Xen with fullvirt loader -->
...
<os>
  <type>hvm</type>
  <loader>/usr/lib/xen/boot/hvmloader</loader>
  <boot dev='hd'/>
</os>
...

<!-- QEMU with default firmware， serial console and SMBIOS -->
...
<os>
  <type>hvm</type>
  <boot dev='cdrom'/>
  <bootmenu enable='yes' timeout='3000'/>
  <smbios mode='sysinfo'/>
  <bios useserial='yes' rebootTimeout='0'/>
</os>
...

<!-- QEMU with UEFI manual firmware and secure boot -->
...
<os>
  <type>hvm</type>
  <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
  <nvram template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/nvram/guest_VARS.fd</nvram>
  <boot dev='hd'/>
</os>
...

<!-- QEMU with UEFI manual firmware， secure boot and with NVRAM type 'file'-->
...
<os>
  <type>hvm</type>
  <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
  <nvram type='file' template='/usr/share/OVMF/OVMF_VARS.fd'>
    <source file='/var/lib/libvirt/nvram/guest_VARS.fd'/>
  </nvram>
  <boot dev='hd'/>
</os>
...

<!-- QEMU with UEFI manual firmware， secure boot and with network backed NVRAM'-->
...
<os>
  <type>hvm</type>
  <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
  <nvram type='network'>
    <source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/0'>
      <host name='example.com' port='6000'/>
      <auth username='myname'>
        <secret type='iscsi' usage='mycluster_myname'/>
      </auth>
    </source>
  </nvram>
  <boot dev='hd'/>
</os>
...

<!-- QEMU with automatic UEFI firmware and secure boot -->
...
<os firmware='efi'>
  <type>hvm</type>
  <loader secure='yes'/>
  <boot dev='hd'/>
</os>
...

<!-- QEMU with automatic UEFI stateless firmware for AMD SEV -->
...
<os firmware='efi'>
  <type>hvm</type>
  <loader stateless='yes'/>
  <boot dev='hd'/>
</os>
...

firmware 固件

​ firmware属性允许管理应用程序自动填充和元素，并可能启用所选固件所需的一些功能。可接受的值为bios和efi。选择过程在指定位置扫描描述已安装固件映像的文件，并使用满足域要求的最特定的文件。按偏好顺序(从一般到最具体)的位置为：

/usr/share/qemu/firmware
/etc/qemu/firmware
$XDG_CONFIG_HOME/qemu/firmware

​ 有关更多信息，请参阅QEMU存储库中docs/interop/firmware.json中描述的固件元数据规范。普通用户无需关心。自5.2.0(仅限QEMU和KVM)对于VMware客户，当客户使用UEFI时，此设置为efi，而在使用BIOS时未设置。自5.3.0起(VMware ESX和Workstation/Player)

注1：UEFI，全称为"统一的可扩展固件接口"(Unified Extensible Firmware Interface)，是一种用于计算机启动的开放标准。它取代了传统的BIOS(Basic Input/Output System)固件，作为现代计算机系统的引导方式。可以提供更强大的虚拟化能力，支持更高效的虚拟机管理和部署。

type

​ type元素的内容指定要在虚拟机中启动(引导)的操作系统的类型。hvm表示操作系统是设计为在裸金属上运行的，因此需要完全虚拟化。linux(命名不佳！)指的是一个支持Xen3 hypervisor(虚拟机监控程序)客户机ABI的操作系统。还有两个可选属性，arch指定要虚拟化的CPU架构，machine指的是机器类型。Capabilities XML提供了有关这些属性的允许值的详细信息。如果省略了arch，那么对于大多数hypervisor驱动程序，将选择主机本机架构。然而，对于test、ESX和VMWare虚拟机监控程序驱动程序，即使在x86_64主机上，也将始终选择i686 架构。自0.0.1起

注1：i686 架构是一种基于 Intel 80386 微处理器的 x86 架构的扩展。它是 x86 架构的一部分，通常被称为 “IA-32” 架构，是最常见的个人计算机和服务器体系结构之一。i686 架构支持 32 位处理器操作，包括各种指令集和功能，如浮点运算、多媒体扩展等。i686 架构是在原始的 8086 架构基础上发展起来的，通过多代处理器的改进和扩展而形成。这些改进包括增加寄存器、更高的时钟频率、更大的内存访问能力等。i686 架构也支持多任务处理和虚拟内存管理，使操作系统和应用程序能够更高效地运行。

firmware

​ 仅自 7.2.0 QEMU/KVM 起

​ 使用固件自动选择时，固件中会启用不同的功能。功能列表可用于限制应为虚拟机自动选择哪些固件。可以使用零个或多个feature元素指定功能列表。在选择固件时，Libvirt将只考虑列出的功能，而忽略其余功能。

​ feature

​ 强制列表属性：

• enabled(可接受的值为yes和no)用于告知libvirt是否必须在自动选择的固件中启用该功能
• name功能的名称，功能列表：
  • enrolled-keys(已注册密钥)所选nvram模板是否已注册默认证书。具有安全引导(启动)功能但没有注册密钥的固件也将成功引导未签名的二进制文件。仅对具有安全启动功能的固件有效。
  • secure-boot固件是否实现UEFI安全启动功能

loader加载程序

​ 可选的loader标记是指由绝对路径指定的固件 blob，用于协助域创建过程。它由 Xen 完全虚拟化域以及为 QEMU/KVM 域设置 QEMU BIOS 文件路径使用。Xen 自 0.1.0 起，QEMU/KVM 自 0.9.12 起。然后， 自 1.2.8 起，元素可以有两个可选属性：readonly(接受的值为yes和no)以反映镜像应该可写或只读。第二个属性type接受值rom和pflash。它告诉hypervisor应该映射到客户机内存中的哪个位置。例如，如果加载程序路径指向 UEFI 映像，则类型应为pflash。此外，某些固件可能会实现安全启动功能。属性secure可用于告诉hypervisor固件具有安全启动功能。它不能用于启用或禁用固件中的功能本身。 从 2.1.0 开始。如果加载程序被标记为只读，则使用 UEFI 时，假定将有一个可写的 NVRAM 可用。然而，在某些情况下，加载程序可能需要在没有任何 NVRAM 的情况下运行，从而在关闭时丢弃任何配置更改。stateless(无状态)标志(自 8.6.0) 可用于控制此行为，当设置为yes时，将永远不会创建 NVRAM。

​ 启用固件自动选择后，format属性可用于告诉 libvirt 仅考虑特定格式的固件版本。支持的值为raw和qcow2。 自 9.2.0 起(仅限 QEMU)

nvram----非易失性随机存取存储器(Non-Volatile Random-Access Memory)断电后数据保持不变

​ 一些 UEFI 固件可能想要使用非易失性存储器来存储一些变量。在主机中，这表示为文件，并且文件的绝对路径存储在该元素中。此外，当域启动时，libvirt 会复制qemu.conf中定义的所谓主 NVRAM 存储文件。如果需要，模板属性可用于配置文件中主 NVRAM 存储的每个域覆盖映射。请注意，对于瞬态域，如果 NVRAM 文件是由 libvirt 创建的，那么该文件将被保留下来，由管理应用程序负责保存和删除文件(如果需要持久化)。从1.2.8开始

​ 从 8.5.0 开始，元素可以具有type属性(接受值file、block和network )，在这种情况下，NVRAM 存储由子元素描述，其语法与disk的源相同 。请参阅1.20.1Hard drives, floppy disks, CDROMs

​ 注意： network支持的 NVRAM 变量不是从template实例化的，用户有责任提供有效的 NVRAM 映像。

​ 该元素支持format属性，该属性与元素的同名属性具有相同的语义。 自 9.2.0 起(仅限 QEMU)

​ 如果加载器被标记为无状态，则提供此元素是无效的。

**注1：**瞬态域(Transient Domain)是指在虚拟化环境中创建的一种临时性的虚拟机实例。与持久性域(Persistent Domain)不同，瞬态域在虚拟机关闭后通常不会保留其状态或数据，而是在关闭后会被删除或重置。主要用于临时性任务和测试目的。

boot 启动/引导

​ dev属性采用值"fd"、“hd”、"cdrom"或"network"之一，用于指定要考虑的下一个引导设备。boot元素可以重复多次，以设置启动设备的优先级列表，依次尝试不同的引导设备。相同类型的多个设备根据其目标进行排序，同时保留总线的顺序。定义域后，libvirt(通过 virDomainGetXMLDesc)返回的 XML 配置按排序顺序列出设备。排序后，第一个设备将被标记为可启动。因此，例如，一个配置为从"hd"引导的域，分配了vdb、hda、vda和hdc磁盘给它，将从vda引导(按照排序后的列表顺序为vda、vdb、hda、hdc)。具有 hdc、vda、vdb 和 hda 磁盘的类似域将从 hda 启动(排序的磁盘为：hda、hdc、vda、vdb)。以所需的方式进行配置可能很棘手，这就是为什么引入了每个设备的引导元素(请参阅1.20.1 Hard drives, floppy disks, CDROMs, Network interfaces, 以及下面的1.20.8 Host device assignment 部分)，它们是提供完全控制引导顺序的首选方式。boot元素和每个设备引导元素是互斥的 。从 0.1.3 开始，从 0.8.8 开始 per-device boot

smbios

​ 如何填充客户端中可见的 SMBIOS 信息。必须指定mode属性，并且可以是"emulate" “模拟”(让hypervisor虚拟机监控程序生成所有值)、“host”(除了 UUID， 从主机的 SMBIOS 值复制所有块 0 和块 1；virConnectGetSysinfo 调用 可以用于查看复制了哪些值)或"sysinfo"(使用 SMBIOS System Information元素中的值)。如果未指定，则使用虚拟机监控程序默认值。从0.8.7开始

到目前为止，BIOS/UEFI 配置选项已经足够通用，可以被大多数(如果不是全部)固件实现。然而，从现在开始，并非每个设置对所有固件都有意义。例如， rebootTimeout对于 UEFI 没有意义，useserial可能无法在不向串行线路上产生任何输出的 BIOS 固件上使用，等等。此外，固件通常不会为 libvirt(或用户)公开其功能以供检查。并且其功能集合可能会随着每个新版本的发布而改变。因此，建议用户在生产环境之前先尝试他们使用的设置，以确保他们可靠。

bootmenu

​ 是否在虚拟机启动时启用交互式启动菜单提示。enable属性可以是"yes"或"no"。如果未指定，将使用hypervisor的默认值。自0.8.3版本起，还增加了timeout属性，它表示启动菜单等待超时的毫秒数。允许的值是范围在[0， 65535]内的数字，除非enable设置为"yes"，否则将被忽略。自1.2.8版本起。

bios

​ 该元素具有属性userserial，其可能值为yes或 no。它启用或禁用串行图形适配器，允许用户在串行端口上查看 BIOS 消息。因此，需要定义串行端口 。从 0.9.4 开始。从 0.10.2(仅限 QEMU)开始，还有另一个属性，rebootTimeout用于控制在启动失败的情况下客户机是否应重新启动以及在多长时间后重新启动(根据 BIOS)。该值以毫秒为单位，最大值为65535，特殊值-1将禁用重新启动。

1.2.2 主机引导加载程序(Host bootloader)

采用半虚拟化的Hypervisor通常不会模拟BIOS，而是由主机负责启动操作系统。这可以使用主机中的伪引导加载程序来提供为客户机选择内核的接口。一个例子是使用Xen的pygrub。Bhyve hypervisor还使用主机引导加载程序，可以是bhyveload或grub Bhyve。

...
<bootloader>/usr/bin/pygrub</bootloader>
<bootloader_args>--append single</bootloader_args>
...

bootloader引导加载程序

​ bootloader元素的内容为在主机OS中可执行的引导加载程序提供了完全限定的路径。将运行此引导加载程序来选择要引导的内核。引导加载程序所需的输出取决于所使用的hypervisor。自0.1.0

bootloader_args

​ 可选的bootloader_args元素允许将命令行参数传递给bootloader。自0.2.3

1.2.3 直接内核引导(Direct kernel boot)

在安装新的guest OS时，直接从主机操作系统中存储的内核和initrd(初始化内存盘)启动通常很有用，这样可以将命令行参数直接传递给安装程序。此功能通常可用于半虚拟化和完全虚拟化的guest OS。

...
<os>
  <type>hvm</type>
  <loader>/usr/lib/xen/boot/hvmloader</loader>
  <kernel>/root/f8-i386-vmlinuz</kernel>
  <initrd>/root/f8-i386-initrd</initrd>
  <cmdline>console=ttyS0 ks=http://example.com/f8-i386/os/</cmdline>
  <dtb>/root/ppc.dtb</dtb>
  <acpi>
    <table type='slic'>/path/to/slic.dat</table>
  </acpi>
</os>
...

type

​ 该元素具有与前面 BIOS bootloader部分中描述的语义相同的语义。

loader

​ 该元素具有与前面 BIOS bootloader部分中描述的语义相同的语义。

kernel

​ 此元素的内容指定主机操作系统中内核镜像的完全限定路径。

initrd

​ 此元素的内容指定主机操作系统中(可选)ramdisk镜像的完全限定路径

cmdline

​ 此元素的内容指定在启动时传递给内核(或安装程序)的参数。这通常用于指定备用主控制台(例如串行端口)或安装媒体源/kickstart文件

dtb

​ 此元素的内容指定主机操作系统中(可选)设备树二进制(dtb，device table binary)映像的完全限定路径。自1.0.4

acpi

​ table元素包含ACPI表的完全限定路径。type属性包含ACPI表类型(目前只支持slic)自1.3.5(QEMU)自5.9.0(Xen)

1.2.4 容器引导(Container boot)

当使用基于容器的虚拟化而不是内核/引导映像来引导域时，需要使用init元素的init二进制文件路径。默认情况下，这将在没有参数的情况下启动。要指定初始argv，请使用initarg元素，根据需要重复多次。cmdline元素(如果设置)将用于提供与/proc/cmdline等效的值，但不会影响init argv。

要设置环境变量，请使用initenv元素，每个变量一个。

要为init设置自定义工作目录，请使用initdir元素。

要以给定用户或组的身份运行init命令，请分别使用inituser或initgroup元素。这两个元素都可以提供用户(resp.group)id或名称。在用户或组id前面加一个+将强制将其视为一个数值。如果没有这一点，它将首先作为用户名或组名进行尝试。

<os>
  <type arch='x86_64'>exe</type>
  <init>/bin/systemd</init>
  <initarg>--unit</initarg>
  <initarg>emergency.service</initarg>
  <initenv name='MYENV'>some value</initenv>
  <initdir>/my/custom/cwd</initdir>
  <inituser>tester</inituser>
  <initgroup>1000</initgroup>
</os>

如果要启用用户命名空间，请设置idmap元素。uid和gid元素有三个属性：

start

​ 容器中的第一个用户ID。它必须是"0"。

target

​ 容器中的第一个用户ID将映射到主机中的此目标用户ID。

count

​ 容器中允许映射到主机用户的用户数。

<idmap>
  <uid start='0' target='1000' count='10'/>
  <gid start='0' target='1000' count='10'/>
</idmap>

1.3 SMBIOS系统信息(SMBIOS System Information)

一些hypervisor允许控制向虚拟机呈现什么系统信息(例如，hypervisor可以填充SMBIOS字段，并通过虚拟机内的dmidecode命令进行检查)。可选的 sysinfo 元素涵盖了所有这些信息类别。自0.8.7

...
<os>
  <smbios mode='sysinfo'/>
  ...
</os>
<sysinfo type='smbios'>
  <bios>
    <entry name='vendor'>LENOVO</entry>
  </bios>
  <system>
    <entry name='manufacturer'>Fedora</entry>
    <entry name='product'>Virt-Manager</entry>
    <entry name='version'>0.9.4</entry>
  </system>
  <baseBoard>
    <entry name='manufacturer'>LENOVO</entry>
    <entry name='product'>20BE0061MC</entry>
    <entry name='version'>0B98401 Pro</entry>
    <entry name='serial'>W1KS427111E</entry>
  </baseBoard>
  <chassis>
    <entry name='manufacturer'>Dell Inc.</entry>
    <entry name='version'>2.12</entry>
    <entry name='serial'>65X0XF2</entry>
    <entry name='asset'>40000101</entry>
    <entry name='sku'>Type3Sku1</entry>
  </chassis>
  <oemStrings>
    <entry>myappname:some arbitrary data</entry>
    <entry>otherappname:more arbitrary data</entry>
  </oemStrings>
</sysinfo>
<sysinfo type='fwcfg'>
  <entry name='opt/com.example/name'>example value</entry>
  <entry name='opt/com.coreos/config' file='/tmp/provision.ign'/>
</sysinfo>
...

sysinfo元素有一个强制属性类型，用于确定子元素的布局，支持的值为：

​ smbios

​ 子元素指定特定的SMBIOS值，如果与os元素的smbios子元素(请参见1.2Operating system booting)结合使用，将影响虚拟机。sysinfo的每个子元素命名一个SMBIOS块，在这些元素内部可以是一个entry元素列表，描述块内的字段。以下块block和条目entry识别为：

​ bios

​ 这是 SMBIOS的块0，条目名称来自：

​ vendor

​ BIOS供应商名称

​ version

​ BIOS版本

​ date

​ BIOS发布日期。如果提供，则为mm/dd/yy或mm/dd/yyyy格式。如果字符串的年份部分是两位数字，则假定年份为19yy。

​ release

​ 系统BIOS主要和次要版本号值连接在一起，作为一个由句点分隔的字符串，例如10.22。

​ system

​ 这是SMBIOS块1，条目名称来自：

​ manufacturer

​ BIOS制造商

​ product

​ 产品名称

​ version

​ 产品版本

​ serial

​ 序列号

​ uuid

​ 通用唯一ID号。如果此条目与顶级uuid元素一起提供(请参见 1.1General metadata)，则这两个值必须匹配。

​ sku

​ 识特定配置的SKU编号。

​ family

​ 识别特定计算机所属的系列。

​ baseBoard

​ 这是SMBIOS的块2.这个元素可以重复多次来描述所有的基板；然而，并不是所有的hypervisor都必须支持重复。该元素可以具有以下子元素：

​ manufacturer

​ BIOS制造商

​ product

​ 产品名称

​ version

​ 产品的版本

​ serial

​ 序列号

​ asset

​ 资产标签

​ location

​ 机箱中的位置

​ 注意：错误提供的bios、系统或基板块条目将被忽略，不会出现错误。除了uuid验证和日期格式检查之外，所有值都作为字符串传递给hypervisor驱动程序。

​ chassis

​ 自4.1.0起，这是SMBIOS的块3，条目名称来自：

​ manufacturer

​ Chassis机箱(底盘)制造商

​ version

​ Chassis的版本

​ serial

​ 序列号

​ asset

​ 资产标签

​ SKU

​ SKU编号

​ oemStrings

​ 这是SMBIOS的块11。这个元素应该出现一次，并且可以有多个entry子元素，每个子元素都提供任意的字符串数据。条目中可以提供的数据没有限制，但是，如果数据打算由客户机的应用程序使用，建议将应用程序名称用作字符串中的前缀。(自4.1.0起)

fwcfg

​ 一些hypervisor提供了统一的方式来调整固件如何配置自己，或者可能包含要为guest OS安装的表，例如引导顺序、ACPI、SMBIOS等。

​ 它甚至允许用户定义自己的配置Blobs。在QEMU的情况下，这些会出现在域的sysfs下(如果客户机内核启用了FW_CFG_sysfs配置选项)，在/sys/ffirmware/qemufw_CFG下。请注意，无论下的模式如何，这些值都适用。自6.5.0

​ 请注意，由于数据槽数量有限，强烈建议使用fwcfg，而应使用。

<sysinfo type='fwcfg'>
  <entry name='opt/com.example/name'>example value</entry>
  <entry name='opt/com.example/config' file='/tmp/provision.ign'/>
</sysinfo>

​ sysinfo元素可以有多个子元素。然后，每个元素都有强制的name属性，该属性定义blob的名称，并且必须以opt/开头，为了避免与其他名称冲突，建议采用opt/$RFQDN/$name的形式，其中$RFQDN是 控制的反向完全限定域名。然后，元素可以包含值(直接设置blob值)，也可以包含file属性(从文件中设置blob的值)。

1.4 CPU分配(CPU Allocation)

<domain>
  ...
  <vcpu placement='static' cpuset="1-4，^3，6" current="1">2</vcpu>
  <vcpus>
    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
    <vcpu id='1' enabled='no' hotpluggable='yes'/>
  </vcpus>
  ...
</domain>

vcpu

​ 这个元素的内容定义了为guest OS分配的虚拟 CPU 的最大数量，必须介于 1 到 hypervisor 支持的最大数量之间。

​ cpuset

​ 可选属性cpuset是一个以逗号分隔的物理CPU编号列表，默认情况下域进程和虚拟CPU可以固定到该列表。(注意：域进程和虚拟CPU的固定策略可以由cputune单独指定。如果指定了cputune的属性emulatorpin，则此处vcpu指定的cpuset将被忽略。同样，对于指定了vcpupin的虚拟CPU，此处cpuset指定的cpuset将被忽视。对于没有指定vcpupin此处由cpuset指定的物理CPU)。该列表中的每个元素要么是一个CPU编号，要么是一系列CPU编号，或者是一个插入符号，后跟一个要从以前的范围中排除的CPU编号。自0.4.4起

​ current

​ 可选属性current可以用来指定是否应启用少于最大数量的虚拟CPU。自0.8.5起

​ placement

​ 可选属性placement可以用于指示域进程的CPU放置模式。该值可以是"static"或"auto"，但如果指定了cpuset，则默认numatune或"static"的placement方式)。使用"auto"表示域进程将通过查询numad固定到查询节点集，并且如果指定了属性cpuset的值，则会忽略该值。如果没有指定cpuset和placement，或者placement是"static"，但没有指定cpuset，则域进程将固定到所有可用的物理CPU。自0.9.11起(仅限QEMU和KVM)

vcpus

​ vcpus元素允许控制各个vCPU的状态。id属性指定libvirt在其他地方使用的vCPU id，如vCPU固定、调度程序信息和NUMA分配。请注意，在某些情况下，guest中看到的vCPU ID可能与libvirt ID不同。有效ID是从0到vCPU元素设置的最大vCPU计数减去1。enabled属性允许控制vCPU的状态。有效值为yes和no。hotpluggable热插拔控制在启动时启用CPU的情况下，是否可以热插拔给定的vCPU。请注意，所有禁用的vCPU都必须是可热插拔的。有效值为yes和no。order允许指定添加在线vCPU的顺序。对于需要同时插入多个vCPU的hypervisor/平台，顺序可能会在需要同时启用的所有vCPU中重复。不需要指定顺序，然后以任意顺序添加vCPU。如果使用排序信息，则必须将其用于所有在线vCPU。Hypervisor可以在某些操作期间清除或更新排序信息，以确保配置有效。请注意，hypervisor可能会创建与启动vCPU不同的可热插拔vCPU，因此可能需要进行特殊初始化。Hypervisor可能要求在启动时启用的不可热插拔的vCPU从ID 0开始群集。还可能要求vCPU 0始终存在并且不可热插拔。请注意，为单个CPU提供状态可能是支持可寻址vCPU热插拔所必需的，并且并非所有hypervisor都支持此功能。对于QEMU，需要以下条件。vCPU 0需要启用且不可热插拔。在PPC64上，同一核心中的vCPU也需要启用。启动时出现的所有不可热插拔CPU都需要在vCPU 0之后进行分组。自2.2.0起(仅限QEMU)

1.5 IOTreads分配(IOTreads Allocation)

IOThreads是受支持磁盘设备的专用事件循环线程，用于执行块I/O请求，以提高可扩展性，尤其是在具有许多LUN的SMP主机/客户机上。自1.2.8起(仅限QEMU)

注1：SMP(Symmetric Multiprocessing)主机是指具有多个处理器核心(CPU核心)的计算机系统，这些核心可以同时运行多个任务或线程。在SMP系统中，每个CPU核心都可以访问相同的内存和设备，并且它们共享相同的系统总线和其他资源。这种设计允许多个CPU核心共同处理任务，提高系统的性能和吞吐量。SMP主机通常用于高性能计算、服务器和虚拟化环境中。

<domain>
  ...
  <iothreads>4</iothreads>
  ...
</domain>

<domain>
  ...
  <iothreadids>
    <iothread id="2"/>
    <iothread id="4"/>
    <iothread id="6"/>
    <iothread id="8" thread_pool_min="2" thread_pool_max="32">
      <poll max='123' grow='456' shrink='789'/>
    </iothread>
  </iothreadids>
  <defaultiothread thread_pool_min="8" thread_pool_max="16"/>
  ...
</domain>

iothreads

​ 这个可选元素的内容定义了分配给域的IOThreads数量，供支持的目标存储设备使用。每个主机CPU应该只有1或2个IOThreads。可能有多个受支持的设备分配给每个IOThread。自1.2.8起

iothreadids

​ 可选的iothreadids元素提供了专门定义域的IOThread ID的功能。默认情况下，IOThread ID按顺序编号，从1开始到为域定义的iothreads数量。id属性用于定义IOThread id。id属性必须是大于0的正整数。如果定义的iothreadids少于为域定义的iothreads，那么libvirt将从1开始顺序填充iothreadids，避免任何预定义的id。1.2.15起元素有两个可选属性thread_pool_min和thread_pool _max，这两个属性允许为给定IOThread设置工作线程数的下限和上限。前者可以是零值，而后者则不能。自8.5.0起自9.4.0起，在iothread切换回事件之前，可以使用可选的子元素pool轮询覆盖iothread的hypervisor默认轮询间隔。可选属性max设置了轮询应使用的最长时间(以纳秒为单位)。将max设置为0将禁用轮询。属性grow和shrink覆盖(override)(或当设置为0时，如果设置的间隔被认为不足或太大，则禁用增加/减少轮询间隔的默认步骤)

defaultiothread

​ 此元素表示hypervisor中的默认事件循环，其中处理来自未分配给特定IOThread的设备的I/O请求。然后，元素可以具有thread_pool_min和/或thread_pool _max属性，这些属性控制默认事件循环的工作线程数的下限和上限。Emulator可能是多线程的，并根据需要生成所谓的工作线程。通常，这两个属性都不应该设置(让模拟器使用自己的默认值)，除非模拟器在实时工作负载中运行，因此无法承受生成新工作线程所需的不可预测时间。自8.5.0

1.6 CPU调整/优(CPU Tuning)

<domain>
  ...
  <cputune>
    <vcpupin vcpu="0" cpuset="1-4，^2"/>
    <vcpupin vcpu="1" cpuset="0，1"/>
    <vcpupin vcpu="2" cpuset="2，3"/>
    <vcpupin vcpu="3" cpuset="0，4"/>
    <emulatorpin cpuset="1-3"/>
    <iothreadpin iothread="1" cpuset="5，6"/>
    <iothreadpin iothread="2" cpuset="7，8"/>
    <shares>2048</shares>
    <period>1000000</period>
    <quota>-1</quota>
    <global_period>1000000</global_period>
    <global_quota>-1</global_quota>
    <emulator_period>1000000</emulator_period>
    <emulator_quota>-1</emulator_quota>
    <iothread_period>1000000</iothread_period>
    <iothread_quota>-1</iothread_quota>
    <vcpusched vcpus='0-4，^3' scheduler='fifo' priority='1'/>
    <iothreadsched iothreads='2' scheduler='batch'/>
    <cachetune vcpus='0-3'>
      <cache id='0' level='3' type='both' size='3' unit='MiB'/>
      <cache id='1' level='3' type='both' size='3' unit='MiB'/>
      <monitor level='3' vcpus='1'/>
      <monitor level='3' vcpus='0-3'/>
    </cachetune>
    <cachetune vcpus='4-5'>
      <monitor level='3' vcpus='4'/>
      <monitor level='3' vcpus='5'/>
    </cachetune>
    <memorytune vcpus='0-3'>
      <node id='0' bandwidth='60'/>
    </memorytune>

  </cputune>
  ...
</domain>

cputune

​ 可选的cputune元素提供有关域的CPU可调参数的详细信息。注意：对于qemu驱动程序，启动模拟器后将遵守可选的vcpupin和emulatorpin固定设置，并考虑NUMA约束。这意味着预计在此期间将使用主机的其他物理CPU，这将反映在virsh cpu-stats的输出中。

vcpuin

​ 可选的vcpupin元素指定域vCPU将被固定到主机的哪个物理CPU上。如果省略此项，并且没有指定元素vcpu的属性cpuset，则默认情况下，vCPU将固定到所有物理CPU。它包含两个必需的属性，属性vcpu指定vCPU id，属性cpuset与元素vcpu的属性cpuset相同。自0.9.0起支持QEMU驱动程序，自0.9.1起支持Xen驱动程序

emulatorpin

​ 可选的emulatorpin元素指定将"模拟器"(不包括vCPU或iothreads的域的子集)固定到哪一个主机物理CPU。如果省略此项，并且没有指定元素vcpu的属性cpuset，则默认情况下，"模拟器"固定到所有物理CPU。它包含一个必需的属性cpuset，用于指定要固定到的物理CPU。

iothreadpin

​ 可选的iothreadpin元素指定IOThreads固定在哪一个物理机CPU上。如果省略此项并且属性cpuset的元素vcpu没有指定，则默认情况下，IOThreads将固定到所有物理CPU上。包含两个必须属性，属性iothread指定了 IOThead的ID，属性cpuset·指定要固定到的物理CPU。请参阅记录iothread有效值的IOThreads分配部分。自1.2.9

shares

​ 可选share元素指定域的比例加权份额。如果忽略此项，则默认为操作系统提供的默认值。注意，该值没有单位，它是基于其他虚拟机设置的相对度量，例如，配置为值2048的虚拟机将获得两倍于配置为值1024的虚拟机的CPU时间。使用cgroups v1时，该值应在[2,262144]的范围内，使用cgroups v2时，应在[1,10000]的范围中。自0.9.0

period

​ 可选的period元素指定强制间隔(单位：微秒)。在此期间内，域的每个vCPU将不允许消耗超过配额的运行时。该值应在[1000,1000000]的范围内。值为0的句点表示没有值。自0.9.4起仅支持QEMU驱动程序，自0.9.10起仅支持LXC

quota 配额

​ 可选的quota元素指定允许的最大带宽(单位：微秒)。quota为负值的域表示该域对vCPU线程具有无限带宽，这意味着它不受带宽控制。该值应在[1000,17592186044415]范围内或小于0。值为0的配额表示没有值。 可以使用此功能来确保所有vCPU以相同的速度运行。自0.9.4起仅支持QEMU驱动程序，自0.9.10起仅支持LXC

global_period

​ 可选的global_period元素指定整个域的强制CFS调度程序间隔(单位：微秒)，而period则强制每个vCPU的间隔。该值应在[1000,1000000]之间。值为0的global_period表示没有值。自1.3.3起仅支持QEMU驱动程序

global_quota

​ 可选的global_period元素指定整个域的强制CFS调度程序间隔(单位：微秒)，而period则强制每个vCPU的间隔。该值应在[1000、1000000之间]。值为0的global_period表示没有值。自1.3.3起仅支持QEMU驱动程序

emulator_period

​ 可选的emulator_period元素指定强制间隔(单位：微秒)。在emulator_period内，域的模拟器线程(不包括vCPU)将不允许消耗超过emulator_quota的运行时。该值应在[1000,1000000]的范围内。值为0的句点表示没有值。0.10.0之后仅支持QEMU驱动程序

emulator_quota

​ 可选的emulator_quota元素指定域的仿真器线程(不包括vCPU的线程)允许的最大带宽(单位：微秒)。emulator_quota为任何负值的域表示该域对仿真器线程(不包括vCPU的线程)具有无限带宽，这意味着它不受带宽控制。该值应在[1000, 17592186044415]范围内或小于0。值为0的配额表示没有值。0.10.0之后仅支持QEMU驱动程序

iothread_period

​ 可选的iothread_period元素指定 IOThread 的执行间隔(单位：微秒)。在iothread_period内，域中的每个 IOThread 将不允许消耗超过iothread_quota 的运行时间。该值应在 [1000， 1000000] 范围内。值为 0 的iothread_period表示没有值。自 2.1.0 起仅支持 QEMU 驱动程序

iothread_quota

​ 可选的iothread_quota元素指定 IOThread 允许的最大带宽(单位：微秒)。iothread_quota为任何负值的域 表示该域 IOThreads 具有无限带宽，这意味着它不受带宽控制。该值应在 [1000， 17592186044415] 范围内或小于 0。 值为 0 的iothread_quota表示没有值。 可以使用此功能来确保所有 IOThread 以相同的速度运行。自 2.1.0 起仅支持 QEMU 驱动程序

vcpuched， iothreadsched and emulatorsched

​ 可选的vcpusched、iothreadsched和emulatorsched元素分别指定特定 vCPU、IOThread 和模拟器线程的调度程序类型(值batch、idle、fifo、rr )。对于vcpusched 和iothreadsched ，属性vcpus和iothreads选择此设置适用于哪些 vCPU/IOThread，将它们保留为默认值。元素emulatorsched没有该属性。有效的vCPU 值从 0 开始，到比为域定义的 vCPU 数量减一为止。有效的iothreads值在IOThreads Allocation部分中描述 。如果未定义iothreadids ，则 libvirt 会将 IOThread 编号从 1 到 可用于域的iothread数量。对于实时调度程序(fifo、rr)，还必须指定优先级(对于非实时调度程序则忽略优先级)。优先级的取值范围取决于主机内核(通常为1-99)。 自 1.2.13 起 emulatorsched 自 5.3.0 起

cachetune Since 4.1.0

​ 可选的cachetune元素可以使用主机上的resctrl控制CPU缓存的分配。是否支持这一点可以从报告了一些限制(如最小size和所需粒度)的功能中收集。所需的属性vcpus指定此分配应用于哪些vCPU。vCPU只能是一个cachetune元素分配的成员。cachetune指定的vCPU可以与memorytune中的vCPU相同，但不允许重叠。可选的、仅输出的id属性唯一标识缓存。支持的子元素有：

​ cache

​ 此可选元素控制CPU缓存的分配，并具有以下属性：

​ level

​ 要分配的主机缓存级别。

​ id

​ 要从中分配的主机缓存id。

​ type

​ 分配类型。可以是代码(指令)的 code，数据的 data，或者代码和数据都包含的 both(统一)。目前，分配只能与主机支持的相同类型一起进行，这意味着 无法请求both在启用了 CDP(代码/数据优先级)的主机上同时分配两者。

​ size

​ 要分配的区域的大小。默认情况下，值以字节为单位，但单位属性可用于缩放值。

​ unit(optional)

​ 如果指定，则是指定大小的单位，如KiB、MiB、GiB或TiB(在内存分配的memory元素中描述)，size默认为字节。

​ monitor Since4.10.0

​ 可选元素monitor监视器为当前缓存分配创建缓存监视器，并具有以下必需属性：

​ level

​ 监视器所属的主机缓存级别。

​ vcpus

​ 监视器应用的vCPU列表。监视器的vCPU名单只能是关联分配的vCPU清单的成员。默认监视器具有与关联分配相同的vCPU列表。对于非默认监视器，不允许重叠vCPU。

memorytune Since4.7.0

​ 可选的memorytune元素可以使用主机上的resctrl控制内存带宽的分配。是否支持这一点可以从报告了一些限制(如最小带宽和所需粒度)的功能中收集。所需的属性vcpus指定此分配应用于哪些vCPU。vCPU只能是一个内存调整元素分配的成员。memorytune指定的vcpus可以与cachetune指定相同。但是，它们不允许相互重叠。支持的子元素有：

​ node

​ 此元素控制CPU内存带宽的分配，并具有以下属性：

​ id

​ 从中分配内存带宽的主机节点id。

​ bandwidth

​ 要从此节点分配的内存带宽。默认情况下，该值以百分比为单位。

1.7 内存分配(Memory Allocation)

<domain>
  ...
  <maxMemory slots='16' unit='KiB'>1524288</maxMemory>
  <memory unit='KiB'>524288</memory>
  <currentMemory unit='KiB'>524288</currentMemory>
  ...
</domain>

memory

​ 在引导时为虚拟机分配的最大内存。内存分配包括在启动时指定的可能的附加内存设备，或后来的热插拔。该值的单位由可选属性unit 决定，默认为 “KiB”(千字节，210 或 1024 字节的块)。有效的单位包括 “b” 或 “bytes” 代表字节，“KB” 代表千字节(10^3 或 1，000 字节)，“k” 或 “KiB” 代表 kibibytes(1024 字节)，“MB” 代表兆字节(10^6 或 1,000,000 字节)，“M” 或 “MiB” 代表 mebibytes(2^20 或 1,048,576 字节)，“GB” 代表千兆字节(10^9 或 1,000,000,000 字节)，“G” 或 “GiB” 代表 gibibytes(2^30 或 1,073,741,824 字节)，“TB” 代表太字节(10^12 或 1,000,000,000,000 字节)，或 “T” 或 “TiB” 代表 tebibytes(2^40 或 1,099,511,627,776 字节)。但是，libvirt 会将该值舍入到最接近的 kibibyte，并且可能会进一步舍入到hypervisor支持的粒度。一些hypervisor还会强制实施最小内存分配，如 4000KiB。如果为guest配置了 NUMA(请参阅 1.14 CPU model and topology)，则可以省略memory内存元素。在崩溃的情况下，可以使用可选属性 dumpCore 来控制是否在生成的核心转储文件中包括guest内存(值为 “on” 或 “off”)。unit 自 0.9.11 版本引入，dumpCore 自 0.10.2 版本引入(仅适用于 QEMU)。

maxMemory

​ guest运行时最大内存分配。元素或NUMA单元大小配置指定的初始内存可以通过将内存热插拔到该元素指定的限制来增加。unit属性的行为与相同。slots属性指定可用于向guest添加内存的插槽数。界限是特定于hypervisor的。请注意，由于通过内存热插拔添加的内存块的对齐，可能无法实现此元素指定的完整大小分配。自1.2.14由QEMU驱动程序支持。

currentMemory

​ guest的实际内存分配。该值可以小于最大分配，以便在运行中增加guest内存。如果忽略此项，则默认为与memory内存元素相同的值。unit属性的行为与memory相同。

1.8 内存备份(Memory Backing)

<domain>
  ...
  <memoryBacking>
    <hugepages>
      <page size="1" unit="G" nodeset="0-3，5"/>
      <page size="2" unit="M" nodeset="4"/>
    </hugepages>
    <nosharepages/>
    <locked/>
    <source type="file|anonymous|memfd"/>
    <access mode="shared|private"/>
    <allocation mode="immediate|ondemand" threads='8'/>
    <discard/>
  </memoryBacking>
  ...
</domain>

可选元素memoryBacking 可包含影响主机页如何支持虚拟存储器页的几个元素。

hugepages

​ 这告诉虚拟机监控程序应该使用大页而不是正常的本机页面大小来分配guest内存。从 1.2.5 开始，可以为每个 numa 节点更具体地设置大页。引入page页面元素。它有一个强制属性 size，指定应使用哪些大页(在支持不同大小的大页的系统上特别有用)。size属性的默认单位是千字节(1024 的倍数)。如果 想使用不同的单位，请使用可选的unit属性。对于具有 NUMA 的系统，可选的nodeset节点集属性可能会很方便，因为它将给定guest的 NUMA 节点与某些大页面大小联系起来。从示例代码片段来看，除 4 号节点外，每个 NUMA 节点都使用 1 GB 的大页。有关正确的语法，请参阅 1.10 NUMA Node Tuning。

nosharepages

​ 指示系统监控程序禁用此域的共享页面(内存合并，KSM)。自1.0.6起

locked

​ 当系统监控程序设置并支持时，属于域的内存页将被锁定在主机的内存中，并且主机将不允许将它们交换出去，这对于某些工作负载(如实时工作负载)可能是必需的。对于QEMU/KVM的 guests，QEMU进程本身使用的内存也将被锁定：与guest内存不同，这是libvirt无法提前计算出的数量，因此它必须完全取消对锁定内存的限制。因此，启用此选项会带来潜在的安全风险：当内存耗尽时，主机将无法从客户机收回锁定的内存，这意味着恶意客户机分配大量锁定内存可能会对主机造成拒绝服务攻击。因此，除非 的工作负载需要，否则不鼓励使用此选项；即便如此，强烈建议在内存分配上同时设置一个适用于特定环境的hard_limit(请参阅Memory Tuning )，以减轻上述风险。自1.0.6起

source

​ 使用type属性，可以提供"file"以利用文件内存备份或保持默认的"匿名"。从4.10.0开始， 可以选择"memfd"备份。(仅限QEMU/KVM)

access

​ 使用mode属性，指定内存是"shared"还是"private"。memAccess可以覆盖每个numa节点。

allocation

​ 使用可选mode模式属性，通过提供"immediate"立即或"ondemand"按需指定何时分配内存。自8.2.0起，可以通过thread属性设置系统监控程序用于分配内存的线程数。为了加快分配过程，当固定仿真线程时，建议包括来自所需NUMA节点的CPU，以便分配线程可以设置其关联性。

discard

​ 当系统监控程序设置并支持时，内存内容将在guest关闭前(或拔下DIMM模块时)。请注意，这只是一种优化，并不能保证在所有情况下都能工作(例如，当系统监控程序崩溃时)。自4.4.0起(仅限QEMU/KVM)

1.9 内存调整/优(Memory Tuning)

<domain>
  ...
  <memtune>
    <hard_limit unit='G'>1</hard_limit>
    <soft_limit unit='M'>128</soft_limit>
    <swap_hard_limit unit='G'>2</swap_hard_limit>
    <min_guarantee unit='bytes'>67108864</min_guarantee>
  </memtune>
  ...
</domain>

memtune

​ 可选元素memtune提供了有关域的内存可调参数的详细信息。如果忽略此项，则默认为操作系统提供的默认值。对于QEMU/KVM，参数作为一个整体应用于QEMU进程。因此，在计算它们时，需要将guest的RAM、guest视频RAM和QEMU本身的一些内存开销相加。最后一块很难确定，所以需要猜测和尝试。对于每个可调，可以使用与相同的值来指定数字在输入时的单位。为了向后兼容，输出始终使用KiB。unit自0.9.11所有 *_limit参数的可能值在0到VIR_DOMAIN_MEMORY_PARAM_UNLIMITED的范围内。

hard_limit

​ 可选元素hard_limit是guest可以使用的最大内存。该值的单位为kibiytes(即1024字节的块)。强烈建议QEMU和KVM的用户不要设置此限制，因为如果猜测值太低，域可能会被内核杀死，并且确定进程运行所需的内存是一个无法确定的问题；也就是说，如果由于工作负载的要求， 已经在Memory Backing内存备份中设置了locked，那么 必须考虑部署的具体情况，并计算出hard_limit的值，该值足够大到可以支持guest的内存需求，但又要足够小到可以保护主机免受恶意guest锁定所有内存的影响。

soft_limit

​ 可选元素soft_limit是在内存争用期间强制执行的内存限制。该值的单位为kibiytes(即1024字节的块)

swap_hard_limit

​ 可选元素swap_hard_limit是guest可以使用的最大内存加交换。该值的单位为kibiytes(即1024字节的块)。这必须大于所提供的hard_limit值

min_guarantee

​ 可选元素min_guarantee是为客户机保证的最小内存分配。该值的单位为kibiytes(即1024字节的块)。此元素仅受VMware ESX和OpenVZ驱动程序的支持。

1.10 NUMA 节点调优(NUMA Node Tuning)

注1：NUMA(Non-Uniform Memory Access，非一致性内存访问)是一种计算机体系结构，用于处理多处理器系统中的内存访问性能问题。在 NUMA 架构中，系统中的处理器核心和内存被分成多个节点，每个节点具有自己的本地内存。不同节点之间的内存访问速度可能会不同，这就是所谓的"非一致性"。

在虚拟化环境中，虚拟机(VM)通常运行在物理主机上，而主机可能具有多个 NUMA 节点。NUMA 节点之间的内存访问延迟和带宽可能不同，这会影响虚拟机的性能。因此，NUMA 节点调优(NUMA Node Tuning)是一种优化措施，用于确保虚拟机在 NUMA 架构下获得更好的性能。

<domain>
  ...
  <numatune>
    <memory mode="strict" nodeset="1-4，^3"/>
    <memnode cellid="0" mode="strict" nodeset="1"/>
    <memnode cellid="2" mode="preferred" nodeset="2"/>
  </numatune>
  ...
</domain>

numatune

​ 可选元素numatune提供了如何通过控制域进程的NUMA策略来调整NUMA主机性能的详细信息。注意，仅由QEMU驱动程序支持。自0.9.3起

memory

​ 可选元素memory指定如何为NUMA主机上的域进程分配内存。它包含几个可选属性。属性mode模式为"interleave"、“strict”、“preferred"或"restrictive”，默认为"strict)。值"restrictive"指定使用系统默认策略，并且仅使用cgroups来限制内存节点，并且它要求在memnode元素中将模式设置为"restricted"(请参阅下面的quirk)。这仅仅是为了能够使用virsh-numatune或virDomainSetNumaParameters请求为正在运行的域移动此类内存，并且不能保证会发生这种情况。属性nodeset指定NUMA节点，使用与元素vcpu的属性cpuset相同的语法。属性placement(自0.9.12起)可用于指示域进程的内存放置模式，其值可以是"静态"或"自动"，默认为vcpu的placement，如果指定了nodeset节点集，则为"静态"。“auto"表示域进程将只从查询numad返回的咨询节点集中分配内存，如果指定了属性节点集的值，则会忽略该值。如果vcpu的位置为"auto”，并且未指定numatune，则将隐式添加位置为"autom"且模式为"strict"的默认numatune。自0.9.3起，请参阅virDomainSetNumaParameters了解有关此元素更新的更多信息。

memnod

​ 可选元素memnode可以为每个guest的NUMA节点指定内存分配策略。对于那些没有相应memnode元素的节点，将使用memory元素中的默认值。属性cellid指定了应用设置的客户端 NUMA 节点的地址。属性mode和nodeset具有与memory元素相同的含义和语法。此设置与自动放置不兼容。请注意，对于memnode，这将仅引导vCPU线程或类似机制的内存访问，并且在很大程度上取决于虚拟化监控程序的特定实现(hypervisor-specific)。这并不能保证节点内存分配的位置。为了进行适当的限制，应使用其他方式(例如不同的模式、预先分配的hugepages)。QEMU自1.2.7起

1.11 块I/O 调整/优(Block I/O Tuning)

<domain>
  ...
  <blkiotune>
    <weight>800</weight>
    <device>
      <path>/dev/sda</path>
      <weight>1000</weight>
    </device>
    <device>
      <path>/dev/sdb</path>
      <weight>500</weight>
      <read_bytes_sec>10000</read_bytes_sec>
      <write_bytes_sec>10000</write_bytes_sec>
      <read_iops_sec>20000</read_iops_sec>
      <write_iops_sec>20000</write_iops_sec>
    </device>
  </blkiotune>
  ...
</domain>

blkotune

​ 可选元素blkiotune提供了为域调整Blkio-cgroup可调参数的能力。如果忽略此项，则默认为操作系统提供的默认值。自0.8.8

weight

​ 可选元素weight是guest的总体I/O权重。该值应在[100， 1000]的范围内。在内核2.6.39之后，该值可能在[10， 1000]的范围内。

device

​ 域可以具有多个device元素，这些设备元素进一步调整域使用的每个主机块设备的权重。请注意，如果多个磁盘(请参阅 Hard drives, floppy disks, CDROMs—1.20.1节)由同一主机文件系统中的文件备份，则它们可以共享一个主机块设备，这就是为什么这个调整参数是全局域级别的，而不是与每个客户磁盘设备相关联(与磁盘定义的元素形成对比(请参阅 Hard drives, floppy disks, CDROMs—1.20.1节)，后者可以应用于单个磁盘)。每个device元素都有两个强制的子元素，一个是描述设备绝对路径的path，另一个是给出该设备相对权重的weight，范围在[100， 1000]。在内核2.6.39之后，该值可能在[10， 1000]的范围内。自0.9.8，此外，可以使用以下可选子元素：

​ read_bytes_sec

​ 读吞吐量限制(以字节每秒为单位)。自1.2.2

​ write_bytes_sec

​ 写吞吐量限制(以字节每秒为单位)。自1.2.2

​ read_iops_sec

​ 每秒读取I/O操作数限制。自1.2.2

​ write_iops_sec

​ 每秒写入I/O操作数限制。自1.2.2

1.12 资源分区(Resource partitioning)

Hypervisor可以允许将虚拟机放置在资源分区中，可能会嵌套这些分区。resource元素将与资源分区相关的配置组合在一起。目前支持一个名为partition的子元素，其内容定义了要将该域放置在哪个资源分区的绝对路径中。如果没有列出分区，那么该域将被放置在默认分区中。在启动客户机之前，应用程序/管理员有责任确保分区存在。默认情况下，只能假定(特定hypervisor)默认分区存在。

...
<resource>
  <partition>/virtualmachines/production</partition>
</resource>
...

资源分区目前由QEMU和LXC驱动程序支持，它们将分区路径映射到所有安装的控制器中的cgroups目录。自1.0.5

1.13 光纤通道VMID(Fibre Channel VMID)

FC SAN(Fibre Channel Storage Area Network)可以根据虚拟机标识(VMID)提供各种不同的服务质量(QoS)级别和访问控制。它还可以在每个虚拟机的级别收集遥测数据，这些数据可以用来提升虚拟机的IO性能。这可以通过使用光纤通道元素的appid属性进行配置。该属性包含一个字符串(最多128字节)，内核会使用它来创建VMID(Virtual Machine Identifier).

...
<resource>
  <fibrechannel appid='userProvidedID'/>
</resource>
...

使用此功能需要支持光纤通道的硬件、使用CONFIG_BLK_CGROUP_FC_APPID编译的内核和加载nvme_FC的内核模块。自7.7.0

1.14 (CPU model and topology)

可以使用以下元素集合指定CPU模型、其功能和拓扑结构的要求。自0.7.5

...
<cpu match='exact'>
  <model fallback='allow'>core2duo</model>
  <vendor>Intel</vendor>
  <topology sockets='1' dies='1' cores='2' threads='1'/>
  <cache level='3' mode='emulate'/>
  <maxphysaddr mode='emulate' bits='42'/>
  <feature policy='disable' name='lahf_lm'/>
</cpu>
...

<cpu mode='host-model'>
  <model fallback='forbid'/>
  <topology sockets='1' dies='1' cores='2' threads='1'/>
</cpu>
...

<cpu mode='host-passthrough' migratable='off'>
  <cache mode='passthrough'/>
  <maxphysaddr mode='passthrough' limit='39'/>
  <feature policy='disable' name='lahf_lm'/>
...

<cpu mode='maximum' migratable='off'>
  <cache mode='passthrough'/>
  <feature policy='disable' name='lahf_lm'/>
...

如果不需要对CPU模型及其功能进行限制，可以使用更简单的CPU元素。自0.7.6

...
<cpu>
  <topology sockets='1' dies='1' cores='2' threads='1'/>
</cpu>
...

cpu

​ cpu元素是用于描述guest cpu需求的主要容器。它的match属性指定提供给guest的虚拟CPU与这些要求的匹配程度。自0.7.6，如果topology是cpu中唯一的元素，则可以省略match属性。match属性的可能值为：

​ minimum

​ 指定的CPU型号和功能描述了请求的最小CPU。如果可以在当前主机上使用请求的虚拟机监控程序，将为客户机提供更好的CPU。这是一种受约束的host-model 模型模式；如果提供的虚拟CPU不满足要求，则不会创建域。

​ exact

​ 提供给guest的虚拟CPU应该与规范完全匹配。如果不支持这样的CPU，libvirt将拒绝启动域。

​ strict

​ 除非主机CPU与规范完全匹配，否则不会创建域。这在实践中不是很有用，只有在有真正原因的情况下才应该使用。

0.8.5起，match属性可以省略，默认为exact。有时系统监控程序无法创建与libvirt传递的规范完全匹配的虚拟CPU。从3.2.0开始，可选的check属性可用于请求检查虚拟CPU是否符合规范的特定方式。在启动域时，通常可以安全地省略此属性，并使用默认值。一旦域启动，libvirt将自动将check属性更改为支持的最佳值，以确保域迁移到另一台主机时虚拟CPU不会发生更改。可以使用以下值：

​ none

​ Libvirt不进行检查，如果无法提供请求的CPU，则由hypervisor拒绝启动域。对于QEMU，这意味着根本不进行检查，因为QEMU的默认行为是发出警告，但无论如何都要启动域。

​ partial

​ Libvirt将在启动域之前检查guest的CPU规范，但其余内容将保留在hypervisor上。它仍然可以提供不同的虚拟CPU。

​ full

​ hypervisor创建的虚拟CPU将根据CPU规范进行检查，除非两个CPU匹配，否则不会启动域。

0.9.10起，可以使用可选的mode属性，以便更容易地将客户CPU配置为尽可能接近主机CPU。模式属性的可能值为：

​ custom

​ 在这种模式下，cpu元素描述了应该提供给guest的cpu。当未指定mode属性时，这是默认设置。这种模式使得持久guest无论在哪个主机上启动都能看到相同的硬件。

​ host-model

​ host-model模式本质上是将主机CPU定义从capabilities XML复制到域XML的快捷方式。由于CPU定义是在启动域之前复制的，因此完全相同的XML可以在不同的主机上使用，同时仍然提供每个主机支持的最佳客户CPU。match属性不能在此模式中使用。也不支持指定CPU型号，但仍可使用model的fallback属性。使用feature元素，除了host 模型之外，还可以专门启用或禁用特定标志。这可以用于调整可以模拟的功能。(从1.1.1开始).Libvirt并没有对每个CPU的各个方面进行建模，因此客户机CPU不会与主机CPU完全匹配。另一方面，提供给guest的ABI是可复制的。在迁移过程中，完整的CPU模型定义会转移到目标主机，因此即使目标主机包含更多功能的CPU或更新的内核，迁移的客户机也会看到与客户机运行实例完全相同的CPU模型；但是关闭和重新启动guest可以根据新主机的能力向guest呈现不同的硬件。在libvirt 3.2.0和QEMU 2.9.0之前，不支持通过QEMU检测主机CPU模型。因此，使用主机模型创建的CPU配置可能无法按预期工作。自3.2.0和QEMU 2.9.0，该模式按照设计方式工作，并且在 domain capabilities XML中公布的主机模型CPU定义中，fallback属性设置为forbid。当fallback属性设置为allow域功能XML时，建议仅使用host capabilities XML中的CPU模型使用custom模式。自1.2.11 PowerISA允许处理器在二进制兼容模式下运行VM，支持旧版本的ISA。PowerPC体系结构上的Libvirt使用host-model来表示在二进制兼容模式下运行的guest模式CPU。示例：当用户需要power7虚拟机在Power8主机上以兼容模式运行时，可以用XML描述如下：

<cpu mode='host-model'>
  <model>power7</model>
</cpu>
...

注1：ABI(Application Binary Interface)定义了不同部分(通常是软件和硬件之间)之间的二进制接口标准，以确保不同程序和模块能够互相协同工作。

注2：PowerISA(Power Instruction Set Architecture)(Power指令集架构)微处理器架构

​ host-passthrough 物理机透传

​ 在这种模式下，提供给虚拟机的CPU应该与主机CPU完全相同，即使在libvirt无法理解的方面也是如此。然而，这种模式的缺点是虚拟机环境无法在不同的硬件上重现。因此，如果遇到任何问题，你需要自己解决。可以使用feature元素来进一步更改虚拟CPU的详细信息。如果源主机和目标主机在硬件、QEMU版本、 microcode版本和配置方面不完全相同，那么使用host-passthrough迁移虚拟机是危险的。如果尝试这样的迁移，那么虚拟机可能会在在目标主机上恢复执行时挂起或崩溃。根据hypervisor版本，虚拟CPU可能会包含阻止迁移的功能，即使迁移到一个完全相同的主机也可能如此。自6.5.0起，可选的migratable属性可用于显式请求将这些功能从虚拟CPU中删除(on)或保留在其中(off)。这个属性并不会使迁移到另一台主机更安全：即使使用migratable='on'，除非两台主机如上所述完全相同，否则迁移仍然是危险的。

​ maximum

​ 当使用硬件虚拟化运行客户机时，此CPU型号在功能上与主机直通相同，因此请参阅上面的文档。

​ 当使用CPU仿真运行客户机时，此CPU模型将启用仿真引擎能够支持的最大功能集。请注意，即使migrateable=‘on’，迁移也会很危险，除非两个主机都运行相同版本的模拟代码。

​ 自7.1.0起使用QEMU驱动程序。

当域可以直接在主机CPU上运行时，host-mode和host-passthrough模式都是有意义的(例如，类型为kvm或hvf的域)。实际主机CPU与具有模拟虚拟CPU的域(例如qemu类型的域)无关。然而，为了向后兼容，即使对于在模拟CPU上运行的域，也可以实现host-model，在这种情况下，可以使用hypervisor能够模拟的最佳CPU，而不是试图模拟主机CPU模型。

如果应用程序不关心特定的CPU，只想要最好的功能集而不需要迁移兼容性，那么在可用的hypervisor上，maximum模型是一个不错的选择。

model

​ model元素的内容指定guest请求的CPU模型。可用CPU型号及其定义的列表可以在目录cpu_map中找到，该目录安装在libvirt的数据目录中。如果hypervisor无法使用确切的CPU模型，那么libvirt会自动返回到hypervisor支持的最接近的模型，同时维护CPU功能列表。自0.9.10以来，可以使用可选的fallback属性来禁止这种行为，在这种情况下，启动请求不支持的CPU模型的域的尝试将失败。fallback属性支持的值为：allow(这是默认值)和forbid。可选的vendor_id属性(0.10.0起)可用于设置guest看到的供应商id。它必须正好有12个字符长。如果未设置，则使用主机的供应商id。典型的可能值是"AuthenticAMD"和"GenuineIntel"。

vendor-cpu供应商-amd / intel / hygon

​ 0.8.3起，vendor元素的内容指定了guest请求的CPU vendor。如果缺少此元素，则无论供应商如何，guest都可以在与给定功能匹配的CPU上运行。支持的供应商列表可以在cpu_map/*_vendors.xml中找到。

topology拓扑

​ topology元素指定提供给客户的虚拟CPU的请求拓扑。sockets、dies、cores和threads这四个属性接受非零正整数值。它们分别指CPU sockets(插槽)的总数、每个sockets的die(裸片数，晶圆)、每个die的内核数和每个内核的线程数。dies属性是可选的，如果省略，则默认为1，而其他属性都是必需的。Hypervisor可能要求cpus元素指定的最大vCPU数量等于拓扑结构产生的vCPUs数量。

注1：海光Hygon CPU 架构图

feature

​ cpu元素可以包含零个或多个用于调整由所选cpu模型提供的特征的feature元素。已知功能名称的列表可以在与CPU型号相同的文件中找到。每个feature元素的含义取决于其policy属性，该属性必须设置为以下值之一：

​ force

​ 无论主机CPU是否支持该功能，虚拟CPU都会声明该功能得到支持。

​ require

​ 除非主机CPU支持该功能或hypervisor能够模拟该功能，否则guest创建将失败。

​ optional

​ 仅当主机CPU支持该功能时，虚拟CPU才会支持该功能。

​ disable

​ 虚拟CPU不支持该功能。

​ forbid

​ 如果主机CPU支持该功能，则创建客户端将失败。

从0.8.5开始，policy属性可以省略，默认为require。

单个CPU功能名称作为name属性的一部分指定。例如，要显式指定英特尔IvyBridge CPU模型的"pcid"功能:

...
<cpu match='exact'>
  <model fallback='forbid'>IvyBridge</model>
  <vendor>Intel</vendor>
  <feature policy='require' name='pcid'/>
</cpu>
...

cache

​ 自3.3.0开始，cache元素描述了虚拟CPU缓存。如果该元素不存在，hypervisor将使用一个合理的默认值。

​ level

​ 此可选属性指定元素描述的缓存级别。缺少属性意味着元素同时描述所有CPU缓存级别。禁止混合使用带level属性集的cache元素和不带level属性集的缓存元素。

​ mode

​ 支持以下取值:

​ emulate

​ hypervisor将提供一个假的CPU缓存数据。

​ passthrough 透传

​ 主机CPU上的真实CPU cache数据会被传递给虚拟CPU。

​ disable

​ 虚拟CPU将报告没有指定级别的CPU缓存(或者如果缺少级别属性则根本没有缓存)。

maxphysaddr

​ 8.7.0起，maxphysaddr元素以位为单位描述虚拟CPU地址的大小。如果缺少该元素，则使用hypervisor默认值。

​ mode

​ 这个强制属性指定地址大小的显示方式。支持以下模式:

​ passthrough

​ 主机CPU报告的物理地址位数将传递给虚拟CPU

​ emulate

​ hypervisor将通过bits属性为物理地址的位数定义一个特定的值(自9.2.0是可选的)，位数不能超过hyperviosr支持的物理地址位数。

​ bits

​ 如果mode属性设置为emulation，并且指定虚拟CPU地址大小(以位为单位)，则bits属性是必选的。

​ limit

​ limit属性可用于限制passthrough模式的地址位的最大值，即，如果主机CPU报告的位超过该值，则使用limit。自9.3.0

可以使用numa元素指定guest的NUMA拓扑。

...
<cpu>
  ...
  <numa>
    <cell id='0' cpus='0-3' memory='512000' unit='KiB' discard='yes'/>
    <cell id='1' cpus='4-7' memory='512000' unit='KiB' memAccess='shared'/>
  </numa>
  ...
</cpu>
...

每个cell元素指定一个NUMA cell或NUMA节点。cpus指定节点的CPU或CPUs范围。从6.5.0开始，对于qemu驱动程序，如果模拟器二进制支持每个cell使用不相交cpus范围，则每个cell中声明的所有cpu的总和将与vcpu元素中声明的虚拟cpu的最大数量相匹配。这是通过将任何剩余的CPU填充到第一个NUMA cell来完成的。鼓励用户提供完整的NUMA拓扑，其中NUMA CPUs的总数与在vcpus中声明的最大虚拟CPU数量相匹配，以确保在qemu和libvirt的各个版本中，域的配置保持一致。memory指定了以kibibytes(即1024字节的块)为单位的节点内存。自6.6.0以来，cpus属性是可选的，如果省略，则会创建一个没有CPU的NUMA节点。自1.2.11以来，可以使用额外的unit属性(请参阅内存分配 1.7Memory Allocation)，以定义memory的单位。自1.2.7起，所有的单元都应该具有id属性，以便在代码中引用某些单元，否则这些单元将按从0开始的递增顺序分配id。不建议混合具有id属性和没有id属性的单元，因为这可能导致意外的行为。自1.2.9起，memAccess是一个可选属性，可以控制内存是否映射为"shared"或"private"。这仅适用于hugepages支持的内存和nvdimm模块。每个cell元素都可以具有一个可选的discard属性，用于调整给定NUMA节点的丢弃功能，如在" Memory Backing."下所述。可接受的值为yes和no。自4.4.0起

这个guest的NUMA规范目前仅适用于QEMU/KVM和Xen。

NUMA硬件架构支持NUMA单元之间距离的概念。从3.10.0开始，可以使用NUMA cell描述中的distances元素来定义NUMA单元之间的距离。sibling子元素用于指定兄弟NUMA单元格之间的距离值。要了解更多细节，请参阅ACPI(Advanced Configuration and Power Interface，高级配置和电源接口)规范中解释系统的SLIT(System Locality Information Table，系统位置信息表)的章节。

...
<cpu>
  ...
  <numa>
    <cell id='0' cpus='0，4-7' memory='512000' unit='KiB'>
      <distances>
        <sibling id='0' value='10'/>
        <sibling id='1' value='21'/>
        <sibling id='2' value='31'/>
        <sibling id='3' value='41'/>
      </distances>
    </cell>
    <cell id='1' cpus='1，8-10，12-15' memory='512000' unit='KiB' memAccess='shared'>
      <distances>
        <sibling id='0' value='21'/>
        <sibling id='1' value='10'/>
        <sibling id='2' value='21'/>
        <sibling id='3' value='31'/>
      </distances>
    </cell>
    <cell id='2' cpus='2，11' memory='512000' unit='KiB' memAccess='shared'