附录 B. API 版本 4 的更改

对 YAML 的支持已完全删除。

以下 XML 模式复杂类型已被重命名：

目前，不同对象的状态是使用 Status 类型报告，它包含一个 状态 字符串和另一个详细信息 字符串 以了解更多详细信息。例如，当前报告因为 IO 错误而暂停的虚拟机的状态，如下所示：

<vm>
  ...
  <status>
    <state>paused</state>
    <detail>eio</detail>
  </status>
  ...
</vm>

在 API 的版本 4 中，此 Status 类型已删除，并被 enum type 替换。需要额外的 详细信息 字符串时，它已被额外的 status_detail 属性替代。例如，同一虚拟机的状态现在将报告如下：

<vm>
  ...
  <status>paused</status>
  <status_detail>eio</status_detail>
  ...
</vm>

NIC 网络和 port_mirroring 元素已被 vnic_profile 元素替代，因此在创建或更新 NIC 时，不会指定网络和端口镜像配置，这些会预先指定创建 vNIC 配置集：

POST /ovirt-engine/api/vnicprofiles

<vnic_profile>
  <name>myprofile</name>
  <network id="..."/>
  <port_mirroring>true</port_mirroring>
</vnic_profile>

然后，创建 NIC 或引用现有的 vNIC 配置集：

PUT /ovirt-engine/api/vms/123/nics/456

<nic>
  <vnic_profile id="/vnicprofiles/...">
</nic>

旧元素及其含义保留下来，以便向后兼容，但现已完全删除。

请注意，网络 元素尚未从 XML 架构中删除，因为它仍由 初始化 元素使用，但是如果在创建或更新 NIC 时提供，则完全被忽略。

NIC active 属性在一段时间前被 插入。现在它已被完全删除。

磁盘 的类型 属性已被删除，但保留在 XML 架构中并忽略。现在它已被完全删除。

磁盘大小 属性在之前已被 provisioned_size 替代。现在它已被完全删除。

在版本 3.6 之前，API 可以使用 VM 实体的 placement_policy 元素将虚拟机固定到单一主机上：

PUT /ovirt-engine/api/vms/123

<vm>
  <placement_policy>
    <host id="456"/>
  </placement_policy>
<vm>

在版本 3.6 中，这个功能被改进来支持多个主机，并添加了一个新的 主机 元素：

PUT /ovirt-engine/api/vms/123

<vm>
  <placement_policy>
    <hosts>
      <host id="456"/>
      <host id="789"/>
      ...
    </hosts>
  </placement_policy>
<vm>

为了保持向后兼容性，单一 主机 元素已被保留。在 4.0 中，这已被删除，因此即使固定到单个主机，应用也需要使用 hosts 元素。

对于每个集群级别，其允许列表可能有所不同，而且几年前已添加到 version 元素中，但它也保留在 capabilities 元素中，只是为了向后兼容。

在 4.0 中，功能 服务已被完全删除，并被新的集群级别 服务替代。要查找集群级别 4.0 支持的允许，应使用如下请求：

GET /ovirt-engine/api/clusterlevels/4.0

结果将是包含特定于该集群级别的信息的文档，特别是所支持的允许集合：

<cluster_level id="4.0" href="/clusterlevels/4.0">
  ...
  <permits>
    <permit id="1">
      <name>create_vm</name>
      <administrative>false</administrative>
    </permit>
    ...
  </permits>
</cluster_level>

storage_manager 元素在一段时间前已被 spm 元素取代。旧版本保留为向后兼容性，但现已完全删除。

数据中心过去与特定的存储类型（NFS、光纤通道、iSCSI 等）关联，但是它们已经进行了更改，使得只有两种类型：本地存储以及共享存储。引入了一个新的 本地 元素来指示这一点，并且保留了旧的 storage_type 元素，以便向后兼容。这个旧元素现已完全删除。

用于包含用于表示时区的 timezone 元素的虚拟机资源。这个元素只允许字符串：

<vm>
  <timezone>Europe/Madrid</timezone>
</vm>

这不允许扩展，因为需要添加 UTC 偏移，它被替换为一个新的结构化 time_zone 元素：

<vm>
  <time_zone>
    <name>Europe/Madrid</name>
    <utc_offset>GMT+1</utc_offset>
  </time_zone>
</vm>

旧 时区 元素已被保留，但现已完全删除。

guest_info 元素用于存放客户机代理收集的信息，如 IP 地址和完全限定主机名。此信息在其他地点也可获得。例如，IP 地址在 VM 资源中可用：

GET /ovirt-engine/api/vms/123

<vm>
  <guest_info>
    <ips>
      <ip address="192.168.122.30"/>
    </ips>
    <fqdn>myvm.example.com</fqdn>
  </guest_info>
</vm>

另外，在 NIC 资源中使用较新的 reporting _devices 元素：

GET /ovirt-engine/api/vms/{vm:id}/nics/{nic:id}

<nic>
  <reported_devices>
    <reported_device>
      <name>eth0</name>
      <mac address="00:1a:4a:b5:4c:94"/>
      <ips>
        <ip address="192.168.1.115" version="v4"/>
        <ip address="fe80::21a:4aff:feb5:4c94" version="v6"/>
        <ip address="::1:21a:4aff:feb5:4c94" version="v6"/>
      </ips>
    </reported_device>
  </reported_devices>
</nic>

此外，这个较新的 report_devices 元素还提供更完整的信息，如多个 IP 地址、MAC 地址等。

为删除此重复 ，guest_info 元素已被删除。

为了支持完全限定域名，在 VM 资源中添加了新的 fqdn 元素：

GET /ovirt-engine/api/vms/123

<vm>
  <fqdn>myvm.example.com</fqdn>
</vms>

此命令将包含 guest_info.fqdn 用于包含的相同信息。

用于具有代表 CPU 类型的 id 属性的 cpu 元素：

<cpu id="Intel Nehalem Family">
  <architecture>X86_64</architecture>
  ...
</cpu>

这与 API 模型的其余元素有关，其中 id 属性用于不透明标识符。这个 id 属性已被一个新的 type 元素替代：

<cpu>
  <type>Intel Nehalem Family</type>
  <architecture>X86_64</architecture>
</cpu>

在过去，CPU 拓扑元素将属性用作其属性：

<cpu>
  <topology sockets="1" cores="1" threads="1"/>
  ...
</cpu>

这与 API 中的常见做法相反。它们已被内联元素取代：

<cpu>
  <topology>
    <sockets>1<sockets>
    <cores>1<cores>
    <threads>1<threads>
  </topology>
  ...
</cpu>

在过去，VCPU pin 元素将属性用作其属性：

<cpu_tune>
  <vcpu_pin vcpu="0" cpu_set="0"/>
</cpu_tune>

这与 API 中的常见做法相反。它们已被内联元素取代：

<cpu_tune>
  <vcpu_pin>
    <vcpu>0</vcpu>
    <cpu_set>0</cpu_set>
  </vcpu_pin>
</cpu_tune>

在过去，version 元素的属性是它的属性：

<version major="3" minor="5" ../>

这与 API 中的常见做法相反。它们已被内联元素取代：

<version>
  <major>3</minor>
  <minor>5</minor>
  ...
</version>

过去，过量使用 元素的属性是它的属性：

<memory_policy>
  <overcommit percent="100"/>
  ...
</memory_policy>

这与 API 中的常见做法相反。它们已被内联元素取代：

<memory_policy>
  <overcommit>
    <percent>100</percent>
  </overcommit>
  ...
</memory_policy>

在过去，console 元素 将属性用作其属性：

<console enabled="true"/>

这与 API 中的常见做法相反。它们已被内联元素取代：

<console>
  <enabled>true</enabled>
</console>

在过去，VIRTIO ISCSI 元素在其属性中使用属性：

<virtio_scsi enabled="true"/>

这与 API 中的常见做法相反。它们已被内联元素取代：

<virtio_scsi>
  <enabled>true</enabled>
</virtio_scsi>

电源管理 类型 属性表示为属性：

<agent type="apc">
  <username>myuser</username>
  ...
</agent>

这与 API 中的常见做法相反。它已被一个内部元素替代：

<agent>
  <type>apc</type>
  <username>myuser</username>
  ...
</agent>

在过去，电源管理代理选项元素在其属性中使用属性：

<options>
  <option name="port" value="22"/>
  <option name="slot" value="5"/>
  ...
</options>

这与 API 中的常见做法相反。它们已被内联元素取代：

<options>
  <option>
    <name>port</name>
    <value>22</value>
  </option>
  <option>
    <name>slot</name>
    <value>5</value>
  </option>
  ...
</options>

在过去，IP 地址元素将属性用作其属性：

<ip address="192.168.122.1" netmask="255.255.255.0"/>

这与 API 中的常见做法相反。它们已被内联元素取代：

<ip>
  <address>192.168.122.1</address>
  <netmask>255.255.255.0</netmask>
</ip>

在过去，MAC 地址元素将属性用作其属性：

<mac address="66:f2:c5:5f:bb:8d"/>

这与 API 中的常见做法相反。它们已被内联元素取代：

<mac>
  <address>66:f2:c5:5f:bb:8d</address>
</mac>

在过去，引导设备元素将属性用作其属性：

<boot dev="cdrom"/>

这与 API 中的常见做法相反。它们已被内联元素取代：

<boot>
  <dev>cdrom</dev>
</boot>

操作系统 类型 属性表示为属性：

<os type="other">
  ...
</os>

这与 API 中的常见做法相反。它已被一个内部元素替代：

<os>
  <type>other</type>
  ...
</os>

在从数据库检索之前，要检索用于支持 强制 矩阵参数的主机的请求，以指示应该刷新主机数据（扩展 VDSM 以重新加载主机功能和设备）：

GET /ovirt-engine/api/hosts/123;force

此 force 参数已被主机 刷新 操作取代，但保留为向后兼容性。现在它已被完全删除。需要此功能的应用程序应执行两个请求，第一个用于刷新主机：

POST /ovirt-engine/api/hosts/123/refresh

<action/>

然后，在没有 force 参数的情况下检索它：

GET /ovirt-engine/api/hosts/123

主机电源管理配置过去是主机资源的一部分，使用嵌入式配置元素：

<power_management type="apc">
  <enabled>true</enabled>
  <address>myaddress</address>
  <username>myaddress</username>
  <options>
    <option name="port" value="22/>
    </option name="slot" value="5/>
  </options>
  ...
</power_management>

这在几年前已经改变，为了支持多个电源管理代理，引入一个新的 /hosts/123/fenceagents 集合。

旧 类型 属性、旧 地址、用户名和密码 元素以及直接在 power_management 内的内 代理 元素保留下来，以便向后兼容性。所有这些元素已完全删除，因此查询或修改电源管理代理的唯一方法是 /hosts/123/fenceagents 子集合。

过去，在启动虚拟机时指定启动序列的方法是使用多个 引导 元素，每个元素包含一个 dev 元素。例如，指定虚拟机应首先尝试从 CDROM 引导，然后从硬盘引导，并使用以下请求：

POST /ovirt-engine/api/vms/123/start

<action>
  <vm>
    ...
    <boot>
      <dev>cdrom</dev>
    </boot>
    <boot>
      <dev>hd</dev>
    </boot>
  </vm>
</action>

API 其它部分的常见做法是使用 wrapper 元素表示数组。在这种情况下，wrapper 元素可以命名为 boots ， 但这并不合理，因为此处的有多个值是引导设备，而不是启动序列。要修复这个不一致性的问题，这个错误已被一个可以包含多个设备的 引导 元素替代：

POST /ovirt-engine/api/vms/123/start

<action>
  <vm>
    ...
    <boot>
      <devices>
        <device>cdrom</device>
        <device>hd</device>
      </devices>
    </boot>
  </vm>
</action>

这些元素不是磁盘表示的一部分，而是添加和删除虚拟机的操作参数。

disks.clone 元素用于指示必须克隆新虚拟机的磁盘：

POST /ovirt-engine/api/vms

<vm>
  ...
  <disks>
    <clone>true</clone>
  </disks>
<vm>

现在，这已被删除，并使用一个新的 克隆 查询参数替换：

POST /ovirt-engine/api/vms?clone=true

<vm>
  ...
</vm>

disks.detach_only 元素用于指示在删除虚拟机时磁盘不必删除，而是从虚拟机分离：

DELETE /ovirt-engine/api/vms/123

<action>
  <vm>
    <disks>
      <detach_only>true</detach_only>
    </disks>
  </vm>
</action>

现在，这已被删除，并被一个新的 detach_only 查询参数替代：

DELETE /ovirt-engine/api/vms/123?detach_only=true

代表虚拟机池的元素的名称，如 vmpool 和 vm pools。它们已被重命名为 vm_pool 和 vm_pools，以便在复杂类型的名称（本例中为VmPool 和 VmPools ）和元素之间保持一致。

作为卷组的一部分的逻辑单元，报告为未绑定的 logical_unit 元素。例如，当报告存储域详情时：

GET /ovirt-engine/api/storagedomains/123

<storage_domain>
  ...
  <storage>
    ...
    <volume_group>
      <logical_unit>
        <!-- First LU -->
      </logical_unit>
      <logical_unit>
        <!-- Second LU -->
      </logical_unit>
      ...
    </volume_group>
  </storage>
</storage_domain>

这与 API 中的常见做法相反，因为元素列表始终包含在元素中。这个问题现已解决，因此逻辑单元列表将与 logical_units 元素一起换行：

GET /ovirt-engine/api/storagedomains/123

<storage_domain>
  ...
  <storage>
    ...
    <volume_group>
      <logical_units>
        <logical_unit>
          <!-- First LU -->
        </logical_unit>
        <logical_unit>
          <!-- Second LU -->
        </logical_unit>
        ...
      </logical_units>
    </volume_group>
  </storage>
</storage_domain>

此元素实际上不是快照表示的一部分，而是从导出存储域导入虚拟机的操作参数：

POST /ovirt-engine/api/storagedomains/123/vms/456/import

<action>
  <vm>
    <snapshots>
      <collapse_snapshots>true</collapse_snapshots>
    </snapshots>
  </vm>
</action>

现在，这已被删除，并被一个新的 折叠_snapshots 查询参数替代：

POST /ovirt-engine/api/storagedomains/123/vms/456/import?collapse_snapshots=true

<action/>

主机存储集合使用 存储和 host_storage 元素以及 Storage 和 HostStorage 复杂类型来报告与主机关联的存储：

GET /ovirt-engine/api/hosts/123/storage

<host_storage>
  <storage>
    ...
  </storage>
  <storage>
    ...
  </storage>
  ...
</host_storage>

这不遵循 API 的其余部分中使用的模式，其中外部元素是复数名称，内元素是同名，但单数表示。现在，它已被修改为使用 host_storages 作为外部元素，host_storage 作为内部元素：

GET /ovirt-engine/api/hosts/123/storage

<host_storages>
  <host_storage>
    ...
  </host_storage>
  <host_storage>
    ...
  </host_storage>
  ...
</host_storage>

此元素不是权限表示的一部分，而是创建虚拟机或模板的操作参数：

POST /ovirt-engine/api/vms

<vm>
  <template id="...">
    <permissions>
      <clone>true</clone>
    </permissions>
  </template>
</action>

POST /ovirt-engine/api/templates

<template>
  <vm id="...">
    <permissions>
      <clone>true</clone>
    </permissions>
  </vm>
</template>

现在，这已被删除，并被新的 clone_permissions 查询参数替代：

POST /ovirt-engine/api/vms?clone_permissions=true

<vm>
  <template id="..."/>
</vm>

POST /ovirt-engine/api/templates?clone_permissions=true

<template>
  <vm id="..."/>
</template>

用来使用一组源元素来报告随机数生成器 源，以一个元素括起，名称应反映其用途。例如，以前报告的集群的随机数字生成器源如下：

GET /ovirt-engine/api/clusters/123

<cluster>
  ...
  <required_rng_sources>
    <source>random</source>
  </required_rng_sources>
  ...
</cluster>

以及一个用于报告的主机的随机数字生成器源，如下所示：

GET /ovirt-engine/api/hosts/123

<host>
  ...
  <hardware_information>
    <supported_rng_sources>
      <source>random</source>
    </supported_rng_sources>
  </hardware_information>
  ...
</host>

这与 API 的其余部分不一致，其中集合用一个名称括起，以单数形式按相同名称括起元素。这个问题现已解决。现在会报告所需的随机数生成器源，如下所示：

GET /ovirt-engine/api/clusters/123

<cluster>
  <required_rng_sources>
    <required_rng_sources>random</required_rng_source>
  </required_rng_sources>
  ...
</cluster>

主机支持的随机数生成器源将报告如下：

GET /ovirt-engine/api/hosts/123

<host>
  ...
  <hardware_information>
    <supported_rng_sources>
      <supported_rng_source>random</supported_rng_source>
    </supported_rng_sources>
  </hardware_information>
  ...
</host>

注意 required_rng_source 和 supported_ rng_source 的使用，而不是只使用 source。

关系建立标签，过去使用非终端父标签表示 的父 标签，后者包含另一个 标签 元素：

<tag>
  <name>mytag</name>
  <parent>
    <tag id="..." href="..."/>
  </parent>
</tag>

这个结构已被简化，现在只使用一个 父 元素：

<tag>
  <name>mytag</name>
  <parent id="..." href="..."/>
</tag>

在过去，集群的调度策略的规格基于内置名称和阈值。例如，使用均匀分布式调度策略的集群被表示如下 ：

<cluster>
  <name>mycluster</name>
  <scheduling_policy>
    <policy>evenly_distributed</policy>
    <thresholds high="80" duration="120"/>
  </scheduling_policy>
  ...
</cluster>

这种机制被一个顶层 /schedulingpolicies 集合替代，在这里可以使用任意名称和属性定义调度策略。例如，相同的调度策略在顶级集合中被表示如下：

<scheduling_policy>
  <name>evenly_distributed</name>
  <properties>
    <property>
      <name>CpuOverCommitDurationMinutes</name>
      <value>2</value>
    </property>
    <property>
      <name>HighUtilization</name>
      <value>80</value>
    </property>
  </properties>
</scheduling_policy>

集群的表示法引用调度策略及其标识符：

<cluster>
  <name>mycluster</name>
  <scheduling_policy id="..."/>
  ...
</cluster>

为保持向后兼容性，旧 策略 和 阈值 元素得以保留。嵌入在集群中的调度策略表示也被保留。所有这些操作现已被完全删除，因此在检索、创建或更新集群时引用调度策略的唯一方法是使用其标识符引用现有的集群。例如，当检索集群时，只会填充 id （和 href）：

GET /ovirt-engine/api/clusters/123

<cluster>
  ...
  <scheduling_policy id="..." href="..."/>
  ...
</cluster>

在创建或更新集群时，仅接受 id。

这些元素实际上不是 brick 集合表示的一部分，而是用于添加和删除 brick 的操作参数。现在删除了它们，并被新的 replica_count 和 stripe_count 参数 替代：

POST .../bricks?replica_count=3&stripe_count=2

DELETE .../bricks?replica_count=3

用于使用表示统计 类型的类型 元素（计量、计数器等）以及表示值类型（整数、字符串等）的 type 属性来表示统计：

<statistic>
  <type>GAUGE</type>
  <values type="INTEGER">
    <value>...</value>
    <value>...</value>
    ...
  </values>
</statistic>

为避免对第两种事物都使用 类型 概念，现在 kind 和 type 都是元素：

<statistic>
  <kind>gauge</kind>
  <type>integer</type>
  <values>
    <value>...</value>
    <value>...</value>
    ...
  </values>
</statistic>

过去，将虚拟机的虚拟 CPU 固定指定为物理 CPU 固定的方法是使用多个 vcpu_pin 元素：

<vm>
  <cpu>
    <cpu_tune>
      <vcpu_pin>...</vcpu_pin>
      <vcpu_pin>...</vcpu_pin>
      ...
    </cpu_tune>
  </cpu>
</vm>

为了遵循 API 其它部分中的常见做法，它已改为使用 wrapper 元素，本例中为 vcpu_pins ：

<vm>
  <cpu>
    <cpu_tune>
      <vcpu_pins>
        <vcpu_pin>...</vcpu_pin>
        <vcpu_pin>...</vcpu_pin>
        ...
      </vcpu_pins>
    </cpu_tune>
  </cpu>
</vm>

删除数据中心的操作支持 force 参数。要使用它来支持可选的 action 参数，请执行 DELETE 操作：

DELETE /ovirt-engine/api/datacenters/123

<action>
  <force>true</force>
</action>

此可选的 action 参数已被一个可选参数替代：

DELETE /ovirt-engine/api/datacenters/123?force=true

删除主机的 操作支持 force 参数。要使用它来支持可选的 action 参数，请执行 DELETE 操作：

DELETE /ovirt-engine/api/host/123

<action>
  <force>true</force>
</action>

此可选的 action 参数已被一个可选参数替代：

DELETE /ovirt-engine/api/host/123?force=true

删除存储域的操作支持 强制、销毁和主机 参数。这些参数使用作为正文的存储域表示给 DELETE 方法：

DELETE /ovirt-engine/api/storagedomains/123

<storage_domain>
  <force>...</force>
  <destroy>...</destroy>
  <host id="...">
    <name>...</name>
  </host>
</storage_domain>

这个问题存在问题，因为 HTTP DELETE 参数不应具有正文，并且存储域的表示形式不应包含存储域属性之外的内容，而是包含操作的参数。

force、delete 和 host 属性已被等同的参数替代，操作现在不接受正文。例如，现在使用 force 参数删除存储域的正确方法是：

DELETE /ovirt-engine/api/storagedomain/123?host=myhost&force=true

使用 destroy 参数删除：

DELETE /ovirt-engine/api/storagedomain/123?host=myhost&destroy=true

删除存储服务器连接的操作支持 主机 参数。要使用它来支持可选的 action 参数，请使用 DELETE 方法：

DELETE /ovirt-engine/api/storageconnections/123

<action>
  <host id="...">
    <name>...</name>
  </host>
</action>

此可选的 action 参数已被一个可选参数替代：

DELETE /ovirt-engine/api/storageconnections/123?host=myhost

删除模板磁盘的操作支持 force 和 storage_domain 参数。要使用它，可使用 DELETE 方法来支持可选的 action 参数：

DELETE /ovirt-engine/api/templates/123/disks/456

<action>
  <force>...</force>
  <storage_domain id="..."/>
</action>

在 API 版本 4 中，此操作被移到新的 磁盘附加集合中，请求正文已被查询参数 force 和 storage_domain 替代：

DELETE /ovirt-engine/api/templates/123/disksattachments/456?force=true

DELETE /ovirt-engine/api/templates/123/disksattachments/456?storage_domain=123

通过删除 /vms/123/disks/456 来删除实体意味着删除虚拟机与磁盘之间的关系 - 例如，此操作应该仅仅将磁盘从虚拟机分离。此操作无法从系统完全删除磁盘，这容易出现用户错误，并产生无法更正的后果。要删除磁盘，请使用 /disk/456 API:

DELETE /ovirt-engine/api/disks/456

删除虚拟机的操作支持 force 参数。要使用它来支持可选的 action 参数，请使用 DELETE 方法：

DELETE /ovirt-engine/api/vms/123

<action>
  <force>true</force>
</action>

此可选的 action 参数已被一个可选的查询参数替代：

DELETE /ovirt-engine/api/vms/123?force=true

删除多个 Gluster brick 的操作是使用 DELETE 方法实施的，并将 brick 列表作为请求的正文传递：

DELETE /ovirt-engine/api/clusters/123/glustervolumes/456/bricks

<bricks>
  <bricks id="..."/>
  <bricks id="..."/>
  ...
</bricks>

这有问题，因为 DELETE 方法不应该有正文，因此它已被使用 POST 方法的新 删除 操作替代：

POST /ovirt-engine/api/clusters/123/glustervolumes/456/bricks/remove

<bricks>
  <bricks id="..."/>
  <bricks id="..."/>
  ...
</bricks>

该元素保留下来以便向后兼容。改为使用 scheduling_policy.name。

POST /ovirt-engine/api/schedulingpolicies

<scheduling_policy>
  ...
  <name>policy_name</name>
  ...
</scheduling_policy>

PUT /ovirt-engine/api/schedulingpolicies/123

<scheduling_policy>
  ...
  <name>policy_name</name>
  ...
</scheduling_policy>

API 正在逐渐引入枚举。直到现在为止，一些将成为字符串的字段被替换为适当的枚举。其中一个字段是 vm.type。但是，此字段由快照继承，快照类型与 vm 类型不同。因此，快照实体添加了一个新字段： snapshot.snapshot_type。

<snapshot>
  ...
  <snapshot_type>regular|active|stateless|preview</snapshot_type>
  ...
</snapshot>

虚拟机 实体已弃用 的移动 操作已被删除。相反，您可以移动内置磁盘。

在 API 的版本 3 中，XML 模式类型 ReportedConfigurations 具有 in_sync 属性：

<network_attachment>
  <reported_configurations>
    <in_sync>true</in_sync>
    <reported_configuration>
      ...
    </reported_configuration>
    ...
  </reported_configurations>
</network_attachment>

在 API 版本 4 使用的规范机制中，这无法表达，因为列表类型（报告配置列表）不能有属性。为了代表它，属性已被移到括起的 network_attachment 中 ：

<network_attachment>
  <in_sync>true</in_sync>
  <reported_configurations>
    <reported_configuration>
      ...
    </reported_configuration>
    ...
  </reported_configurations>
</network_attachment>

顶级 功能 集合已被新的 集群级别集合 取代。这个新集合将包含模型中不可用的信息，如每个集群级别的 CPU 类型列表：

GET /ovirt-engine/api/clusterlevels

这将返回一个 ClusterLevel 对象列表，其中包含系统支持的所有集群级别的详情：

<cluster_levels>
  <cluster_level id="3.6" href="/clusterlevels/3.6">
    <cpu_types>
      <cpu_type>
        <name>Intel Nehalem Family</name>
        <level>2</level>
        <architecture>x86_64</architecture>
      </cpu_type>
      ...
    </cpu_types>
    ...
  </cluster_level>
</cluster_levels>

每个特定集群级别都有自己的子资源，由版本本身标识：

GET /ovirt-engine/api/clusterlevels/3.6

这将返回该版本的详情：

<cluster_level id="3.6" href="/clusterlevels/3.6">
  <cpu_types>
    <cpu_type>
      <name>Intel Nehalem Family</name>
      <level>2</level>
      <architecture>x86_64</architecture>
    </cpu_type>
    ...
  </cpu_types>
  ...
</cluster_level>

在 API 虚拟机的版本 3 中，模板有一个 磁盘 集合，其中包含附加的磁盘的所有信息。在 API 版本 4 中，这些 磁盘 集合已删除，并替换为一个新的 磁盘附加集合，该集合将仅包含对磁盘的引用以及磁盘与其附加的虚拟机或模板之间的关系特定属性： 接口和可 启动。

要查找附加到虚拟机的磁盘，例如，发送如下请求：

GET /ovirt-engine/api/vms/123/diskattachments

这会返回类似如下的响应：

<disk_attachments>
  <disk_attachment href="/vms/123/diskattachments/456" id="456">
    <bootable>false</bootable>
    <interface>virtio</interface>
    <disk href="/disks/456" id="456"/>
    <vm href="/vms/123" id="123"/>
  </disk_attachment>
  ...
<disk_attachments>

要查找磁盘的其余详细信息，请使用提供的链接。

在虚拟机或模板中添加磁盘也使用新的 disk_attachment 元素：如下请求：

POST /ovirt-engine/api/vms/123/diskattachments

如果磁盘不存在且您要创建它，请使用以下正文：

<disk_attachment>
  <bootable>false</bootable>
  <interface>virtio</interface>
  <disk>
    <description>My disk</description>
    <format>cow</format>
    <name>mydisk</name>
    <provisioned_size>1048576</provisioned_size>
    <storage_domains>
      <storage_domain>
        <name>mydata</name>
      </storage_domain>
    </storage_domains>
  </disk>
</disk_attachment>

或者，如果磁盘已存在，则使用以下正文，且您只想将其附加到虚拟机：

<disk_attachment>
  <bootable>false</bootable>
  <interface>virtio</interface>
  <disk id="456"/>
</disk_attachment>

考虑 vm.disks 和 template. disks attribtes 具有所有使用的 disk_attachments。例如，在创建模板时，vm.disks 元素用于指示在其中创建模板磁盘的存储域。这个用法已被 vm.disk_attachments 替代，因此，在特定存储域中创建带有磁盘的模板的请求现在类似如下：

<template>
  <name>mytemplate</name>
  <vm id="123">
    <disk_attachments>
      <disk_attachment>
        <disk id="456">
          <storage_domains>
            <storage_domain id="789"/>
          </storage_domains>
        </disk>
      </disk_attachment>
      ...
    </disk_attachments>
  </vm>
</template>

在 API 版本 3 中，使用多个 iscsi_target 元素来发现用于接收 iSCSI 目标列表的未注册存储域的操作：

POST /ovirt-engine/api/hosts/123/unregisteredstoragedomaindiscover

<action>
  <iscsi>
    <address>myiscsiserver</address>
  </iscsi>
  <iscsi_target>iqn.2016-07.com.example:mytarget1</iscsi_target>
  <iscsi_target>iqn.2016-07.com.example:mytarget2</iscsi_target>
</action>

在 API 版本 4 中，所有重复元素（本例中为 iscsi_target ）都使用另一个元素 iscsi_targets 进行打包，以防出现 iscsi_targets。因此，同一请求现在应类似如下：

POST /ovirt-engine/api/hosts/123/unregisteredstoragedomaindiscover

<action>
  <iscsi>
    <address>myiscsiserver</address>
  </iscsi>
  <iscsi_targets>
    <iscsi_target>iqn.2016-07.com.example:mytarget1</iscsi_target>
    <iscsi_target>iqn.2016-07.com.example:mytarget2</iscsi_target>
  </iscsi_targets>
</action>