云计算虚拟化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>MyGuestname>
  <uuid>4dea22b3-1d52-d8f3-2516-782e98ab3fa0uuid>
  <genid>43dc0cf8-809b-4adb-9bea-a9abb5f3d90egenid>
  <title>A short description - title - of the domaintitle>
  <description>Some human readable descriptiondescription>
  <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、网络)，用于确定在哪里获取/查找引导映像。

...
<os>
  <type>hvmtype>
  <loader>/usr/lib/xen/boot/hvmloaderloader>
  <boot dev='hd'/>
os>
...


...
<os>
  <type>hvmtype>
  <boot dev='cdrom'/>
  <bootmenu enable='yes' timeout='3000'/>
  <smbios mode='sysinfo'/>
  <bios useserial='yes' rebootTimeout='0'/>
os>
...


...
<os>
  <type>hvmtype>
  <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fdloader>
  <nvram template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/nvram/guest_VARS.fdnvram>
  <boot dev='hd'/>
os>
...


...
<os>
  <type>hvmtype>
  <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fdloader>
  <nvram type='file' template='/usr/share/OVMF/OVMF_VARS.fd'>
    <source file='/var/lib/libvirt/nvram/guest_VARS.fd'/>
  nvram>
  <boot dev='hd'/>
os>
...


...
<os>
  <type>hvmtype>
  <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fdloader>
  <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>
...


...
<os firmware='efi'>
  <type>hvmtype>
  <loader secure='yes'/>
  <boot dev='hd'/>
os>
...


...
<os firmware='efi'>
  <type>hvmtype>
  <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/pygrubbootloader>
<bootloader_args>--append singlebootloader_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>hvmtype>
  <loader>/usr/lib/xen/boot/hvmloaderloader>
  <kernel>/root/f8-i386-vmlinuzkernel>
  <initrd>/root/f8-i386-initrdinitrd>
  <cmdline>console=ttyS0 ks=http://example.com/f8-i386/os/cmdline>
  <dtb>/root/ppc.dtbdtb>
  <acpi>
    <table type='slic'>/path/to/slic.dattable>
  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'>exetype>
  <init>/bin/systemdinit>
  <initarg>--unitinitarg>
  <initarg>emergency.serviceinitarg>
  <initenv name='MYENV'>some valueinitenv>
  <initdir>/my/custom/cwdinitdir>
  <inituser>testerinituser>
  <initgroup>1000initgroup>
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'>LENOVOentry>
  bios>
  <system>
    <entry name='manufacturer'>Fedoraentry>
    <entry name='product'>Virt-Managerentry>
    <entry name='version'>0.9.4entry>
  system>
  <baseBoard>
    <entry name='manufacturer'>LENOVOentry>
    <entry name='product'>20BE0061MCentry>
    <entry name='version'>0B98401 Proentry>
    <entry name='serial'>W1KS427111Eentry>
  baseBoard>
  <chassis>
    <entry name='manufacturer'>Dell Inc.entry>
    <entry name='version'>2.12entry>
    <entry name='serial'>65X0XF2entry>
    <entry name='asset'>40000101entry>
    <entry name='sku'>Type3Sku1entry>
  chassis>
  <oemStrings>
    <entry>myappname:some arbitrary dataentry>
    <entry>otherappname:more arbitrary dataentry>
  oemStrings>
sysinfo>
<sysinfo type='fwcfg'>
  <entry name='opt/com.example/name'>example valueentry>
  <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 valueentry>
  <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">2vcpu>
  <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>4iothreads>
  ...
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>2048shares>
    <period>1000000period>
    <quota>-1quota>
    <global_period>1000000global_period>
    <global_quota>-1global_quota>
    <emulator_period>1000000emulator_period>
    <emulator_quota>-1emulator_quota>
    <iothread_period>1000000iothread_period>
    <iothread_quota>-1iothread_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'>1524288maxMemory>
  <memory unit='KiB'>524288memory>
  <currentMemory unit='KiB'>524288currentMemory>
  ...
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'>1hard_limit>
    <soft_limit unit='M'>128soft_limit>
    <swap_hard_limit unit='G'>2swap_hard_limit>
    <min_guarantee unit='bytes'>67108864min_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>800weight>
    <device>
      <path>/dev/sdapath>
      <weight>1000weight>
    device>
    <device>
      <path>/dev/sdbpath>
      <weight>500weight>
      <read_bytes_sec>10000read_bytes_sec>
      <write_bytes_sec>10000write_bytes_sec>
      <read_iops_sec>20000read_iops_sec>
      <write_iops_sec>20000write_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/productionpartition>
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'>core2duomodel>
  <vendor>Intelvendor>
  <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>power7model>
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'>IvyBridgemodel>
  <vendor>Intelvendor>
  <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'>
      <distances>
        <sibling id='0' value='31'/>
        <sibling id='1' value='21'/>
        <sibling id='2' value='10'/>
        <sibling id='3' value='21'/>
      distances>
    cell>
    <cell id='3' cpus='3' memory='512000' unit='KiB'>
      <distances>
        <sibling id='0' value='41'/>
        <sibling id='1' value='31'/>
        <sibling id='2' value='21'/>
        <sibling id='3' value='10'/>
      distances>
    cell>
  numa>
  ...
cpu>
...

描述NUMA单元之间的距离目前仅由Xen和QEMU支持。如果没有给出distances来描述不同小区之间的SLIT数据，则默认使用10表示本地距离和20表示远程距离的方案。

注1：SLIT(System Locality Information Table)是一种在NUMA(Non-Uniform Memory Access)体系结构中使用的数据结构，它提供了关于系统中不同本地性域之间的本地性信息。SLIT 数据通常以表格或矩阵的形式表示，其中每个条目表示一个本地性域对的距离。较小的值表示更接近的距离，而较大的值表示更远的距离。这种信息可以帮助操作系统更有效地将任务和数据分配到本地性域，以减少延迟和提高系统性能。

ACPIHeterogeneous Memory Attribute Table

...
<cpu>
  ...
  <numa>
    <cell id='0' cpus='0-3' memory='2097152' unit='KiB' discard='yes'>
      <cache level='1' associativity='direct' policy='writeback'>
        <size value='10' unit='KiB'/>
        <line value='8' unit='B'/>
      cache>
    cell>
    <cell id='1' cpus='4-7' memory='512000' unit='KiB' memAccess='shared'/>
    <interconnects>
      <latency initiator='0' target='0' type='access' value='5'/>
      <latency initiator='0' target='0' cache='1' type='access' value='10'/>
      <bandwidth initiator='0' target='0' type='access' value='204800' unit='KiB'/>
    interconnects>
  numa>
  ...
cpu>
...

从6.6.0开始，cell元素可以有一个cache子元素，它描述内存邻近域的内存侧缓存。cache元素具有描述缓存级别的level属性，因此该元素可以被重复多次以描述缓存的不同级别。

然后，cache元素具有以下强制属性：

​ level

​ 描述所涉及的缓存级别。

​ assocaitivity

​ 描述缓存关联性(可接受的值为none、direct和full)。

​ policy

​ 描述缓存写关联性(可接受的值为none、writeback和writethrough)。

cache元素有两个强制性的子元素:size和line，它们描述缓存大小和缓存行大小。两个元素都接受两个属性:value和unit，它们设置相应缓存属性的值.

NUMA描述有一个可选的interconnects元素，用于描述启动邻近域(处理器或I/O)和目标邻近域(内存)之间的规范化内存读/写延迟，读/写带宽。

interconnects元素可以具有零个或多个latency子元素来描述两个内存节点之间的延迟，以及零个或多个bandwith子元素来描述两个内存节点之间的带宽。它们都有以下强制属性:

​ initiator

​ 指的是源NUMA节点

​ target

​ 指的是目的NUMA节点

​ type

​ 访问的类型。取值范围:access、read、write

​ value

​ 实际值。对于延迟，该值以纳秒为单位，对于带宽，该值以千字节每秒为单位。使用附加的unit属性来改变单位。

为了描述从一个NUMA节点到另一个NUMA节点的缓存的延迟，latency元素具有可选的cache属性，该属性与target属性相结合，创建对远程NUMA节点缓存级别的完整引用。例如，target='0' cache='1'表示NUMA节点0的第一级缓存。

1.15 事件配置(Envents configuration)

有时需要覆盖对各种事件采取的默认操作。并非所有hypervisor都支持所有事件和操作。这些操作可能是调用libvirt api virDomainReboot、virDomainShutdown或virDomainShutdownFlags的结果。使用virsh reboot或virsh shutdown也会触发该事件。

...
<on_poweroff>destroyon_poweroff>
<on_reboot>restarton_reboot>
<on_crash>restarton_crash>
<on_lockfailure>poweroffon_lockfailure>
...

以下元素集合允许在guest操作系统触发生命周期操作时指定操作。一个常见的用例是在进行初始操作系统安装时强制将重新启动视为关机。这允许在安装后的第一次启动时重新配置VM。

on_poweroff
此元素的内容指定guest请求关机时要采取的操作。
on_reboot
此元素的内容指定guest请求重新启动时要采取的操作。
on_crash
此元素的内容指定guest崩溃时要采取的操作。

这些状态中的每一个都允许相同的四种可能的操作。
destroy
该域名将被完全终止，所有资源将被释放。
restart
该域将被终止，然后使用相同的配置重新启动。
preserve
域将被终止，其资源将被保留以允许分析。
rename-restart
该域将被终止，然后用一个新名称重新启动。(仅支持libxl hypervisor驱动程序。)

QEMU/KVM/HVF支持on_poweroff和on_reboot事件处理destroy和restart动作，但是设置为 restart的on_poweroff 和设置为destroy的on_reboot 的组合是禁止的。

从0.8.4开始，on_crash事件支持这些附加操作。

​ coredump-destroy

​ 崩溃的域的核心将被转储，然后该域将完全终止并释放所有资源

​ coredump-restart

​ 崩溃的域的核心将被转储，然后该域将使用相同的配置重新启动

从3.9.0起，可以通过virDomainSetLifecycleAction API配置生命周期事件。

on_lockfailure元素(自1.0.0起)可用于配置当锁管理器丢失资源锁时应采取的操作。libvirt可以识别以下操作，尽管并非所有操作都需要单独的锁管理器支持。如果未指定任何操作，则每个锁管理器都将执行其默认操作。

​ poweroff

​ 域将被强制关闭电源。

​ restart

​ 域将关闭电源并重新启动以重新获取其锁定

​ pause

​ 域将暂停，以便在锁问题解决后可以手动恢复。

​ ignore

​ 保持域像什么都没发生一样运行。

1.16 (Power Management)

0.10.2起，可以强制启用或禁用到guestOS的BIOS广告。(注意：仅支持qemu驱动程序)

...
<pm>
  <suspend-to-disk enabled='no'/>
  <suspend-to-mem enabled='yes'/>
pm>
...

pm

​ 这些元素启用(“是”)或禁用(“否”)BIOS对S3(暂停到内存)和S4(暂停到磁盘)ACPI睡眠状态的支持。如果没有指定任何内容，那么hypervisor将保留其默认值。注意：此设置不能阻止guest操作系统执行挂起，因为guest操作系统本身可以选择绕过睡眠状态的不可用性(例如，通过完全关闭S4)。

1.17 (Hypervisor features)

Hypervisor可以允许打开/关闭某些CPU/机器功能。

...
<features>
  <pae/>
  <acpi/>
  <apic/>
  <hap/>
  <privnet/>
  <hyperv mode='custom'>
    <relaxed state='on'/>
    <vapic state='on'/>
    <spinlocks state='on' retries='4096'/>
    <vpindex state='on'/>
    <runtime state='on'/>
    <synic state='on'/>
    <stimer state='on'>
      <direct state='on'/>
    stimer>
    <reset state='on'/>
    <vendor_id state='on' value='KVM Hv'/>
    <frequencies state='on'/>
    <reenlightenment state='on'/>
    <tlbflush state='on'/>
    <ipi state='on'/>
    <evmcs state='on'/>
  hyperv>
  <kvm>
    <hidden state='on'/>
    <hint-dedicated state='on'/>
    <poll-control state='on'/>
    <pv-ipi state='off'/>
    <dirty-ring state='on' size='4096'/>
  kvm>
  <xen>
    <e820_host state='on'/>
    <passthrough state='on' mode='share_pt'/>
  xen>
  <pvspinlock state='on'/>
  <gic version='2'/>
  <ioapic driver='qemu'/>
  <hpt resizing='required'>
    <maxpagesize unit='MiB'>16maxpagesize>
  hpt>
  <vmcoreinfo state='on'/>
  <smm state='on'>
    <tseg unit='MiB'>48tseg>
  smm>
  <htm state='on'/>
  <ccf-assist state='on'/>
  <msrs unknown='ignore'/>
  <cfpc value='workaround'/>
  <sbbc value='workaround'/>
  <ibs value='fixed-na'/>
  <tcg>
    <tb-cache unit='MiB'>128tb-cache>
  tcg>
  <async-teardown enabled='yes'/>
features>
...

所有功能都列在features元素中，省略一个可切换的功能标签会将其关闭。通过询问功能XML和域功能XML可以找到可用的功能，但完全虚拟化域的常见集合是：

​ pae

​ 物理地址扩展模式允许32位guests寻址超过4GB的内存。

​ acpi

​ ACPI对于电源管理非常有用，例如，对于KVM或HVF客户，它是正常关机工作所必需的。

​ apic

​ APIC允许使用可编程的IRQ管理。0.10.2(仅限QEMU)，有一个可选属性eoi，其值为on和off，用于切换guest的eoi(中断结束)的可用性。

​ hap

​ 根据state属性(值on、off)启用或禁用硬件辅助分页。如果hyperviosr检测到硬件辅助分页可用，默认设置为on。

​ viridian

​ 启用Viridian虚拟化扩展，用于对半虚拟化guest OS进行虚拟化。

​ privnet

​ 始终创建专用网络命名空间。如果定义了任何接口设备，则会自动设置。此功能仅与基于容器的虚拟化驱动程序(如LXC)相关。

​ hyperv

​ 启用各种功能，改善运行Microsoft Windows的guest的行为。

​

8.0.0起，可以通过将mode属性设置为以下值之一来进一步配置hyperviosr：

​ custom

​ 精确设置指定的功能。

​ passthrough

​ 启用hypervisor当前支持的所有功能，即使是libvirt无法理解的功能。使用passthrough迁移虚拟机在源主机和目标主机的硬件、QEMU版本、微码版本和配置不完全相同的情况下是危险的。如果尝试这样的迁移，那么在目标主机上恢复执行时，虚拟机可能会挂起或崩溃。根据hypervisor的版本，虚拟CPU可能会包含可能阻止迁移到即使是相同主机的功能。

​ mode属性可以省略，并且将默认为custom自定义。

pvspinlock

​ 通知guest主机支持准虚拟自旋锁，例如通过公开pvticketlocks机制。可以使用state='off'属性显式禁用此功能。

kvm

​ 用于更改KVM虚拟机监控程序行为的各种功能。

xen

​ 用于于更改Xen虚拟机监控程序行为的各种功能。

pmu

​ 根据state属性(值打开、关闭、默认打开)启用或禁用客户机的性能监视单元。自1.2.12

vmport

​ 根据state属性(值on、off、默认为on)，为vmmouse等启用或禁用VMware IO端口的模拟。自1.2.16

gic

​ 使用常规中断控制器而不是APIC启用架构，以处理中断。例如，"aarch64"体系结构使用gic而不是apic。可选属性version指定GIC版本；但是，可能并非所有hypervisor都支持它。可接受的值为2、3和host。自1.2.16起

smm

​ 根据state属性(值on，off，默认值on)启用或禁用系统管理模式。自2.1.0

​ 可选的子元素tseg可用于指定专用于SMM扩展TSEG的内存量。除现有的选项(1个MIB，2 MIB和8 MIB)外，它提供了第四个选件大小，可供guest OS选择(或更确切地说是装载机)。可以将大小指定为该元素的值，可选属性unit可用于指定上述值的单元(默认为" MiB")。如果设置为0，则不会公布扩展大小，并且只有默认大小(见上文)可用。

​ 如果VM正在启动，则应该不理会此选项，除非 非常确定自己知道自己在做什么。

​ 该值是可配置的，因为无法在保证其正确工作的情况下正确进行计算。在QEMU中，用户可配置的扩展TSEG功能在pc-q35-2.9之前(包括该版本)不可用。从pc-q35-2.10开始，该功能可用，默认大小为16 MiB。这应该足以满足大约272个vCPU、总共5 GiB客户机RAM、无热插拔内存范围和32 GiB 64位PCI MMIO孔径的需求。或者适用于48个vCPU，具有1TB客户机RAM、无热插拔DIMM范围和32GB 64位PCI MMIO孔径。这些值还可以根据VM正在使用的加载器而变化。

​ 可能需要额外的大小来显著提高vCPU计数或增加地址空间(可以是内存、maxMemory、64位PCI MMIO孔径大小；每1 TiB地址空间大约8 MiB TSEG)，也可以四舍五入。

​ 由于此设置的性质类似于"客户应该有多少RAM"，建议用户查阅客户机操作系统或加载程序的文档(如果有的话)，或者通过反复更改值来进行测试，直到虚拟机成功引导。对于用户来说，另一个指导价值可能是48 MiB对于相当大的客户机(240 vCPU和4TB客户机RAM)应该足够了，但这是故意不设置为默认值，因为48 MiB的不可用RAM对于小客户机来说可能太多了(例如512 MiB的RAM)。

​ 有关单位属性的更多详细信息，请参阅内存分配1.7 Memory Allocation。自4.5.0起(仅限QEMU)

ioapic

​ 调优I/O APIC。驱动程序属性的可能值是:kvm (kvm域的默认值)和qemu，它将I/O APIC放在用户空间中，也称为拆分I/O APIC模式。3.4.0以后(仅QEMU/KVM)

hpt

​ 配置pSeries客户机的HPT(Hash Page Table哈希页表)。启用了resizing属性的可能值，如果客户机和主机都支持HPT调整大小，则启用HPT调整大小;disabled，这将导致禁用HPT调整大小，而不管客户和主机支持;required，这将阻止客户机启动，除非客户机和主机都支持HPT调整大小。如果未定义该属性，则将使用hypervisor默认值。自3.10.0(仅QEMU/KVM)。

​ 可选的maxpagesize子元素可用于限制HPT客户机可用的页面大小。常用值为64KiB、16MiB和16GiB;如果没有指定，将使用hyperviosr默认值。自4.5.0(仅QEMU/KVM)。

vmcoreinfo

​ 启用QEMU vmcoreinfo设备，让客户内核保存调试细节。从4.4.0开始(仅限QEMU)

htm

​ 为pSeries客户机配置HTM(硬件转换内存)可用性。state属性的可能值是on和off。如果未定义该属性，则将使用hypervisor默认值。从4.6.0开始(仅QEMU/KVM)

nested-hv

​ 为pSeries客户机配置嵌套HV可用性。这需要从主机(L0)启用才能有效;如果计划在(L1)客户机中运行嵌套的(L2)客户机，那么在(L1)客户机中提供HV支持是非常可取的，因为这将使那些嵌套的客户机具有比使用KVM PR或TCG时更好的性能。state属性的可能值是on和off。如果未定义该属性，则将使用hypervisor默认值。4.10.0起(仅QEMU/KVM)

msrs

​ 有些客户机可能需要忽略未知的模型特定寄存器(Model Specific Registers， MSR)读写。可以通过将msrs的未知属性设置为ignore来切换这种情况。如果未定义该属性或将其设置为fault，则不会忽略未知的读写。自5.1.0以来(仅限bhyve)

ccf-assist

​ 为pSeries客户机配置ccf-assist (Count Cache Flush Assist)可用性。state属性的可能值是on和off。如果未定义该属性，则将使用hypervisor默认值。自5.9.0(仅QEMU/KVM)

cfpc

​ 为pSeries客户配置cfpc(特权更改时缓存刷新)可用性。value属性的可能值是坏的(没有保护)、工作区(可用的软件工作区)和固定的(在硬件中固定的)。如果未定义该属性，则将使用hypervisor默认值。自6.3.0(仅QEMU/KVM)以来，

sbbc

​ 为pSeries客户配置了sbbc(Speculation Barrier Bounds Checking， 推测栅栏边界检查)可用性。value属性的可能值是broken(没有保护)、workaround(可用的软件工作区)和fixed(在硬件中固定的)。如果未定义该属性，则将使用hypervisor默认值。从6.3.0开始(仅QEMU/KVM)

ibs

​ 为pSeries客户配置ibs(Indirect Branch Speculation， 间接分支推测)可用性。value属性的可能值broken(没有保护)、workaround(计数缓存刷新)、fixed-ibs(通过序列化间接分支修复)、fixed-ccd(通过禁用缓存计数修复)和fixed-na(在硬件上修复-不再适用)。如果未定义该属性，则将使用hypervisor默认值。从6.3.0(仅QEMU/KVM)起，

tcg

​ 各种特性来改变tcg加速器的行为。

async-teardown

​ 根据enabled属性(值yes或no)启用或禁用QEMU异步拆解以改善客户机上的内存回收。自9.6.0起(仅限QEMU)

1.18 (Time keeping)

客户机时钟通常是从主机时钟初始化的。大多数操作系统期望硬件时钟保持在UTC，这是默认的。然而，Windows期望它是在所谓的"本地时间"。

...
<clock offset='localtime'>
  <timer name='rtc' tickpolicy='catchup' track='guest'>
    <catchup threshold='123' slew='120' limit='10000'/>
  timer>
  <timer name='pit' tickpolicy='delay'/>
clock>
...

clock

​ offset属性有四个可能的值，允许对如何将客户机时钟同步到主机进行细粒度控制。注意，并非所有hypervisor都支持所有模式。

​ utc

​ 当启动时，客户时钟将始终同步到utc。从0.9.11开始，utc模式可以转换为variable模式，这可以通过使用调整属性来控制。如果值为’reset’，则永远不会完成转换(不是所有hypervisor都可以在每次启动时同步UTC;在这些hypervisor上使用reset将导致错误)。数值强制转换为variable模式，使用该值作为初始调整。默认的调整是特定于hypervisor的。

​ localtime

​ 客户时钟将在启动时同步到主机配置的时区(如果有的话)。从0.9.11开始，调整属性的行为与在utc模式下相同。

​ timezone

​ 使用timezone属性将客户时钟同步到请求的时区。自0.7.7

​ variable

​ 客户时钟将根据basis属性，相对于UTC或本地时间应用任意偏移。相对于UTC(或本地时间)的增量是使用adjustment属性以秒为单位指定的。客户机可以随时调整RTC，并期望在下次重新启动时兑现。这与"utc"和"localtime"模式(可选属性adjustment=“重置”)形成对比，后者在每次重新启动时都会丢失RTC调整。自0.7.7自0.9.11以来，basis属性可以是"utc"(默认值)或"localtime"。

​ absolute

​ 客户时钟在域启动时将始终设置为start属性的值。start属性的参数是epoch时间戳。8.4.0起。

一个clock可以有零个或多个定时器子元素。自0.8.0起

timer

​ 每个定时器元素都需要一个name属性，并具有其他依赖于指定name的可选属性。各种hypervisor支持不同的属性组合。

​ name

​ name属性选择要修改的计时器，可以是"platform"(当前不支持)、“hpet”(xen，qemu，lxc)、“kvmclock”(qemu)、“pit”(qemo)、“rtc”(qemu， lxc)“tsc”(xen，qemu-自3.2.0起)、“hyperclock”(qemu，自1.2.2起)或"armvtimer"(qemcu，自6.1.0起)。hypervclock计时器为运行Microsoft Windows操作系统的客户机添加了对iTSC功能的参考时间计数器和参考页面的支持。

​ track

​ track属性指定计时器跟踪的内容，可以是"boot"、“guest”、“wall"或"realtime”。仅对name="rtc"或name="platform"有效。

​ tickpolicy

​ tickpolicy属性确定当QEMU错过向客户机注入tick的最后期限时会发生什么。例如，这可能是因为客户机被暂停。

​ delay

​ 继续以正常速率发送tick。guest操作系统不会注意到任何问题，因为从它的角度来看，时间将继续正常流动。guest的时间现在应该正好落后于host的时间，刚好是错过ticks的时间。

​ catchup

​ 以更高的速率发送tick，以赶上错过的tick。guest OS不会注意到任何问题，因为从它的角度来看，时间将继续正常流动。一旦计时器设法赶上了所有丢失的tick，guest和host中的时间应该匹配。

​ merge

​ 将遗漏的tick合并为一个tick并注入。guest时间可能会延迟，具体取决于操作系统对tick合并的响应

​ discard

​ 扔掉错过的tick，继续正常的未来注入。guest OS将看到计时器一次提前一个潜在的相当大的量，就好像干预的时间块根本不存在一样；更不用说，这样的突然跳跃很容易混淆没有专门准备处理它的guest OS。假设guest OS能够正确处理时间跳跃，那么guest和host中的时间现在应该匹配。

​ 如果策略是"catchup"，catchup子元素中可以有更多详细信息

​ catchup

​ catchup元素有三个可选属性，每个属性都是正整数。属性包括threshold，slew和limit。

​ 请注意，hypervisors不需要支持所有时间源中的所有策略

​ frequency

​ frequency属性是一个无符号整数，指定name="tsc"运行的频率。

​ mode

​ mode属性控制name="tsc"计时器的管理方式，可以是"auto"、“native”、“emulate”、“paravirt"或"smpsafe”。总是模拟其他计时器。

​ present

​ present属性可以是"yes"或"no"，以指定特定计时器是否可用于guest。

1.19 (Performance monitoring events)

一些平台允许监控虚拟机的性能和内部执行的代码。若要启用性能监视事件，可以在perf元素中指定它们，也可以通过virDomainSetPerfEvents API启用它们。然后使用virConnectGetAllDomainStats API检索性能值。自2.0.0起.

...
<perf>
  <event name='cmt' enabled='yes'/>
  <event name='mbmt' enabled='no'/>
  <event name='mbml' enabled='yes'/>
  <event name='cpu_cycles' enabled='no'/>
  <event name='instructions' enabled='yes'/>
  <event name='cache_references' enabled='no'/>
  <event name='cache_misses' enabled='no'/>
  <event name='branch_instructions' enabled='no'/>
  <event name='branch_misses' enabled='no'/>
  <event name='bus_cycles' enabled='no'/>
  <event name='stalled_cycles_frontend' enabled='no'/>
  <event name='stalled_cycles_backend' enabled='no'/>
  <event name='ref_cpu_cycles' enabled='no'/>
  <event name='cpu_clock' enabled='no'/>
  <event name='task_clock' enabled='no'/>
  <event name='page_faults' enabled='no'/>
  <event name='context_switches' enabled='no'/>
  <event name='cpu_migrations' enabled='no'/>
  <event name='page_faults_min' enabled='no'/>
  <event name='page_faults_maj' enabled='no'/>
  <event name='alignment_faults' enabled='no'/>
  <event name='emulation_faults' enabled='no'/>
perf>
...

1.20 (Devices)

最后一组XML元素都用于描述提供给客户域的设备。所有设备都作为主device元素的子元素出现。自0.1.3起

...
<devices>
  <emulator>/usr/lib/xen/bin/qemu-dmemulator>
devices>
...

emulator

​ emulator元素的内容指定设备模型模拟器二进制文件的完全限定路径。 capabilities XML 指定了建议用于每个特定域类型/体系结构组合的默认仿真器。

为了帮助用户识别他们关心的设备，每个设备都可以有直接的子别名alias元素，然后该元素具有name属性，用户可以在其中存储设备的标识符。标识符必须有"ua-"前缀，并且在域中必须是唯一的。此外，标识符必须仅由以下字符组成：[a-zA-Z0-9_-]。自3.9.0

<devices>
  <disk type='file'>
    <alias name='ua-myDisk'/>
  disk>
  <interface type='network' trustGuestRxFilters='yes'>
    <alias name='ua-myNIC'/>
  interface>
  ...
devices>

1.20.1 (Hard drives， floppy disks， CDROMs)

任何看起来像磁盘的设备，无论是软盘、硬盘、cdrom还是半虚拟化驱动程序，都是通过disk元素指定的。

...
<devices>
  <disk type='file' snapshot='external'>
    <driver name="tap" type="aio" cache="default"/>
    <source file='/var/lib/xen/images/fv0' startupPolicy='optional'>
      <seclabel relabel='no'/>
    source>
    <target dev='hda' bus='ide'/>
    <iotune>
      <total_bytes_sec>10000000total_bytes_sec>
      <read_iops_sec>400000read_iops_sec>
      <write_iops_sec>100000write_iops_sec>
    iotune>
    <boot order='2'/>
    <encryption type='...'>
      ...
    encryption>
    <shareable/>
    <serial>
      ...
    serial>
  disk>
    ...
  <disk type='network'>
    <driver name="qemu" type="raw" io="threads" ioeventfd="on" event_idx="off"/>
    <source protocol="sheepdog" name="image_name">
      <host name="hostname" port="7000"/>
    source>
    <target dev="hdb" bus="ide"/>
    <boot order='1'/>
    <transient/>
    <address type='drive' controller='0' bus='1' unit='0'/>
  disk>
  <disk type='network'>
    <driver name="qemu" type="raw"/>
    <source protocol="rbd" name="image_name2">
      <host name="hostname" port="7000"/>
      <snapshot name="snapname"/>
      <config file="/path/to/file"/>
      <auth username='myuser'>
        <secret type='ceph' usage='mypassid'/>
      auth>
    source>
    <target dev="hdc" bus="ide"/>
  disk>
  <disk type='block' device='cdrom'>
    <driver name='qemu' type='raw'/>
    <target dev='hdd' bus='ide' tray='open'/>
    <readonly/>
  disk>
  <disk type='network' device='cdrom'>
    <driver name='qemu' type='raw'/>
    <source protocol="http" name="url_path" query="foo=bar&baz=flurb>
      "hostname" port="80"/>
      <cookies>
        <cookie name="test">somevaluecookie>
      cookies>
      <readahead size='65536'/>
      <timeout seconds='6'/>
    source>
    <target dev='hde' bus='ide' tray='open'/>
    <readonly/>
  disk>
  <disk type='network' device='cdrom'>
    <driver name='qemu' type='raw'/>
    <source protocol="https" name="url_path">
      <host name="hostname" port="443"/>
      <ssl verify="no"/>
    source>
    <target dev='hdf' bus='ide' tray='open'/>
    <readonly/>
  disk>
  <disk type='network' device='cdrom'>
    <driver name='qemu' type='raw'/>
    <source protocol="ftp" name="url_path">
      <host name="hostname" port="21"/>
    source>
    <target dev='hdg' bus='ide' tray='open'/>
    <readonly/>
  disk>
  <disk type='network' device='cdrom'>
    <driver name='qemu' type='raw'/>
    <source protocol="ftps" name="url_path">
      <host name="hostname" port="990"/>
    source>
    <target dev='hdh' bus='ide' tray='open'/>
    <readonly/>
  disk>
  <disk type='network' device='cdrom'>
    <driver name='qemu' type='raw'/>
    <source protocol="tftp" name="url_path">
      <host name="hostname" port="69"/>
    source>
    <target dev='hdi' bus='ide' tray='open' rotation_rate='7200'/>
    <readonly/>
  disk>
  <disk type='block' device='lun'>
    <driver name='qemu' type='raw'/>
    <source dev='/dev/sda'>
      <slices>
        <slice type='storage' offset='12345' size='123'/>
      slices>
      <reservations managed='no'>
        <source type='unix' path='/path/to/qemu-pr-helper' mode='client'/>
      reservations>
    source>
    <target dev='sda' bus='scsi' rotation_rate='1'/>
    <address type='drive' controller='0' bus='0' target='3' unit='0'/>
  disk>
  <disk type='block' device='disk'>
    <driver name='qemu' type='raw'/>
    <source dev='/dev/sda'/>
    <geometry cyls='16383' heads='16' secs='63' trans='lba'/>
    <blockio logical_block_size='512' physical_block_size='4096' discard_granularity='4096'/>
    <target dev='hdj' bus='ide'/>
  disk>
  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw'/>
    <source pool='blk-pool0' volume='blk-pool0-vol0'/>
    <target dev='hdk' bus='ide'/>
  disk>
  <disk type='network' device='disk'>
    <driver name='qemu' type='raw'/>
    <source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/2'>
      <host name='example.com' port='3260'/>
      <auth username='myuser'>
        <secret type='iscsi' usage='libvirtiscsi'/>
      auth>
    source>
    <target dev='vda' bus='virtio'/>
  disk>
  <disk type='network' device='lun'>
    <driver name='qemu' type='raw'/>
    <source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/1'>
      <host name='example.com' port='3260'/>
      <auth username='myuser'>
        <secret type='iscsi' usage='libvirtiscsi'/>
      auth>
    source>
    <target dev='sdb' bus='scsi'/>
  disk>
  <disk type='network' device='disk'>
    <driver name='qemu' type='raw'/>
    <source protocol='nfs' name='PATH'>
      <host name='example.com'/>
      <identity user='USER' group='GROUP'/>
    source>
    <target dev='vda' bus='virtio'/>
  disk>
  <disk type='network' device='lun'>
    <driver name='qemu' type='raw'/>
    <source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/0'>
      <host name='example.com' port='3260'/>
      <initiator>
        <iqn name='iqn.2013-07.com.example:client'/>
      initiator>
    source>
    <target dev='sdb' bus='scsi'/>
  disk>
  <disk type='dir' device='floppy'>
    <driver name='qemu' type='fat'/>
    <source dir='/var/somefiles'>
    <target dev='fda'/>
    <readonly/>
  disk>
  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw'/>
    <source pool='iscsi-pool' volume='unit:0:0:1' mode='host'/>
    <target dev='vdb' bus='virtio'/>
  disk>
  <disk type='volume' device='disk'>
    <driver name='qemu' type='raw'/>
    <source pool='iscsi-pool' volume='unit:0:0:2' mode='direct'/>
    <target dev='vdc' bus='virtio'/>
  disk>
  <disk type='file' device='disk'>
    <driver name='qemu' type='qcow2' queues='4' queue_size='256' />
    <source file='/var/lib/libvirt/images/domain.qcow'/>
    <backingStore type='file'>
      <format type='qcow2'/>
      <source file='/var/lib/libvirt/images/snapshot.qcow'/>
      <backingStore type='block'>
        <format type='raw'/>
        <source dev='/dev/mapper/base'/>
        <backingStore/>
      backingStore>
    backingStore>
    <target dev='vdd' bus='virtio'/>
  disk>
  <disk type='nvme' device='disk'>
    <driver name='qemu' type='raw'/>
    <source type='pci' managed='yes' namespace='1'>
      <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    source>
    <target dev='vde' bus='virtio'/>
  disk>
  <disk type='vhostuser' device='disk'>
    <driver name='qemu' type='raw'/>
    <source type='unix' path='/tmp/vhost-blk.sock'>
      <reconnect enabled='yes' timeout='10'/>
    source>
    <target dev='vdf' bus='virtio'/>
  disk>
devices>
...

disk

​ disk元素是描述磁盘的主要容器，支持以下属性：

​ type

​ 有效值为"file"、“block”、“dir”(自0.7.5起)、“network”(自0.8.7起)、或"volume"(从1.0.5起)、或者"nvme"(自6.0.0起)或"vhostuser"(自7.1.0起)，并指代磁盘的底层源。自0.0.3起

​ device

​ 指示如何向guest操作系统公开磁盘。此属性的可能值为"floppy"、“disk”、“cdrom"和"lun”，默认值为"disk"。

​ 使用"lun"(自0.9.10起)仅在协议="scsi"的类型为"块"或"网络"时有效，或者在使用iscsi源池作为模式"主机"或作为使用光纤通道存储池的NPIV虚拟主机总线适配器(vHBA)时类型为"卷"时有效。以这种方式配置，LUN的行为与"磁盘"相同，只是接受来自guest的通用SCSI命令并将其传递到物理设备。还要注意的是，device='lun’只会被实际的原始设备识别，而不会被单独的分区或LVM分区识别(在这种情况下，内核会拒绝通用SCSI命令，使其与device='disk’相同)。自0.1.4

​ model

​ 指示磁盘的模拟设备型号。通常，这只由总线属性表示，但对于总线"virtio"，可以用"virtiotransitional"、"virtionon-transitional"或"virtio"进一步指定模型。有关更多详细信息，请参阅Virtio过渡设备。自5.2.0起

​ rawio

​ 指示磁盘是否需要rawio功能。有效设置为"是"或"否"(默认为"否")。如果域中的任何一个磁盘的rawio=“yes”，则将为域中的所有磁盘启用rawio功能(因为在QEMU的情况下，只能根据每个进程设置此功能)。此属性仅在设备为"lun"时有效。注意，rawio打算限制每个设备的能力，然而，当前的QEMU实现为域进程提供了比这更广泛的能力(基于每个进程，影响所有域磁盘)。为了在这个阶段尽可能地限制QEMU驱动程序的功能，建议使用sgio，它比rawio更安全。自0.9.10

​ sgio

​ 如果hypervisor和操作系统支持，则指示是否为磁盘筛选无特权的SG_IO命令。有效设置为"filtered"已筛选或"unfiltered"未筛选，默认设置为"filtered"。仅当device为"lun"时可用。自1.0.2起

​ snapshot

​ 指示磁盘快照过程中磁盘的默认行为：internal需要一种文件格式，如qcow2，可以存储快照和自快照以来的数据更改；external将快照与实时数据分离；否表示磁盘不会参与快照；和手动允许通过非托管存储提供程序执行快照。只读磁盘默认为no，而其他磁盘的默认值取决于hypervisor的功能。在 domain snapshot creation的过程中，某些hypervisor还允许按快照进行选择。并非所有快照模式都受支持；例如，使用临时磁盘启用快照通常没有意义。自0.9.5

source

​ 磁盘source的表示取决于磁盘类型属性值，如下所示：

​ file

​ file属性指定存放磁盘的文件的完全限定路径。自0.0.3起

​ 9.0.0起，可以添加一个新的可选属性fdgroup，指示通过virDomainFDAssociate()API通过与域对象关联的文件描述符访问磁盘，而不是打开文件。libvirt不一定要通过文件系统访问这些文件。在执行块操作时，通过file传递的文件名仍然可以用于生成写入镜像元数据的路径，但libvirt不会以本机方式访问这些路径。

​ block

​ dev属性指定要用作磁盘的主机设备的完全限定路径。自0.0.3起

​ dir

​ dir属性指定要用作磁盘的目录的完全限定路径。自0.7.5

​ 请注意，大多数支持目录磁盘的hypervisor都是通过公开模拟块设备来实现这一点的，其中模拟文件系统填充了配置目录的内容。由于客户机操作系统可能会缓存文件系统元数据，因此对目录的外部更改可能不会出现在客户机中，和/或可能导致可从VM观察到损坏的数据。

​ 模拟文件系统的格式由元素的format属性控制。目前只支持fat格式。Hypervisor可能只支持模式。

​ network

​ protocol属性指定访问请求的映像的协议。可能的值有"nbd"、“iscsi”、“rbd”、“sheepdog”、“gluster”、“vxhs”、"nfs、“http”、“https”、“ftp”、“ftps"或"tftp”。

​ 对于nbd以外的任何协议protocol，必须使用附加属性name来指定将使用的卷/映像。

​ 对于"nbd"，name属性是可选的。可以通过将tls属性设置为yes来启用NBD的TLS传输。对于QEMU hypervisor，TLS环境的使用也可以通过/etc/libvirt/QEMU.conf中的nbd_TLS和nbd_TLS_x509_cert_dir在主机上进行全局控制。(自4.5.0起为’TLS’)自8.2.0起，可选属性tlsHostname可用于覆盖用于TLS证书验证的nbd服务器的预期主机名。

​ 对于http和https协议，可选的属性query指定查询字符串。(自6.2.0起)

​ 对于"iscsi"(自1.0.4起)，name属性可能包括一个逻辑单元号，用斜线与目标名称隔开(例如，iqn.2013-07.com.example:iscsi pool/1)。如果未指定，则默认LUN为零。

​ 对于"vxhs"(自3.8.0起)，name是由HyperScale服务器分配的卷的UUID。此外，可选属性tls(仅限QEMU)可用于控制VxHS块设备是否会利用hypervisor配置的tls X.509证书环境来加密数据通道。对于QEMU虚拟机监控程序，TLS环境的使用也可以通过文件/etc/libvirt/QEMU.conf中的 vxhs_TLS 和 vxhs_TLS_x509_cert_dir 或default_TLS_x509 _cert_dr设置在主机上进行全局控制。如果启用了vxhs_TLS，则除非域TLS属性设置为"no"，否则libvirt将使用主机配置的TLS环境。如果tls属性设置为"yes"，则无论qemu.conf设置如何，都将尝试tls身份验证。

​ 自0.8.7

​ volume

​ 底层磁盘源由属性pool和volume表示。属性pool指定磁盘源所在的存储池(由libvirt管理)的名称。属性volume指定用作磁盘源的存储卷(由libvirt管理)的名称。volume属性的值将是virsh-vol-list[pool Name]命令的“Name”列的输出。

​ 使用属性mode(自1.1.1起)指示如何将LUN表示为磁盘源。有效值为“direct”和“host”。如果未指定mode，则默认使用“主机”。使用“direct”作为mode值表示使用 storage pool’s的source元素host属性作为磁盘源来生成libscsi URI(例如“file”=iscsi://example.com:3260/iqn.2013-07.com.example:iscsi pool/1’)。使用“host”作为mode值表示使用LUN在主机上显示的路径(例如，‘file=/dev/disk/by-path/ip-example.com:3260 iscsi iqn.2013-07.com.example:iscsi-pol-LUN-1’)。使用iscsi资源池中的LUN提供了与使用type为“block”或“network”配置的磁盘相同的功能，并且device为“lun”并且可以由guest使用。自1.0.5起

​ nvme

​ 要为NVMe磁盘指定磁盘源，源元素具有以下属性：

​ type

​ 在address子元素中指定的地址类型。目前，只接受pci值。

​ managed

​ 此属性指示libvirt在域启动时自动分离NVMe控制器(yes)，或者期望系统管理员分离控制器(no)。

​ namespace

​ 应分配给域的命名空间ID。根据NVMe标准，命名空间编号从1开始，包括。

​ 和的区别在于，后者是具有所有限制的普通主机设备分配(例如，没有实时迁移)，而前者使hypervisor通过hypervisor的块层运行nvme磁盘，从而启用该层提供的所有功能(例如，快照、域迁移等)。此外，由于nvme磁盘与其PCI驱动程序没有绑定，主机内核存储堆栈不涉及(与通过传递say /dev/nvme0n1相比)，因此可以实现更低的延迟。

​ vhostuser

​ 使hypervisor能够使用vhost用户协议连接到另一个进程。需要为VM配置共享内存，有关更多详细信息，请参阅memoryBacking元素的access模式(请参阅1.8Memory Backing)。

​ source元素具有以下强制属性：

​ type

​ 字符设备的类型。目前只支持unix类型。

​ path

​ 要用作磁盘源的unixsocket的路径。

请注意，vhost服务器同时替换了磁盘前端和后端，因此几乎所有的磁盘属性都无法通过XML对此磁盘类型进行配置。此外，此磁盘类型不支持块作业、增量备份和快照等功能。

对于“file”、“block”和“volume”，可以使用一个或多个可选的子元素seclabel(请参阅1.21Security label)来覆盖仅针对该源文件的域安全标签策略。(注意，对于“卷”类型的磁盘，seclabel仅在指定的存储卷为“文件”或“块”类型时有效)。自0.9.9

source元素也可以具有与backingStore的index属性相同语义的index属性。
source元素可以包含以下子元素:

​ host

​ 当磁盘type为“network”时，source可以有零个或多个host子元素，用于指定要连接的主机。host元素支持4个属性，即:“name”、“port”、“transport"和"socket”，分别指定主机名、端口号、传输类型和到socket的路径。此元素的含义和元素的数量取决于协议属性。

​ Gluster支持“tcp”、“rdma”、“unix”作为传输属性的有效值。NBD支持“tcp”和“unix”。其他仅支持“tcp”。如果没有指定，则假定为“tcp”。如果传输是“unix”，socket属性指定AF_UNIXsocket的路径。NFS只支持使用“tcp”传输，根本不支持使用端口，因此必须省略它。

​ snapshot

​ snapshot元素的name属性可以指定一个内部快照名称，作为存储协议的源。从1.2.11开始支持rbd(仅QEMU)。

​ config

​ 元素的file属性提供了指向配置文件的完全限定路径，该配置文件将作为参数提供给网络存储协议的客户端。从1.2.11开始支持rbd(仅QEMU)。

​ auth

​ 从libvirt 3.9.0开始，auth元素支持磁盘type“network”，该类型使用带有协议属性“rbd”或“iscsi”的source元素。如果存在auth元素，则提供访问源所需的身份验证凭据。它包括一个强制属性username，用于标识在身份验证期间使用的用户名，以及一个带有强制属性type的子元素secret，用于绑定到一个持有实际密码或其他凭据的 libvirt secret object (域XML故意不公开密码，只公开对管理密码的对象的引用)。已知的秘密类型是“ceph”用于ceph RBD网络源，“iscsi”用于iscsi目标的CHAP认证。两者都需要与秘密对象的uuid相匹配的uuid属性，或者与秘密对象中指定的键相匹配的usage属性。

​ encryption

​ 从libvirt 3.9.0开始，对于加密的存储源，encryption可以是source元素的子元素。如果存在，则指定如何加密存储源，请参阅Storage Encryption 页面以获取更多信息。请注意，加密的qcow格式已被破坏，因此不再支持与磁盘映像一起使用。(从libvirt 4.5.0开始)

​ reservations

​ 从libvirt 4.4.0开始，reservations可以是用于存储源(仅QEMU驱动程序)的source元素的子元素。如果存在，则支持对基于SCSI的磁盘进行持久预留。元素有一个强制属性managed，使用接受的值yes和no进行管理。如果启用了managed， libvirt准备和管理所需的任何资源。在不管理持久预留时，hypervisor充当客户机，必须在子元素source中提供到服务器socket的路径，该子元素源当前仅接受以下属性:type(一个值unix)、path(到socket的路径)和mode(接受一个值client(指定hypervisor的角色)。建议允许libvirt管理持久预留。

​ initiator启动器

​ 从libvirt 4.7.0开始，initiator元素支持磁盘type“network”，它使用带有协议属性“iscsi”的source元素。如果存在，initiator元素提供了通过强制属性name访问源所需的启动器IQN。

​ address

​ 对于nvme类型的磁盘，此元素指定主机nvme控制器的PCI地址。6.0.0起

​ slices

​ 使用slice子元素对slices元素进行切片，因此允许配置镜像格式(slice type='storage')在存储源中的位置偏移量和大小，或镜像格式容器中的guest数据(未来扩展)。offset和size值的单位是字节。自6.1.0起

​ ssl

​ 对于https和ftps访问的存储，可以使用此元素调整SSL传输参数。verify属性允许打开或关闭SSL证书验证。支持的取值为yes和no。自6.2.0

​ cookies

​ 针对http和https访问的存储可以传递一个或多个cookie。cookie的名称和值必须符合HTTP规范。自6.2.0

​ readahead

​ readahead成员有一个size属性，用于指定支持预读缓冲区的字节大小。注意，0被认为是没有提供值。从6.2.0 开始

​ timeout

​ timeout元素有一个seconds属性，用于指定支持的协议的连接超时时间，单位为秒。注意，0被认为是没有提供值。自6.2.0

​ identity

​ 当使用nfs协议时，它用于提供有关用户和组的配置信息。元素有两个属性，user和group。用户可以将这些元素提供为用户或组字符串，或者直接提供为用户和组ID号，如果字符串在ID号的开头使用“+”进行格式化的话。如果省略这些属性中的任何一个，则假定该字段是当前系统的默认值。如果user和group都是默认值，则可以省略整个元素。

​ reconnect

​ 对于磁盘类型vhostuser，如果连接丢失，则配置重新连接超时。这是在启用两个强制属性和超时的情况下设置的。对于磁盘类型网络和协议nbd， QEMU nbd重新连接延迟可以通过属性delay设置:

​ enabled
​ 如果启用了重新连接功能，则接受yes和no
​ timeout
​ hypervisor尝试重新连接的秒数。
​ delay
​ 仅适用于NBD主机。所有请求暂停并在成功重新连接后重新运行的秒数。在此之后，任何延迟的请求以及成功重新连接之前的所有未来请求都将立即失败。如果不设置，QEMU的默认值为0。

​ 对于代表cdrom或软盘(device属性)的“file”或“volume”磁盘类型，可以定义在源文件不可访问时如何处理磁盘的策略。(注意，startupPolicy对卷volume类型的磁盘无效，除非指定的存储卷是文件file类型的)。这是由startupPolicy属性完成的(从0.9.7开始)，接受这些值:

​ 从1.1.2开始，startupPolicy扩展到支持除cdrom和软盘floppy之外的硬盘。在客户端冷启动时，如果某个磁盘不可访问或其磁盘链被破坏，使用startupPolicy ‘optional’，客户端将丢弃该磁盘。此功能目前不支持迁移。

backingStore

​ 该成员描述由同级source元素指定的磁盘使用的后备存储器。自1.2.4起，如果hypervisor驱动程序不支持backingStoreInput(自5.10.0起)域特性，则在输入时将忽略backingStore，仅用于输出，以描述检测到的运行域的后备链。如果支持backingStoreInput，则backingStore用作source或其他backingStore的后备映像，后备镜像元数据中记录的任何后备映像信息。空的backingStore元素意味着兄弟源是自包含的，不基于任何后备存储器。为了使检测到的后备链信息准确，后备链的格式必须正确地指定在链的每个文件的元数据中(libvirt创建的文件满足此属性，但使用现有的外部文件进行快照或块复制操作需要最终用户正确地预先创建文件)。backingStore支持以下属性:

​ type

​ type属性表示后备存储使用的磁盘类型，有关详细信息和可能的值，请参阅上面的磁盘类型属性。

​ index

​ 该属性仅在输出时有效(在输入时被忽略)，并且在执行块操作(例如通过virDomainBlockRebase API)时，可以使用它来引用磁盘链的特定部分。例如，vda[2]指具有vda目标的磁盘的index='2'的后备存储。

此外，backingStore还支持以下子元素:

​ format

​ format元素包含type属性，该属性指定后备存储的内部格式，如raw或qcow2。

​ format元素可以包含metadata_cache子元素，它与磁盘驱动程序的同名子元素具有相同的语义。

​ source

​ 该元素与disk中的source元素具有相同的结构。它指定哪个文件、设备或网络位置包含所描述的后备存储的数据。

​ backingStore

​ 如果后备存储不是自包含的，则链中的下一个元素由嵌套的backingStore元素描述。

mirror

​ 如果hypervisor已经启动了一个长时间运行的块作业操作，则会出现该元素，其中source子元素中的镜像位置最终将具有与源相同的内容，并且文件格式为子元素format(可能与源的格式不同)。source子元素的细节由镜像的type属性决定，类似于对整个disk设备元素所做的工作。job属性提到哪个API开始了操作(对于virDomainBlockRebase API是“copy”，对于virDomainBlockCommit API是“active-commit”)，从1.2.7开始。属性ready(如果存在)用于跟踪作业的进度:yes(如果磁盘已经准备好进行pivot操作)，或者从1.2.7开始，abort或pivot(如果作业正在完成过程中)。如果没有ready，则磁盘可能仍在复制。目前，这个元素只在输出中有效;它在输入时被忽略。source子元素适用于从1.2.6开始的所有两阶段作业。旧的libvirt只支持块复制到文件，从0.9.12开始;为了与老客户端兼容，这样的作业包括属性file中的冗余信息和mirror元素中的format。

target

​ target元素控制总线/设备，在总线/设备 bus / driver下，磁盘可以暴露给guest OS。dev属性表示“逻辑”设备名。不保证指定的实际设备名称映射到guest OS中的设备名称。将其视为设备排序提示。可选的bus属性指定要仿真的磁盘设备的类型。可能的值是特定于驱动程序的，典型值是"ide"， “scsi”， “virtio”， “xen”， “usb”， “sata”，或"sd" ，“sd"从1.1.2开始。如果省略，总线类型将从设备名称的样式推断(例如，名为“sda”的设备通常将使用SCSI总线导出)。可选属性tray表示可移动磁盘(即光盘或软盘)的托盘状态，取值为"open"或"closed”，默认值为"closed"。注意，tray的值可以在域运行时更新。可选属性removable用于设置USB或SCSI磁盘的可移动标志，取值为on或off，默认值为off。可选属性rotation_rate设置SCSI、IDE或SATA总线上磁盘的存储旋转速率。1025 ~ 65534为介质转速，单位为转/分。值1用于表示固态或非旋转存储。这些值不需要匹配底层主机存储的值。0.0.3起;bus属性自0.0.3 ;tray属性自0.9.11; “usb”属性值0.4.4之后; “sata”属性值从0.9.7开始; “removable”属性值自1.1.3; "rotation_rate"属性从7.3.0开始的值

iotune

​ 可选的iotune元素提供了提供额外的每设备I/O调整的能力，其值可能因每个设备而异(与blkiotune元素形成对比(请参阅1.11 Block I/O Tuning)，后者全局应用于域)。目前，唯一可用的调优是qemu的块I/O节流。该元素具有可选的子元素；任何未指定或给定值为0的子元素都意味着没有限制。自0.9.8

​ total_bytes_sec

​ 可选的total_bytes_sec元素是以字节每秒为单位的总吞吐量限制。这不能与read_bytes_sec或write_bytes_sec一起出现。

​ read_bytes_sec

​ 可选的read_bytes_sec元素是以字节每秒为单位的读取吞吐量限制。

​ write_bytes_sec

​ 可选的write_bytes_sec元素是以字节每秒为单位的写入吞吐量限制。

​ total_iops_sec

​ 可选的total_iops_sec元素是每秒的I/O操作总数。这不能与read_iops_sec或write_iops_sec一起出现。

​ read_iops_sec

​ 可选的read_iops_sec元素是每秒的读取I/O操作。

​ write_iops_sec

​ 可选的write_iops_sec元素是每秒的写I/O操作。

​ total_bytes_sec_max

​ 可选的total_bytes_sec_max元素是以字节每秒为单位的最大总吞吐量限制。这不能与read_bytes_sec_max或 write_bytes_se_max一起出现。

​ read_bytes_sec_max

​ 可选的read_bytes_sec_max元素是以字节每秒为单位的最大读取吞吐量限制。

​ write_bytes_sec_max

​ 可选的write_bytes_sec_max元素是以字节每秒为单位的最大写入吞吐量限制。

​ total_iops_sec_max

​ 可选的total_iops_sec_max元素是每秒I/O操作总数的最大值。这不能与read_iops_sec_max或write_iops_sec_max一起出现。

​ read_iops_sec_max

​ 可选的read_iops_sec_max元素是每秒最大读取I/O操作数。

​ write_iops_sec_max

​ 可选的write_iops_sec_max元素是每秒最大写入I/O操作数。

​ size_iops_sec

​ 可选的size_iops_sec元素是每秒I/O操作的大小。

​ 1.2.11和QEMU 1.7之后的吞吐量限制

​ group_name

​ 可选的group_name提供了在多个驱动器之间共享I/O限制配额的功能。这可以防止最终用户通过将1个大驱动器拆分为N个小驱动器并获得正常限制配额的N倍来规避主机提供商的限制策略。可以使用任何名称。

​ group_name自3.0.0和QEMU 2.4起

​ total_bytes_sec_max_length

​ 可选的total_bytes_sec_max_length元素是total_betes_sec_max突发周期的最大持续时间(以秒为单位)。仅在设置了total_bytes_sec_max时有效。

​ read_bytes_sec_max_length

​ 可选的read_bytes_sec_max_length元素是read_bytes_sec_max突发周期的最大持续时间(以秒为单位)。仅当设置了read_bytes_sec_max时有效。

​ write_bytes_sec_max

​ 可选的write_bytes_sec_max_length元素是write_bytes_sec_max突发周期的最大持续时间(以秒为单位)。仅在设置了write_bytes_sec_max时有效。

​ total_iop_sec_max_length

​ 可选的total_iops_sec_max_length元素是total_iops_sec_max突发周期的最大持续时间(以秒为单位)。仅当设置了total_iops_sec_max时有效。

​ read_iop_sec_max_length

​ 可选的read_iops_sec_max_length元素是read_iop_sec_max突发周期的最大持续时间(以秒为单位)。仅在设置了read_iops_sec_max时有效。

​ write_iops_sec_max

​ 可选的write_iops_sec_max_length元素是write_iop_sec_max突发周期的最大持续时间(以秒为单位)。仅在设置了write_iops_sec_max时有效。

​ 吞吐量长度z自2.4.0和QEMU 2.6起

driver

​ 可选的驱动程序元素允许指定与用于提供磁盘的hypervisor驱动程序相关的进一步细节。自0.1.8

​ · 如果hypervisor支持多个后端驱动程序，则name属性选择主后端驱动程序名称，而可选type属性提供子类型。例如，xen支持名称“tap”、“tap2”、“phy”或“file”，类型为“aio”，而qemu只支持名称“qemu”，但支持多种类型，包括“原始”、“bochs”、“qcow2”和“qed”。

​ · 可选的缓存属性控制缓存机制，可能的值为“default”、“none”、“writethrough”、“回写”、“directsync”(类似于“writethroughs”，但它绕过了主机页缓存)和“unsafe”(主机可以缓存所有磁盘io，忽略来自guest的同步请求)。自0.6.0起，“directsync”自0.9.5起，“unsafe”自0.9.7起

​ · 可选的error_policy属性控制hyperivisor在磁盘读写错误时的行为，可能的值为“stop”、“report”、“ignore”和“enospace”。自0.8.0起，自0.9.7起“report”默认值由hypervisor自行决定。还有一个可选的rerror_policy，它仅控制读取错误的行为。自0.9.7起。如果没有给出错误策略，则错误策略用于读取和写入错误。如果给定了rerror_policy，它将覆盖读取错误的error_policy。还要注意的是，“enospace”不是读取错误的有效策略，因此，如果error_policy设置为“inospace”，并且没有给出rerror_policy，则读取错误策略将保留为默认值。

​ · 可选的io属性控制I/O上的特定策略；qemu-guests支持“线程”和“本机”自0.8.8，io_uring自6.3.0(qemu 5.0)。

​ · 可选的ioeventfd 属性允许用户设置磁盘设备的域I/O异步处理。默认值由hypervisor自行决定。接受的值为"on"和"off"。启用此功能允许QEMU在单独的线程处理I/O时执行虚拟机。通常，正在进行I/O操作的虚拟机会受益于此功能，因为它可以降低系统CPU利用率。但在负载过重的主机上，可能会增加虚拟机的I/O延迟。自0.9.3版(仅适用于QEMU和KVM)。一般情况下，除非 非常确定自己知道在做什么，否则应该不要触碰此选项。

​ · 可选的event_idx属性控制设备事件处理的某些方面。该值可以是"on"或"off" - 如果为"on"，将减少虚拟机的中断和退出次数。默认值由QEMU确定；通常情况下，如果支持该功能，则默认值为"on"。如果存在使此行为不太理想的情况，此属性提供了一种强制关闭该功能的方法。自0.9.5(仅适用于QEMU和KVM)。一般情况下，除非 非常确定自己知道在做什么，否则应该不要触碰此选项。

​ · 可选的copy_on_read属性控制是否将读取的后备文件复制到镜像文件中。该值可以是"on"或"off"。在后备文件位于较慢网络上时，通过复制读取可避免重复访问相同的后备文件扇区，因此这在一般情况下默认关闭。自0.9.10(仅适用于QEMU和KVM)。

​ · 可选的discard属性控制是否忽略或传递丢弃请求(也称为"trim"或"unmap")。该值可以是"unmap"(允许传递丢弃请求)或"ignore"(忽略丢弃请求)。自1.0.6(仅适用于QEMU和KVM)。

​ · 可选的detect_zeroes属性控制是否检测零写入请求。该值可以是"off"、“on"或"unmap”。前两个值分别关闭和开启检测。第三个值(“unmap”)开启检测，并根据上述丢弃选项的值尝试从Image discard这些区域(如果discard设置为"ignore"，它将作为"on"运行)。请注意，启用检测是一个计算密集型操作，但在慢速媒体上可以节省文件空间和/或时间。自2.0.0。

​ · 可选的iothread属性将磁盘分配给域iothreads值范围定义的IOThread(请参阅1.5 IOThreads Allocation)。可以将多个磁盘分配给相同的IOThread，并从1编号到域iothreads值。仅适用于配置为使用"virtio" bus和"pci"或"ccw"address类型的磁盘设备target。自1.2.8(QEMU 2.1)。

​ · 可选的queues属性指定virtio-blk(自3.9.0)或vhost-user-blk(自7.1.0)的虚拟队列数量。

​ · 可选的queue_size属性指定virtio-blk或vhost-user-blk的每个虚拟队列大小(自7.8.0)。

​ · 对于virtio磁盘，也可以设置1.20.4Virtio-related options(自3.5.0)。

​ · 可选的metadata_cache子元素控制与存储镜像元数据的特定缓存相关的方面。请注意，此设置仅适用于顶级镜像；backingStore的format元素的同名子元素可用于指定备份镜像的缓存设置。

​ 自7.0.0版开始，可以通过max_size子元素来控制qemu虚拟机的qcow2格式驱动程序的元数据缓存的max_size(请参见下面的示例)。

​ 可选的discard_no_unref属性可以设置为控制qemu hypervisor如何处理qcow2镜像中的客户机丢弃命令。启用后，来自客户机的丢弃请求将将qcow2群集标记为零，但将保留该群集的引用/偏移量。但它仍然会将丢弃传递到较低的层。这将解决qcow2镜像中的碎片问题。自9.5.0版(QEMU 8.1)。

​ 在大多数情况下，hypervisor使用的默认配置足够了，因此不需要修改此设置。有关qemu虚拟机中qcow2元数据缓存行为的具体信息，请参阅qemu qcow2 cache docs。

​ Example:

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2'>
    <metadata_cache>
      <max_size unit='bytes'>1234max_size>
    metadata_cache>
  driver>
  <source file='/var/lib/libvirt/images/domain.qcow'/>
  <backingStore type='file'>
    <format type='qcow2'>
      <metadata_cache>
        <max_size unit='bytes'>1234max_size>
      metadata_cache>
    format>
    <source file='/var/lib/libvirt/images/snapshot.qcow'/>
    <backingStore/>
  backingStore>
  <target dev='vdd' bus='virtio'/>
disk>

backenddomain

​ 可选的backenddomain元素允许指定承载磁盘的后端域(也称为驱动程序域)。使用name属性可以指定后端域名。自1.2.13起(仅限Xen)

boot

​ 指定磁盘是可引导的。order属性确定在引导序列中尝试设备的顺序。在S390体系结构上，仅使用第一个引导设备。可选的loadparm属性是一个8个字符的字符串，guest可以在S390上通过sclp或diag 308查询该字符串。S390上的Linux客户机可以使用loadparm来选择boot entry。自3.5.0在BIOS引导加载程序部分，每个设备的boot元素不能与通用引导元素一起使用 BIOS bootloader。自0.8.8

encryption

​ 从libvirt 3.9.0开始，首选将encryption元素作为source元素的子元素。如果存在，它指定如何使用"qcow"加密卷。有关更多信息，请参阅Storage Encryption。

readonly

​ 如果存在，表示设备不能由客户机修改。目前，对于具有属性device='cdrom'的磁盘，这是默认设置。

shareable

​ 如果存在，表示设备预计在域之间共享(假设hypervisor和操作系统支持此功能)，这意味着该设备的缓存应该被停用。

transient

​ 如果存在，表示应在客户机退出时自动还原对设备内容的更改。对于某些hypervisor，将磁盘标记为transient可以阻止该域参与迁移、快照或块作业。仅支持vmx hypervisor(自0.9.5)和qemu hypervisor(自6.9.0)。

​ 在源映像的磁盘被假定为在多个同时运行的VM之间共享的情况下，可选的shareBacking属性应设置为是。请注意，hypervisor驱动程序可能需要热插拔此磁盘，因此仅适用于支持热插拔的配置。自7.4.0版开始。

serial

​ 如果存在，指定虚拟硬盘的序列号。例如，它可能看起来像WD-WMAP9A966149。不支持scsi-block设备，即那些使用磁盘类型’block’，使用device’lun’在bus 'scsi’上的设备。自0.7.1。

​ 请注意，根据hypervisor和设备类型，序列号可能会被默默截断。IDE/SATA设备通常限制为20个字符。根据hypervisor版本的不同，SCSI设备可能限制为20、36或247个字符。

​ 将来，hypervisor可能开始拒绝过长的序列号，而不是截断它们，因此建议通过测试所需的设备和hypervisor组合的所需序列号长度范围来避免隐式截断。

wwn

​ 如果存在，此元素指定虚拟硬盘或CD-ROM驱动器的WWN(World Wide Name, 全局唯一名称)。它必须由16个十六进制数字组成。自0.10.1。

vendor

​ 如果存在，此元素指定虚拟硬盘或CD-ROM设备的制造商。其长度不能超过8个可打印字符。自1.0.1。

product

​ 如果存在，此元素指定虚拟硬盘或CD-ROM设备的产品。其长度不能超过16个可打印字符。自1.0.1。

address

​ 如果存在，address元素将磁盘绑定到控制器的特定插槽(通常可以由libvirt推断实际的设备，尽管可以明确指定)。type属性是强制性的，通常为"pci"或"drive"。对于"pci"控制器，必须存在额外的属性bus、slot和function，以及可选的domain和multifunction。multifunction默认为’off’；任何其他值都需要QEMU 0.1.3和libvirt 0.9.7。对于"drive"控制器，可以使用额外的属性controller、bus、target(libvirt 0.9.11)和unit，每个属性默认为0。

auth

​ 从libvirt 3.9.0开始，首选将auth元素作为source元素的子元素。该元素仍然被视为磁盘的子元素并进行管理。将auth同时用作disk和source的子元素是无效的。auth元素在libvirt 0.9.7中作为磁盘的子元素引入。

geometry

​ 可选的geometry元素提供了替代几何图元设置的功能。这对于S390 DASD磁盘或较旧的DOS磁盘非常有用。0.10.0

​ cyls

​ cyls属性是圆柱体cylinders的数量。

​ heads

​ heads属性是头的数量。

​ secs

​ secs属性是每个磁道的扇区数。

​ trans

​ 可选trans属性是BIOS Translation Modus(none， lba 或 auto)

blockio

​ 如果存在，blockio元素允许覆盖下面列出的任何块设备属性。自0.10.2(QEMU和KVM)

​ logical_block_size

​ 磁盘将向guest OS报告的逻辑块大小。对于Linux，这将是BLKSSZGET ioctl返回的值，并描述磁盘I/O的最小单元。

​ physical_block_size

​ 磁盘将向guest OS报告的物理块大小。对于Linux，这将是BLKPBSZGET ioctl返回的值，并描述磁盘的硬件扇区大小，该大小可能与磁盘数据的对齐有关。

​ discard_gramularity

​ 在单个操作中可以丢弃的最小数据量。它会影响取消映射操作，并且它必须是logical_block_size的倍数。这通常由hypervisor正确配置。

1.20.2 (Filesystems)

...
<devices>
  <filesystem type='template'>
    <source name='my-vm-template'/>
    <target dir='/'/>
  filesystem>
  <filesystem type='mount' accessmode='passthrough' multidevs='remap'>
    <driver type='path' wrpolicy='immediate'/>
    <source dir='/export/to/guest'/>
    <target dir='/import/from/host'/>
    <readonly/>
  filesystem>
  <filesystem type='mount' accessmode='mapped' fmode='644' dmode='755'>
    <driver type='path'/>
    <source dir='/export/to/guest'/>
    <target dir='/import/from/host'/>
    <readonly/>
  filesystem>
  <filesystem type='file' accessmode='passthrough'>
    <driver type='loop' format='raw'/>
    <source file='/export/to/guest.img'/>
    <target dir='/import/from/host'/>
    <readonly/>
  filesystem>
  <filesystem type='mount' accessmode='passthrough'>
      <driver type='virtiofs' queue='1024'/>
      <binary path='/usr/libexec/virtiofsd' xattr='on'>
         <cache mode='always'/>
         <sandbox mode='namespace'/>
         <lock posix='on' flock='on'/>
         <thread_pool size='16'/>
      binary>
      <source dir='/path'/>
      <target dir='mount_tag'/>
  filesystem>
  <filesystem type='mount'>
      <driver type='virtiofs' queue='1024'/>
      <source socket='/tmp/sock'/>
      <target dir='tag'/>
  filesystem>
  ...
devices>
...

filesystem

​ filesystem属性type指定source的类型。可能的值包括：

​ mount

​ 在客户机中挂载的主机目录。用于LXC、OpenVZ(自0.6.2起)和QEMU/KVM(自0.8.5起)。如果未指定类型，则默认为此类型。此模式还具有一个可选的子元素driver，带有属性type='path'或type='handle'(自0.9.7起)。driver块具有可选的wrpolicy属性，用于进一步控制与主机页面缓存的交互；省略属性会给出默认行为，而值immediate表示在客户机文件写操作期间触发所有受影响页面的主机回写(自0.9.10起)。自6.2.0起，也支持type='virtiofs'。使用virtiofs需要设置共享内存，参见指南：Virtiofs

​ template

​ OpenVZ文件系统模板。仅由OpenVZ驱动程序使用。

​ file

​ 主机文件将被视为镜像并挂载到客户机中。将自动检测文件系统格式。仅由LXC驱动程序使用。

​ block

​ 要在客户机中挂载的主机块设备。将自动检测文件系统格式。仅由LXC驱动程序使用(自0.9.5起)。

​ ram

​ 使用来自主机操作系统的内存的内存文件系统。源元素具有一个名为usage的属性，该属性指定以KiB为单位的内存使用限制，除非通过units属性指定单位。仅由LXC驱动程序使用(自0.9.13起)。

​ bind

​ 客户机内的一个目录将绑定到客户机内的另一个目录。仅由LXC驱动程序使用(自0.9.13起)。

​ filesystem

​ 元素具有一个可选的accessmode属性，该属性指定访问源的安全模式(自0.8.5起)。目前，这仅在QEMU/KVM驱动程序的type='mount'模式下工作。对于驱动程序类型virtiofs，仅支持passthrough。对于其他驱动程序类型，可能的值包括：

​ passthrough

​ 以客户机内的用户权限访问源。如果未指定，这是accessmode默认值。More info

​ mapped

​ 以hypervisor(QEMU进程)的权限访问source。More info

​ squash

​ 类似于’passthrough’，不同之处在于忽略特权操作(如’chown’)的失败。这使得类似于passthrough的模式可供将hypervisor作为非root用户运行的人使用。More info

自5.2.0版以来，filesystem元素具有一个可选的model属性，支持的值为"virtio-transitional"、“virtio-non-transitional"或"virtio”。有关更多详细信息，请参见1.20.5Virtio transitional devices

filesystem元素具有可选的fmode和dmode属性。这两个属性控制在accessmode的mapped值(自6.10.0起，需要QEMU 2.10)下用于文件和目录的创建模式。如果未指定，QEMU将使用模式600创建文件，使用模式700创建目录。不支持setuid、setgid和粘性位。

filesystem元素具有一个可选的multidevs属性，用于指定如何处理包含多个设备的文件系统导出，以避免在使用9pfs时在客户机上出现文件ID冲突(自6.3.0起，需要QEMU 4.2)。此属性不适用于virtiofs。可能的值包括：

​ default

​ 使用QEMU的默认设置(当前为警告)。

​ remap

​ 此设置允许客户机访问一个导出中的多个设备，而不会发生行为不当。来自主机的inode编号会自动重新映射到客户机上，以主动防止如果客户机访问包含多个设备的导出时出现文件ID冲突。

​ forbid

​ 只允许客户机访问导出中的一个设备。尝试访问同一导出中的其他设备将导致客户机上的个别文件系统访问失败，并在主机上记录错误(一次)。

​ warn

​ 此设置类似于QEMU 4.2之前的9pfs行为，即不会执行任何操作来防止导出包含多个设备时的潜在文件ID冲突，唯一的例外是：现在在主机上记录了警告(一次)。如果一个导出中导出了多个设备，这可能会导致客户机一侧的不当行为，因为这可能会导致客户机一侧的文件ID冲突。

driver

​ 可选的driver元素允许指定与提供文件系统的hypervisor驱动程序相关的进一步细节(自1.0.6起)。

​ 如果hypervisor支持多个后端驱动程序，则type属性选择主要后端驱动程序名称，而format属性提供格式类型。例如，LXC支持"type"为"loop"，格式为"raw"或"nbd"(可以使用任何格式)。QEMU支持"type"为"path"或"handle"，但不支持格式。Virtuozzo驱动程序支持"type"为"ploop"，格式为"ploop"。

​ 对于支持virtio的设备，还可以设置Virtio-related options(自3.5.0起)。

​ 对于virtiofs，可以使用queue属性指定队列大小(即队列可以容纳多少请求)(自6.2.0起)。

binary

​ 可选的binary元素可以调整virtiofsd的选项。以下所有属性和元素都是可选的。属性path可用于覆盖守护程序的路径。属性xattr启用了文件系统扩展属性的使用。缓存可以通过cache元素进行调整，可能的模式值为none和always。锁定可以通过lock元素进行控制 - 属性posix和flock都接受on或off的值(自6.2.0起)。virtiofsd使用的沙箱方法可以通过sandbox元素进行配置，可能的模式值为namespace和chroot，请参阅 virtiofsd documentation 以获取更多详细信息(自7.2.0起)。元素thread_pool接受一个名为size的属性，该属性定义了最大线程池大小。值"0"禁用了线程池。线程池有助于在与具有较高延迟的存储一起使用时增加在运行中的请求数量。但是，它会增加开销，因此对于快速、低延迟的文件系统，最好关闭它(自8.5.0起)。

source

​ 在主机上正在访问的客户机中的资源。必须在type='template'的情况下使用name属性，并且在type='mount'的情况下使用dir属性。对于virtiofs，可以使用socket属性连接到在libvirt之外启动的virtiofsd守护程序。在这种情况下，target元素不适用，大多数与virtiofs相关的选项也不适用，因为它们由virtiofsd而不是libvirtd控制。使用type='ram'时，使用usage属性设置以KiB为单位的内存限制，除非通过units属性指定单位。

target

​ 在客户机中可以访问source的位置。对于大多数驱动程序，这是一个自动挂载点，但对于QEMU/KVM来说，这只是一个导出到客户机的任意字符串标记，用作提示在客户机上挂载的位置。

readonly

​ 启用将文件系统导出为只读挂载，如果未指定，默认为读写访问(目前仅适用于QEMU/KVM驱动程序)。

space_hard_limit

​ 该客户机文件系统的最大可用空间(自0.9.13起)。

space_soft_limit

​ 该客户机文件系统的最大可用空间。容器被允许在柔性限制期间超出其限制一段时间。之后，强制执行硬性限制(自0.9.13起)。

1.20.3 (Device Addresses)

许多设备都有一个可选的

子元素来描述设备在呈现给客户的虚拟总线上的位置。如果在输入时省略了一个地址(或地址中的任何可选属性)，libvirt将生成一个适当的地址；但是如果需要对布局进行更多控制，则需要显式地址。有关包括地址元素的设备示例，请参见下文。

​ 每个地址都有一个强制性的属性type，用于描述设备所在的总线。为给定设备选择哪个地址在一定程度上受到设备和guest体系结构的限制。例如，设备使用type='drive'，而设备在i686或x86_64guest上使用type='ci'，或在PowerPC64 pseriesguest上使用type='papr-vio'。每种地址类型都有其他可选属性，用于控制设备在总线上的位置：

​ pci

​ PCI地址具有以下附加属性：domain(2字节的十六进制整数，qemu当前未使用)、bus(0到0xff之间的十六进制值，包括0和0xff)、slot插槽(0x0到0x1f之间的十六进位值，包括0x0和0x1f)和function(0到7之间的值，包括7)。multifunction属性也可用，它控制开启PCI控制寄存器中特定插槽/功能的多功能位(自0.9.7，需要QEMU 0.13)。multifunction默认为“off”，但对于将使用多个功能的插槽的功能0，应设置为“打开”。(自4.10.0起)，支持PCI地址扩展，具体取决于体系结构。例如，S390guest的PCI地址将有一个zpci子元素，具有两个属性：uid(介于0x0001和0xffff之间的十六进制值，包括)和fid(介于0x00000000和0xffffff之间，包括)，供S390上的PCI设备用于用户定义标识符和功能标识符。自1.3.5，一些hypervisor驱动程序可能会接受一个没有其他属性的

元素作为为设备分配pci地址的显式请求，而不是可能适用于同一设备的其他类型的地址(例如virtio mmio)。域XML中配置的PCI地址与guest OS看到的PCI地址之间的关系有时可能会令人困惑：单独的文档更详细地描述了how PCI addresses work。

​ drive

​ 驱动器地址具有 controller(控制器编号)、bus(总线编号)、target(目标编号) 和 unit(单元编号)等属性。这些属性用于指定虚拟机中的驱动器地址。

​ virtio-serial

​ Virtio-Serial 设备地址具有 controller(控制器编号)、bus(总线编号)和 slot(槽编号)等属性。这用于虚拟机中的 Virtio-Serial 设备。

​ ccid(智能卡)

​ CCID 设备地址用于智能卡设备，具有 bus(总线编号)和 slot(槽编号)等属性。

​ usb

​ USB 设备地址具有 bus(总线编号)和 port(端口编号)等属性，用于表示虚拟机中的 USB 设备。

​ spapr-vio

​ 对于 PowerPC pseries 虚拟机，设备可以分配到 SPAPR-VIO 总线。它具有一个平面的 32 位地址空间，通常按照 0x00001000 的非零倍数分配地址，但也可以使用其他地址。每个地址具有 reg(起始寄存器地址的十六进制值)属性。

​ ccw

​ S390 虚拟机(使用 s390-ccw-virtio 机器类型)使用本机 CCW 总线进行 I/O 设备。CCW 总线地址具有 cssid(十六进制值，范围在 0 到 0xfe 之间)、ssid(值在 0 到 3 之间)和 devno(十六进制值，范围在 0 到 0xffff 之间)等属性。

​ virtio-mmio

​ 这将设备放置在 virtio-MMIO 传输上，目前仅适用于某些 armv7l 和 aarch64 虚拟机。Virtio-MMIO 地址没有任何附加属性。

​ isa

​ ISA 地址具有 iobase 和 irq 等属性。

​ unassigned

​ 对于 PCI 主机设备，

允许管理员在域 XML 定义中包含 PCI 主机设备，而无需让虚拟机访问它。这允许Libvirt将设备作为常规PCI hostdev进行管理的配置，而不管guest是否有权访问它。

对于所有其他设备类型都是无效的地址类型。自6.0.0

1.20.4 (Virtio-related options)

QEMU的virtio设备在driver元素下有一些与virtio传输相关的属性：iommu属性允许设备使用模拟iommu。属性ats控制PCIe设备的地址转换服务支持。这是利用IOTLB支持所必需的(请参阅1.20.27 IOMMU devices)。可能的值为on或off。自3.5.0起

属性packed控制QEMU是否应该尝试使用压缩virtqueues。与常规的拆分(spilt)队列相比，压缩(packed)队列仅由一个描述符环组成，用于替换可用和已用的环、索引和描述符缓冲区。这样可以提高缓存利用率和性能。是否实际使用压缩的virtqueues取决于QEMU、vhost后端和guest驱动程序之间的feature negotiation。可能的值为on或off。自6.3.0(仅限QEMU和KVM)

此可选属性page_per_vq控制向guest公开的通知功能的布局。启用后，每个virtio队列将在设备BAR上有一个专用页面，向guest公开。建议在hypervisor上启用vDPA时使用它，因为它可以将通知区域映射到物理设备，这仅在页面粒度中受支持。默认值由QEMU确定。7.9.0起(QEMU 2.8)注意：一般来说，你应该不考虑这个选项，除非你非常确定你知道自己在做什么。

1.20.5 (Virtio transitional devices)

从5.2.0开始，QEMU的一些virtio设备在与PCI/PCIe机器类型一起使用时，接受以下mode值：

​ virtio-transitional

​ 这个模型选项允许设备同时与virtio 0.9和virtio 1.0的客户端驱动程序一起工作。因此，它是在需要与较旧的guest OS兼容性的情况下的最佳选择。Libvirt会将设备连接到传统的PCI插槽。

​ virtio-non-transitional

​ 这个模型选项只能与virtio 1.0的客户端驱动程序一起工作，除非需要与较旧的guest OS兼容性，否则建议使用此选项。根据机器类型，Libvirt会将设备连接到PCI Express插槽或传统的PCI插槽，从而实现更优化的PCI拓扑结构。

​ virtio

​ 这个模型选项在连接到PCI Express插槽时的行为类似于virtio-non-transitional设备，在连接到其他插槽时的行为类似于virtio-transitional设备。Libvirt会根据机器类型选择其中一个模型。这是在需要与早于5.2.0版本的Libvirt兼容性的情况下的最佳选择，但一般情况下不建议使用它。

需要注意的是，虽然大多数virtio设备都适用于上述模型选项，但也有一些例外情况：

• 对于SCSI控制器，由于历史原因，没有virtio模型可用。相反，应该使用virtio-scsi，它对于其他设备与virtio的行为相同。virtio-transitional和virtio-non-transitional都适用于SCSI控制器。
• 一些设备，如GPU和输入设备(键盘、平板电脑和鼠标)，仅在virtio 1.0规范中定义，因此没有过渡变体。唯一接受的模型是virtio，这将导致非过渡设备。

更多信息查阅：qemu patch posting 和virtio-1.0 spec.

1.20.6 (Controllers)

根据guest体系结构的不同，一些设备总线可能会出现不止一次，其中一组虚拟设备连接到一个虚拟控制器。通常，libvirt可以在不需要显式XML标记的情况下自动推断此类控制器，但有时有必要提供显式控制器元素，尤其是在为预期设备热插拔的guest规划 PCI topology 。

...
<devices>
  <controller type='ide' index='0'/>
  <controller type='virtio-serial' index='0' ports='16' vectors='4'/>
  <controller type='virtio-serial' index='1'>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
  controller>
  <controller type='scsi' index='0' model='virtio-scsi'>
    <driver iothread='4'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
  controller>
  <controller type='xenbus' maxGrantFrames='64' maxEventChannels='2047'/>
  ...
devices>
...

每个控制器都有一个必需的type属性，该属性必须是以下之一：‘ide’、‘fdc’、‘scsi’、‘sata’、‘usb’、‘ccid’、‘virtio-serial’ 或 ‘pci’，以及一个必需的index属性，该属性是描述总线控制器在哪个顺序中遇到的十进制整数(用于

元素的controller属性)。自1.3.5以来，索引是可选的；如果未指定，将自动分配为给定控制器类型的未使用的最低索引。某些控制器类型具有控制特定功能的附加属性，例如：

​ virtio-serial

​ virtio-serial控制器具有两个附加的可选属性ports和vectors，用于控制可以通过该控制器连接多少设备。自5.2.0起，它支持一个可选的属性模型，可以是’virtio’、‘virtio-transitional’ 或 ‘virtio-non-transitional’。有关更多详细信息，请参阅 1.20.5 Virtio transitional devices。

​ scsi

​ scsi控制器具有一个可选的属性model，它是以下之一：‘auto’、‘buslogic’、‘ibmvscsi’、‘lsilogic’、‘lsisas1068’、‘lsisas1078’、‘virtio-scsi’、‘vmpvscsi’、‘virtio-transitional’、‘virtio-non-transitional’、‘ncr53c90’(仅作为内置隐式控制器)、‘am53c974’、‘dc390’。有关更多详细信息，请参阅1.20.5 Virtio transitional devices。

​ usb'auto'、'buslogic'、'ibmvscsi'、'lsilogic'、'lsisas1068'、'lsisas1078'、'virtio

​ usb控制器具有一个可选的属性模型，它是以下之一：“piix3-uhci”、“piix4-uhci”、“ehci”、“ich9-ehci1”、“ich9-uhci1”、“ich9-uhci2”、“ich9-uhci3”、“vt82c686b-uhci”、“pci-ohci”、“nec-xhci”、“qusb1”(xen pvusb，带有qemu后端，版本1.1) 、“qusb2”(xen pvusb，带有qemu后端，版本2.0)或 “qemu-xhci”。此外，自0.10.0起，如果需要明确禁用客户机的USB总线，可以使用model='none'。自1.0.5起，s390上不会构建默认的USB控制器。自1.3.5起，USB控制器接受一个ports属性，用于配置可以连接到控制器的设备数量。

​ ide

​ 自3.10.0起，对于vbox驱动程序，IDE控制器具有一个可选的属性model，它是 “piix3”、“piix4” 或 “ich6” 中的一个。

​ xenbus

​ 自5.2.0起，xenbus控制器具有一个可选的属性maxGrantFrames，该属性指定控制器为连接的设备提供的最大授权帧数量。自6.3.0起，xenbus控制器支持可选的maxEventChannels属性，该属性指定客户机可以使用的事件通道(PV中断)的最大数量。

注意：PowerPC64“spapr vio”地址没有关联的控制器。

对于本身是PCI或USB总线上设备的控制器，可选子元素

可以指定控制器与其主总线的确切关系，其语义在设备地址部分中描述。

可选的子元素driver可以指定特定于驱动程序的选项：

​ queues

​ 可选的queues属性指定控制器的队列数量。为了获得最佳性能，建议指定与虚拟CPU数量匹配的值。自1.0.5起(仅适用于QEMU和KVM)。

​ cmd_per_lun

​ 可选的cmd_per_lun属性指定主机控制的设备上可以排队的最大命令数。自1.2.7起(仅适用于QEMU和KVM)。

​ max_sectors

​ 可选的max_sectors属性指定在单个命令中传输到设备或从设备传输的最大数据量(以字节为单位)。传输长度以扇区为单位，其中一个扇区为512字节。自1.2.7起(仅适用于QEMU和KVM)。

​ ioeventfd

​ 可选的ioeventfd属性指定控制器是否应使用I/O异步处理。接受的值为"on"和"off"。自1.2.18起。

​ iothread

​ 对于控制器类型为scsi且使用模型virtio-scsi的地址类型为pci和ccw的情况，自1.3.5版本(QEMU 2.4)以来支持。可选的iothread属性将控制器分配给由域iothreads(请参阅 1.5 IOThreads Allocation)定义的IOThread范围。分配为使用指定控制器的每个SCSI磁盘都将利用相同的IOThread。如果希望为特定的SCSI磁盘指定特定的IOThread，则必须定义多个控制器，每个控制器都具有特定的iothread值。iothread值必须在1到域iothreads值的范围内。

​ virtio options

​ 对于virtio控制器，可以设置1.20.4 Virtio-related options。自3.5.0起

USB配套控制器有一个可选的子元素，用于指定配套控制器与其主控制器的确切关系。伴随控制器与其主控制器在同一总线上，因此伴随index值应该相等。并不是所有的控制器模型都可以用作配套控制器，libvirt可能会为一些特定的模型提供一些合理的默认值(master startport主启动端口的设置和地址的function)。首选的配套控制器是ich uhci[123]。

...
<devices>
  <controller type='usb' index='0' model='ich9-ehci1'>
    <address type='pci' domain='0' bus='0' slot='4' function='7'/>
  controller>
  <controller type='usb' index='0' model='ich9-uhci1'>
    <master startport='0'/>
    <address type='pci' domain='0' bus='0' slot='4' function='0' multifunction='on'/>
  controller>
  ...
devices>
...

PCI控制器具有可选的model属性；该属性的可能值为

• pci-root， pci-bridge ( since 1.0.5 )
• pcie-root， dmi-to-pci-bridge ( since 1.1.2 )
• pcie-root-port， pcie-switch-upstream-port， pcie-switch-downstream-port ( since 1.2.19 )
• pci-expander-bus， pcie-expander-bus ( since 1.3.4 )
• pcie-to-pci-bridge ( since 4.3.0 )

根控制器(pci-root和pcie-root)有一个可选的pcihole64元素，用于指定64位pci漏洞的大小(以千字节为单位，或以pcihole64的unit属性指定的单位为单位)。当QEMU和Seabios足够新，可以支持64位PCI holes时，一些guest(如WindowsXP或WindowsServer2003)可能会崩溃，除非禁用(设置为0)。自1.1.2起(仅限QEMU)

PCI控制器还有一个可选的子元素，该子元素具有属性name。name属性包含qemu正在模拟的特定设备的名称(例如“i82801b11桥”)，而不是简单的设备类别(“pcie到pci桥”、“pci桥”)(在控制器元素的模型属性中设置)。在几乎所有情况下，都不应该手动向控制器添加子元素，也不应该修改libvirt自动生成的子元素。自1.2.19起(仅限QEMU)。

PCI控制器还有一个可选的子元素，其属性和子元素如下所示。这些是可配置项，1)对客户操作系统可见，因此必须保留以与客户ABI兼容，2)通常保留为默认值或由libvirt自动派生。在几乎所有情况下，都不应该手动将子元素添加到控制器中，也不应该修改libvirt自动生成的值中的值。自1.2.19起(仅限QEMU)。

​ chassisNr

​ 对于具有属性model="pci-bridge"的PCI控制器，还可以在子元素中具有chassisNr属性，该属性用于控制QEMU的"chassis_nr"选项，用于pci-bridge设备(通常情况下，libvirt会自动将其设置为与pci控制器的index属性相同的值)。如果设置了chassisNr，必须在1到255之间。

​ chassis

​ pcie-root-port和pcie-switch-downstream-port控制器也可以在子元素中具有chassis属性，该属性用于设置控制器的"chassis"配置值，该值对虚拟机可见。如果设置了chassis，必须在0到255之间。

​ port

​ pcie-root-port和pcie-switch-downstream-port控制器还可以在子元素中具有port属性，该属性用于设置控制器的"port"配置值，该值对虚拟机可见。如果设置了port，必须在0到255之间。

​ hotplug

​ pci-root(自7.9.0)、pcie-root-port(自6.3.0)和pcie-switch-downstream-port控制器(自6.3.0)也可以在子元素中具有hotplug属性，该属性用于禁用特定控制器上设备的热插拔。对于pci-root控制器，该设置会影响基于ACPI的热插拔。对于其余控制器，该设置既影响基于ACPI的热插拔，也影响PCIE本地热插拔。hotplug的默认设置为on；要禁用特定控制器上设备的热插拔，应将其设置为off。

​ busNr

​ pci-expander-bus和pcie-expander-bus控制器可以具有可选的busNr属性(1-254)。这将是新总线的总线号；在指定的总线号和255之间的所有总线号只能分配给插入到从此扩展总线开始的层次结构的PCI/PCIe控制器，而小于指定值的总线号将分配给下一个较低的扩展总线(如果没有较低的扩展总线，则为根总线)。如果不指定busNumber，libvirt将查找所有其他扩展总线中的最低总线号(如果没有其他总线，则使用256)，并自动分配找到的总线的busNr值 - 2，这为pci-expander-bus提供了一个总线号，以及为其自动附加的pci-bridge提供了一个总线号(如果 计划添加更多的pci-bridge到总线的层次结构中， 应该手动将busNr设置为较低的值)。

​ 用于自动确定pcie-expander-bus的busNr属性的算法类似，但由于pcie-expander-bus没有任何内置的pci-bridge，因此第二个总线号只是为必须连接到总线中以实际插入端点设备的pcie-root-port保留的总线号。如果打算将多个设备插入pcie-expander-bus中，必须将pcie-switch-upstream-port连接到插入到pcie-expander-bus中的pcie-root-port，并将多个pcie-switch-downstream-port连接到pcie-switch-upstream-port，当然，为了使这正常工作， 需要相应地减小pcie-expander-bus的busNr，以便在其上方有足够的未使用的总线号以容纳为上游端口提供一个总线号以及为每个下游端口提供一个总线号(除了pcie-root-port和pcie-expander-bus本身)。

​ node

​ 一些PCI控制器(用于pc机器类型的pci-expander-bus，用于q35机器类型的pci-expander-bus，以及自3.6.0以来用于pseries机器类型的PCI根)可以在子元素中具有可选的子元素，用于设置向该总线的guest OS报告的NUMA节点-然后guest OS将知道该总线上的所有设备都是指定NUMA节点的一部分(在将主机设备分配给域时，由libvirt API的用户将主机设备连接到正确的pci-expander-总线)。

​ index

​ pSeries客户的pci根控制器使用此属性来记录它们在客户机中的显示顺序。自3.6.0起

​ 对于提供隐式PCI总线的机器类型，索引为0的PCI根控制器是自动添加的，并且需要使用PCI设备。pci根没有地址。如果PCI根提供的一条总线上有太多设备无法容纳，或者指定了大于零的PCI总线号，则会自动添加PCI桥。PCI桥也可以手动指定，但它们的地址应该仅指由已经指定的PCI控制器提供的PCI总线。在PCI控制器索引中留下间隙可能会导致配置无效。

...
<devices>
  <controller type='pci' index='0' model='pci-root'/>
  <controller type='pci' index='1' model='pci-bridge'>
    <address type='pci' domain='0' bus='0' slot='5' function='0' multifunction='off'/>
  controller>
devices>
...

​ 对于提供隐式PCI Express(PCIe)总线的机器类型(例如，基于Q35芯片组的机器类型)，会自动将具有index=0的pcie-root控制器添加到域的配置中。pcie-root也没有地址，提供31个插槽(编号为1-31)，可用于连接PCIe或PCI设备(尽管libvirt不会自动将PCI设备分配给PCIe插槽，但允许手动指定此类分配)。连接到pcie-root的设备无法热插拔。如果在客户配置中存在传统PCI设备，将自动添加一个pcie-to-pci-bridge控制器：该控制器插入到pcie-root-port中，提供31个可用的PCI插槽(1-31)，支持热插拔(自4.3.0以来)。如果QEMU二进制文件不支持相应的设备，则将添加一个dmi-to-pci-bridge控制器，通常位于slot=0x1e的事实标准位置。dmi-to-pci-bridge控制器插入到PCIe插槽中(由pcie-root提供)，并自身提供31个标准PCI插槽(也不支持设备热插拔)。为了在客户机系统中具有可热插拔的PCI插槽，还将自动创建并连接到自动创建的dmi-to-pci-bridge控制器的插槽之一的pci-bridge控制器；libvirt自动确定的所有客户PCI设备的地址都将放在此pci-bridge设备上(自1.1.2以来)。

​ 具有隐式pcie-root的域还可以添加具有model='pcie-root-port'、model='pcie-switch-upstream-port'和model='pcie-switch-downstream-port'的控制器。pcie-root-port是一种简单类型的桥接设备，只能在其上游侧连接到pcie-root总线的31个插槽之一，并在下游侧提供一个(PCIe、可热插拔)端口(在slot='0’处)。pcie-root-port可用于提供一个插槽以后热插拔PCIe设备(但本身不可热插拔-必须在启动域时包含在配置中)(自1.2.19以来)。

​ pcie-switch-upstream-port是一种更灵活(但也更复杂)的设备，只能在其上游侧插入到pcie-root-port或pcie-switch-downstream-port中(并且只能在启动域之前插入-不可热插拔)，并在下游侧提供32个端口(slot=‘0’ - slot=‘31’)，只接受pcie-switch-downstream-port设备；每个pcie-switch-downstream-port设备只能在其上游侧插入到pcie-switch-upstream-port中(同样不可热插拔)，在其下游侧提供一个可热插拔的pcie端口，可以接受任何标准的PCI或PCIe设备(或另一个pcie-switch-upstream-port)，即与pcie-root-port的功能相同(自1.2.19以来)。

...
<devices>
  <controller type='pci' index='0' model='pcie-root'/>
  <controller type='pci' index='1' model='pcie-root-port'>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
  controller>
  <controller type='pci' index='2' model='pcie-to-pci-bridge'>
    <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
  controller>
devices>
...

1.20.7 (Device leases)

当使用锁管理器时，可能需要记录针对VM的设备租赁。锁管理器将确保VM不会启动，除非可以获得租约。

...
<devices>
  ...
  <lease>
    <lockspace>somearealockspace>
    <key>somekeykey>
    <target path='/some/lease/path' offset='1024'/>
  lease>
  ...
devices>
...

​ lockspace

​ 这是一个任意的字符串，用于标识密钥所在的锁空间。锁管理器可能会对锁空间名称的格式或长度施加额外的限制。

​ key

​ 这是一个任意字符串，唯一标识要获取的租约。锁管理员可能会对密钥的格式或长度施加额外的限制。

​ target

​ 这是与锁空间关联的文件的完全限定路径。偏移量指定租约在文件中的存储位置。如果锁管理器不需要偏移量，只需传递0即可。

1.20.8 (Host device assignment)

1.20.8.1 USB / PCI / SCSI devices

连接到主机的USB、PCI和SCSI设备可以使用hostdev元素传递给客户。在USB 0.4.4、PCI 0.6.0(仅限KVM)和SCSI 1.0.6(仅限KVM)之后：

...
<devices>
  <hostdev mode='subsystem' type='usb'>
    <source startupPolicy='optional' guestReset='off'>
      <vendor id='0x1234'/>
      <product id='0xbeef'/>
    source>
    <boot order='2'/>
  hostdev>
devices>
...

...
<devices>
  <hostdev mode='subsystem' type='pci' managed='yes'>
    <source writeFiltering='no'>
      <address domain='0x0000' bus='0x06' slot='0x02' function='0x0'/>
    source>
    <boot order='1'/>
    <rom bar='on' file='/etc/fake/boot.bin'/>
  hostdev>
devices>
...

...
<devices>
  <hostdev mode='subsystem' type='scsi'>
    <source protocol='iscsi' name='iqn.2014-08.com.example:iscsi-nopool/1'>
      <host name='example.com' port='3260'/>
      <auth username='myuser'>
        <secret type='iscsi' usage='libvirtiscsi'/>
      auth>
      <initiator>
        <iqn name='iqn.2020-07.com.example:test'/>
      initiator>
    source>
    <address type='drive' controller='0' bus='0' target='0' unit='0'/>
  hostdev>
devices>
...

...
<devices>
  <hostdev mode='subsystem' type='mdev' model='vfio-pci'>
  <source>
    <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'/>
  source>
  hostdev>
  <hostdev mode='subsystem' type='mdev' model='vfio-ccw'>
  <source>
    <address uuid='9063cba3-ecef-47b6-abcf-3fef4fdcad85'/>
  source>
  <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
  hostdev>
devices>
...

hostdev

​ hostdev元素是用于描述主机设备的主要容器。对于每个设备，model始终为“subsystem”，type为以下值之一，并注明其他属性。

​ usb

​ USB设备在虚拟机启动时会从主机中分离，而在虚拟机退出或设备热拔插时会重新连接到主机。

​ pci

​ 对于PCI设备，当managed属性设置为“yes”时，设备在传递给虚拟机之前会从主机中分离，并在虚拟机退出后重新连接到主机。如果managed被省略或设置为“no”，则用户需要使用适当的virsh命令来分离和重新连接设备。

​ scsi

​ 对于SCSI设备，用户需要确保主机不在使用该设备。可选的sgio属性(自1.0.6起)指示是否对磁盘过滤未授权的SG_IO命令。有效设置为“filtered”或“unfiltered”，默认为“filtered”。可选的rawio属性(自1.2.9起)指示LUN是否需要rawio功能，有效设置为“yes”或“no”。请参阅1.20.1 Hard drives， floppy disks， CDROMs 部分中的rawio说明。如果域中的磁盘lun已经具有rawio功能，则不需要此设置。

​ scsi_host

​ (自2.5.0起): 对于SCSI设备，用户需要确保主机不在使用该设备。这种类型将由单个HBA呈现的所有LUN传递给虚拟机。从版本5.2.0开始，可以将model属性指定为“virtio-transitional”，“virtio-non-transitional”或“virtio”以用于Virtio过渡设备。

​ mdev

​ (自3.2.0起): 对于中介设备，model属性指定了确定主机的vfio驱动程序如何将设备暴露给虚拟机的设备API。支持的值包括“vfio-pci”，“vfio-ccw”(自4.4.0起)和“vfio-ap”(自4.9.0起)。display属性(自4.6.0起)可用于启用或禁用由中介设备支持的加速远程桌面，例如NVIDIA vGPU或Intel GVT-g，其值可以为“on”或“off”(默认为“off”)。从版本5.10.0开始，对于model='vfio-pci'的设备，还可以使用可选的ramfb属性，以为虚拟机提供内存帧缓冲设备。

​ 注意：managed属性仅与type='pci'一起使用，并且被所有其他设备类型忽略，因此使用pci设备以外的设备显式设置managed与省略它具有相同的效果。同样，model属性仅由中介设备支持，而被所有其他设备类型忽略。

source

​ source元素使用以下机制描述从主机看到的设备：

​ usb

​ USB设备可以通过使用供应商和产品元素的vendor/productid来寻址，也可以通过使用address元素的设备在主机上的address来寻址。

​ 从1.0.0开始，USB设备的source元素可能包含startupPolicy属性，该属性可用于定义策略，如果找不到指定的主机USB设备，该策略将执行什么操作。该属性接受以下值：

​ 从8.6.0起，source元素可以包含具有以下值的guestReset属性：

​ 当为USB设备分配重置时崩溃的固件时，此属性可能很有用。

​ pci

​ PCI设备仅可以通过它们的地址来描述。自6.8.0(仅适用于Xen)起，PCI设备的源元素可以包含writeFiltering属性，用于控制对PCI配置空间的写访问。默认情况下，Xen仅允许对配置空间的已知安全值进行写操作。设置writeFiltering='no'将允许对设备的PCI配置空间进行所有写操作。

​ scsi

​ SCSI设备由适配器和地址元素共同描述。地址元素包括一个bus属性(2位数的总线编号)，一个target属性(10位数的目标编号)和一个unit属性(总线上的20位数的单元编号)。并非所有的虚拟化平台都支持更大的目标和单元值。每个虚拟化平台都会确定适配器支持的最大值。

​ 自1.2.8起，SCSI设备的源元素可以包含protocol属性。当该属性设置为“iscsi”时，主机设备XML遵循网络磁盘设备(请参阅 1.20.1 Hard drives, floppy disks, CDROMs)并使用相同的name属性，可选择使用auth元素提供iSCSI服务器的身份验证凭据。

​ 自6.7.0起，可选的initiator子元素控制通过虚拟化平台运行的起始器的IQN，通过其 子元素进行配置。

​ scsi_host

​ 自2.5.0起，单个SCSI HBA后面的多个LUN通过protocol属性设置为“vhost”以及一个wwpn属性来描述，该wwpn属性是在主机的configfs中建立的vhost_scsi wwpn(16位十六进制数字，带有"naa."前缀)。

​ mdev

​ 中介设备(Mediated devices)(自3.2.0起)通过地址元素来描述。地址元素包含一个必填的uuid属性。

vendor， product

​ vendor和product元素都有一个id属性，用于指定USB vendor和产品id。id可以以十进制、十六进制(以0x开头)或八进制(以0开头)形式给出。

boot

​ 指定设备可用于启动。order属性确定了设备在启动顺序中的尝试顺序。设备级别的boot元素不能与BIOS引导加载器部分中的通用boot元素一起使用。自0.8.8起支持PCI设备，自1.0.1起支持USB设备。

rom

​ rom元素用于更改PCI设备的ROM在宿主中呈现给客户机的方式。可选的bar属性可以设置为"on"或"off"，并确定设备的ROM是否会出现在客户机的内存映射中(在PCI文档中，“rombar”设置控制ROM的基地址寄存器是否存在)。如果未指定rom bar，则将使用qemu的默认设置(较旧版本的qemu使用了默认的"off"，而较新版本的qemu使用了默认的"on")。自0.9.7起(仅适用于QEMU和KVM)。可选的file属性包含一个绝对路径，指向要呈现给客户机作为设备ROM BIOS的二进制文件。这可以用于为支持SR-IOV的以太网设备的虚拟功能提供PXE引导ROM(对于VF而言，这些设备没有VF的引导ROM)。自0.9.10起(仅适用于QEMU和KVM)。可选的enabled属性可以设置为"no"以完全禁用设备的PCI ROM加载；如果通过此属性禁用了PCI ROM加载，则将拒绝尝试使用bar或file属性进一步调整加载过程。自4.3.0起(仅适用于QEMU和KVM)。

address

​ USB设备的address元素具有bus和device属性，用于指定设备在主机上出现的USB总线和设备编号。这些属性的值可以使用十进制、十六进制(以0x开头)或八进制(以0开头)形式表示。对于PCI设备，该元素携带了4个属性，允许将设备指定为可以在lspci或virsh nodedev-list中找到的设备。对于SCSI设备，必须使用’drive’地址类型。对于中介设备，这些是仅由软件定义的设备，定义了物理父设备上的资源分配，使用的地址类型必须符合hostdev元素的model属性，例如，对于vfio-pci设备API，必须使用除PCI以外的任何地址类型，对于vfio-ccw设备API，必须使用除CCW以外的任何地址类型，否则将引发错误。有关address元素的更多详细信息，请参阅 1.20.3 Device Addresses

driver

​ PCI设备可以具有可选的driver子元素，用于指定用于PCI设备分配的后端驱动程序。使用name属性来选择"vfio"(用于新的VFIO设备分配后端，与UEFI SecureBoot兼容)或"kvm"(由KVM内核模块直接处理的传统设备分配)。自1.0.5起(仅适用于QEMU和KVM，需要3.6或更新的内核)。当指定时，如果主机上不支持所请求的设备分配方法，设备分配将失败。如果未指定，默认情况下，在具有可用且加载的VFIO驱动程序的系统上为"vfio"，在较旧的系统上或未加载VFIO驱动程序的系统上为"kvm"。自1.1.3起(在此之前，默认值始终为"kvm")。

readonly

​ 表示设备是只读的，目前仅由SCSI主机设备支持。自1.0.6起(仅适用于QEMU和KVM)。

shareable

​ 如果存在，表示预计设备将在域之间共享(假设hypervisor和操作系统支持此功能)。仅由SCSI主机设备支持。自1.0.6起。

注意：虽然shareable在1.0.6中引入，但直到1.2.2之前它并未按预期工作。

1.20.8.2 Block / character devices

可以使用hostdev元素将来自主机的块/字符设备传递给客户。这只能通过基于容器的虚拟化实现。设备由完全限定的路径指定。自LXC 1.0.1之后：

...
<hostdev mode='capabilities' type='storage'>
  <source>
    <block>/dev/sdf1block>
  source>
hostdev>
...

​ hostdev

​ hostdev元素是用于描述主机设备的主要容器。对于块/字符设备，直通mode始终为“capabilities”，type为块设备的“storage”，字符设备的“misc”，主机网络接口的“net”。

​ source

​ source元素描述了从主机看到的设备。对于块设备，主机操作系统中块设备的路径在嵌套的“block”元素中提供，而对于字符设备，则使用“char”元素。对于网络接口，接口的名称在“interface”元素中提供。

1.20.9 (Redirected devices)

支持通过字符设备重定向USB设备，自0.9.5起(仅限KVM)：

...
<devices>
  <redirdev bus='usb' type='spicevmc'/>
  <redirdev bus='usb' type='tcp'>
    <source mode='connect' host='localhost' service='4000'/>
    <boot order='1'/>
  redirdev>
  <redirfilter>
    <usbdev class='0x08' vendor='0x1234' product='0xbeef' version='2.56' allow='yes'/>
    <usbdev allow='no'/>
  redirfilter>
devices>
...

​ redirdev

​ redirdev元素是用于描述重定向设备的主要容器。对于usb设备，bus必须是“usb”。需要一个额外的属性类型，与支持的串行设备类型之一相匹配(请参阅 1.20.16 Consoles, serial, parallel & channel devices)，以描述隧道的主机侧；type='tcp'或type='picevmc'(使用SPICE图形设备的usbredir通道(参见1.20.14 Graphical framebuffers))是典型的。

​ redirdev元素有一个可选的子元素

，它可以将设备连接到特定的控制器。根据给定的类型，可能需要更多的子元素，如，尽管不需要子元素(因为字符设备的使用者是系统hypervisor本身，而不是 guest中可见的设备)。

​ boot

指定设备是可引导的。order属性确定在引导序列中尝试设备的顺序。在BIOS引导加载程序部分，每个设备的引导元素不能与常规引导元素一起使用。(自1.0.1起)

​ redirfilter

​ dirfilterelement用于创建筛选规则，以从重定向中筛选出某些设备。它使用子元素来定义每个筛选规则。class属性是USB 经典代码，例如0x08表示大容量存储设备。USB设备可以通过供应商vendor/product产品id使用供应商和产品属性进行寻址。version是bcdedit设备字段中的设备版本(不是USB协议的版本)。这四个属性是可选的，-1可以用于允许它们的任何值。allow属性是必需的，“yes”表示允许，“no”表示拒绝。

1.20.10 (Smartcard devices)

虚拟智能卡设备可以通过smartcard元素提供给 guest。主机上的USB智能卡读卡器设备不能在具有简单设备直通的guest身上使用，因为它在主机上不可用，可能会在“移除”主机时锁定主机。因此，一些hypervisor提供了一种专门的虚拟设备，该设备可以向 guest呈现智能卡接口，具有多种模式，用于描述如何从主机甚至从创建给第三方智能卡提供商的通道获得凭据。自0.8.8

...
<devices>
  <smartcard mode='host'/>
  <smartcard mode='host-certificates'>
    <certificate>cert1certificate>
    <certificate>cert2certificate>
    <certificate>cert3certificate>
    <database>/etc/pki/nssdb/database>
  smartcard>
  <smartcard mode='passthrough' type='tcp'>
    <source mode='bind' host='127.0.0.1' service='2001'/>
    <protocol type='raw'/>
    <address type='ccid' controller='0' slot='0'/>
  smartcard>
  <smartcard mode='passthrough' type='spicevmc'/>
devices>
...

元素具有强制属性mode。支持以下模式；在每种模式下， guest都会在其USB总线上看到一个设备，其行为类似于物理USB CCID(芯片/智能卡接口设备)卡。

​ host

​ 最简单的操作，系统hypervisor将来自 guest的所有请求中继为通过NSS直接访问主机的智能卡。不需要其他属性或子元素。请参阅下面关于可选

子元素的使用。

​ host-certificates

​ 不需要将智能卡插入主机，而是可以提供驻留在主机数据库中的三个NSS证书名称。这些证书可以通过命令certutil-d/etc/pki/nssdb-x-t CT，CT，CT-S-S CN=cert1-n cert1生成，并且生成的三个证书名称必须作为三个子元素中的每一个的内容提供。一个额外的子元素可以指定到备用目录的绝对路径(在创建证书时匹配certutil命令的-d选项)；如果不存在，则默认为/etc/pki/nssdb。

​ passthrough

​ 与其让系统hypervisor直接与主机通信，不如通过次要字符设备将所有请求隧道传输到第三方提供商(第三方供应商可能反过来与智能卡通信或使用三个证书文件)。在这种操作模式下，需要一个额外的属性type，与支持的串行设备类型之一相匹配(请参阅1.20.16 Consoles, serial，parallel & channel devices)，以描述隧道的主机侧；type='tcp'或type='picevmc'(使用SPICE图形设备的智能卡通道(参见1.20.16 Graphical framebuffers))是典型的。根据给定的类型，可能需要更多的子元素，如，尽管不需要子元素(因为字符设备的使用者是系统hypervisor本身，而不是 guest中可见的设备)。

每个模式都支持一个可选的子元素

(请参阅1.20.3 Device Addresses)，它可以微调智能卡和ccid总线控制器之间的相关性。目前，qemu最多只支持一个智能卡，地址为bus=0 slot=0。

1.20.11 (Network interfaces)

...
<devices>
  <interface type='direct' trustGuestRxFilters='yes'>
    <source dev='eth0'/>
    <mac address='52:54:00:5d:c7:9e'/>
    <boot order='1'/>
    <rom bar='off'/>
    <acpi index='4'/>
  interface>
devices>
...

有多种方法可以指定对虚拟机可见的网络接口。以下各小节提供了有关常见设置选项的更多详细信息：

自1.2.10起，接口元素的trustGuestRxFilters属性允许主机通过将该属性设置为yes来检测和信任虚拟机关于接口MAC地址和接收过滤器更改的报告。出于安全原因，该属性的默认设置为no，其支持取决于虚拟机的网络设备模型以及主机上的连接类型 - 目前仅支持virtio设备模型和主机上的macvtap连接。

每个元素都可以包含一个可选的

子元素，该子元素可以将接口绑定到特定的PCI插槽，属性type='pci'的设置如Device Addresses 部分所述。

自6.6.0起，可以通过在元素中添加type="static"属性来强制libvirt在MAC地址位于保留的VMware范围内时保持提供的MAC地址不变。请注意，如果提供的MAC地址在保留的VMware范围之外，则此属性将无效。

自7.3.0起，可以为网络接口设置ACPI索引。对于某些操作系统(例如带有systemd的Linux)，ACPI索引用于提供网络接口设备命名，以便在分配给设备的PCI地址更改时保持稳定。该值必须在所有设备中是唯一的，并且必须介于1和(16*1024-1)之间。

1.20.11.1 (Virtual network)

**这是适用于具有动态/无线网络配置的主机或多主机环境的一般虚拟机连接的推荐配置。**如果主机硬件详细信息在定义中单独描述(自0.9.4起)

提供了一个连接，其详细信息由命名的网络定义描述。根据虚拟网络的“转发模式”配置，网络可以是完全隔离的(未提供元素)，NAT到显式网络设备或默认路由()，无NAT路由()，或直接连接到主机的一个网络接口(通过macvtap)或桥接设备( 自0.9.4起)。

对于具有桥接、private、vepa和passthrough转发模式的网络，假定主机已经在libvirt范围之外设置了必要的DNS和DHCP服务。对于隔离、nat和路由网络，libvirt提供了虚拟网络上的DHCP和DNS，IP范围可以通过查看virsh net-dumpxml [networkname]的虚拟网络配置来确定。默认情况下，系统中已经设置了一个名为’default’的虚拟网络，它会将流量进行NAT转发到默认路由，并具有IP范围为192.168.122.0/255.255.255.0。每个虚拟机将会有一个相关联的tun设备，其名称为vnetN，也可以通过元素进行覆盖(请参阅1.20.11.17Overriding the target element)。

当接口的源是网络时，可以指定一个portgroup以及网络的名称；一个网络可以定义多个portgroup，每个portgroup包含了针对不同类型的网络连接的略微不同的配置信息(自0.9.4起)。

当虚拟机运行时，类型为network的接口可能包括一个portid属性。这提供了一个关联的virNetworkPortPtr对象的UUID，记录了域接口与网络之间的关联。由于端口对象在启动和关闭期间会自动创建和删除，所以该属性是只读的(自5.1.0起)。

此外，类似于direct网络连接(下文描述)，类型为network的连接可以指定一个virtualport元素，其中包含要转发到vepa(802.1Qbg)或802.1Qbh兼容交换机(自0.8.2起)，或者转发到Open vSwitch虚拟交换机(自0.9.11起)。

由于实际交换机类型可能根据主机上中的配置而有所不同，因此可以省略virtualport type属性，并指定来自多个不同virtualport类型的属性(也可以省略某些属性)；在域启动时，将通过合并网络中定义的类型和属性以及接口引用的portgroup中的类型和属性来构建完整的元素。新构建的virtualport是它们的组合。较低virtualport的属性不能更改较高virtualport中定义的属性。接口具有最高优先级，端口组具有最低优先级(自0.10.0起)。例如，为了与802.1Qbh交换机和Open vSwitch交换机正常工作，可以选择不指定类型，但同时指定profileid(如果交换机是802.1Qbh)和interfaceid(如果交换机是Open vSwitch)(也可以省略其他属性，例如managerid、typeid或profileid，以从网络的填充)。如果要限制虚拟机仅连接到某些类型的交换机，可以指定virtualport类型，但仍然省略某些/所有参数 - 在这种情况下，如果主机的网络具有不同类型的virtualport，接口的连接将失败。

...
<devices>
  <interface type='network'>
    <source network='default'/>
  interface>
  ...
  <interface type='network'>
    <source network='default' portgroup='engineering'/>
    <target dev='vnet7'/>
    <mac address="00:11:22:33:44:55"/>
    <virtualport>
      <parameters instanceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/>
    virtualport>
  interface>
devices>
...

1.20.11.2 (Bridge to LAN)

这是针对在具有静态有线网络配置的主机上实现一般虚拟机连通性的推荐配置。

它提供了一个桥接连接，将虚拟机直接连接到局域网(LAN)。这假定主机上有一个桥接设备，其中附加了一个或多个主机的物理网卡。虚拟机将具有一个相关联的tun设备，名称为vnetN，也可以使用元素进行覆盖(请参阅1.20.11.17 Overriding the target element)。tun设备将连接到桥接设备上。IP范围/网络配置与LAN上使用的相同。这为虚拟机提供了与物理机一样的完整的入站和出站网络访问权限。

在Linux系统上，桥接设备通常是标准的Linux主机桥接。在支持Open vSwitch的主机上，还可以通过在接口定义中添加来连接到Open vSwitch桥接设备(自0.9.11以来)。Open vSwitch类型的virtualport在其元素中接受两个参数 - 一个interfaceid，这是一个标准的UUID，用于唯一标识Open vSwitch中的这个特定接口(如果您没有指定一个，当您首次定义接口时，将为您生成一个随机的interfaceid)，以及一个可选的profileid，它作为接口的“port-profile”发送到Open vSwitch。

...
<devices>
  ...
  <interface type='bridge'>
    <source bridge='br0'/>
  interface>
  <interface type='bridge'>
    <source bridge='br1'/>
    <target dev='vnet7'/>
    <mac address="00:11:22:33:44:55"/>
  interface>
  <interface type='bridge'>
    <source bridge='ovsbr'/>
    <virtualport type='openvswitch'>
      <parameters profileid='menial' interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/>
    virtualport>
  interface>
  ...
devices>
...

在内核侧支持Open vSwitch并配置了Midonet Host Agent的主机上，也可以通过在接口定义中添加来连接到’Midonet’桥接设备。(自1.2.13起)。Midonet虚拟端口类型在其元素中需要一个interfaceid属性。此接口id是指定虚拟网络拓扑中哪个端口将绑定到接口的UUID。

...
<devices>
  ...
  <interface type='bridge'>
    <source bridge='br0'/>
  interface>
  <interface type='bridge'>
    <source bridge='br1'/>
    <target dev='vnet7'/>
    <mac address="00:11:22:33:44:55"/>
  interface>
  <interface type='bridge'>
    <source bridge='midonet'/>
    <virtualport type='midonet'>
      <parameters interfaceid='0b2d64da-3d0e-431e-afdd-804415d6ebbb'/>
    virtualport>
  interface>
  ...
devices>
...

1.20.11.3 (Userspace(SLIRP or passt) connection)

user类型通过一个透明的用户空间代理将guest接口连接到外部，该代理不需要任何特殊的系统权限，使其在libvirt本身没有权限运行的情况下可用(例如，libvirt的“会话模式”守护进程，或当libvirt在无特权容器中运行时)。

默认情况下，此用户代理是由QEMU的内部SLRP驱动程序完成的，该驱动程序具有DHCP和DNS服务，这些服务提供从10.0.2.15开始的guestIP地址，默认路由为10.0.2.2，DNS服务器为10.0.2.3。自3.8.0起，可以通过在其一个强制属性address中包含指定IPv4地址的ip元素来覆盖默认网络地址。可选地，可以指定family属性设置为“ipv6”的第二个ip元素，以向接口添加ipv6地址。address可以选择指定地址前缀。

...
<devices>
  <interface type='user'/>
  ...
  <interface type='user'>
    <mac address="00:11:22:33:44:55"/>
    <ip family='ipv4' address='172.17.2.0' prefix='24'/>
    <ip family='ipv6' address='2001:db8:ac10:fd01::' prefix='64'/>
  interface>
devices>
...

自9.0.0版本以来，可以通过将界面的子元素type属性设置为passt来选择user界面类型的备用后端实现。在这种情况下，将使用passt传输([https://passt.top)。与SLIRP类似，passt具有内部DHCP服务器，为请求的虚拟机提供一个IPv4和一个IPv6地址；然后，它使用用户空间代理和单独的网络命名空间来提供出站UDP/TCP/ICMP会话，并可选择将目标主机的入站流量重定向到虚拟机。

当使用passt后端时，属性logFile可用于告诉passt进程为此接口的消息日志写入的位置，并且属性dev可以告诉它使用特定的主机接口来派生向虚拟机提供用于转发流量的路由。由于passt的设计决策，如果使用SELinux，建议将日志文件放置在passt进程将运行的用户的运行时目录中，最有可能是/run/user/$UID，其中$UID是用户的UID，例如qemu。请注意，为避免可能的问题，特别是由于此日志文件属性主要用于调试，因此libvirt不会创建此目录，除非它已经存在。

此外，当使用passt时，可以添加多个元素以将目标主机的入站网络流量转发到此虚拟机界面。每个必须具有proto属性(设置为tcp或udp)，可选的原始地址(如果未指定，则将所有传入的会话转发到给定proto/port的任何主机IP的guest)，以及可选的dev属性，以将转发的流量限制为特定的主机接口。

关于要转发哪些端口的决策由的零个或多个子元素描述(如果没有，则将转发给定proto/address的所有端口)。每个具有一个start和可选的end属性。如果省略end，则将转发单个端口，否则将转发start和end(包括在内)之间的所有端口。如果端口号应保持不变，因为会话被转发，那么不需要进一步的选项，但如果虚拟机期望在不同的端口上接收会话，则应在的to属性中指定 - 范围内每个转发的会话的端口号将偏移“to - start”。元素还可用于指定不应转发的端口范围。这是通过将范围的exclude属性设置为yes来完成的。这可能看起来不太有用，但在希望转发一长段端口的同时排除某些子集时，可以使用。

...
<devices>
  ...
  <interface type='user'>
    <backend type='passt' logFile='/run/user/$UID/passt-domain.log'/>
    <mac address="00:11:22:33:44:55"/>
    <source dev='eth0'/>
    <ip family='ipv4' address='172.17.2.4' prefix='24'/>
    <ip family='ipv6' address='2001:db8:ac10:fd01::20'/>
    <portForward proto='tcp'>
      <range start='2022' to='22'/>
    portForward>
    <portForward proto='udp' address='1.2.3.4'>
      <range start='5000' end='5020' to='6000'/>
      <range start='5010' end='5015' exclude='yes'/>
    portForward>
    <portForward proto='tcp' address='2001:db8:ac10:fd01::1:10' dev='eth0'>
      <range start='80'/>
      <range start='443' to='344'/>
    portForward>
  interface>
devices>
...

1.20.11.4 (Generic ethernet connection)

提供一种使用新的或现有的tap设备(或veth设备对，取决于hypervisor驱动程序的需求)的方法，该设备部分或完全在libvirt之外进行设置(要么在虚拟机启动之前，要么在通过配置中指定的可选脚本启动虚拟机时)。

可以选择使用元素的dev属性指定tap设备的名称。如果未指定目标dev，则libvirt将创建一个新的标准tap设备，其名称模式为“vnetN”，其中“N”将替换为数字。如果指定了目标dev并且该设备不存在，那么将创建一个具有给定dev名称的新标准tap设备。如果指定的目标dev存在，则将使用该现有设备。通常，libvirt会对设备进行一些基本设置，包括设置MAC地址和IFF_UP标志，但如果dev是一个预先存在的设备，并且元素的managed属性也设置为“no”(默认值为“yes”)，甚至连这个基本设置都不会执行 - libvirt将只是将设备传递给hypervisor而没有任何设置。从5.7.0版本开始，使用`managed='no’与预先创建的tap设备很有用，因为它允许由非特权libvirtd管理的虚拟机具有基于tap设备的模拟网络设备。

在创建/打开tap设备后，将运行一个可选的shell脚本(在