부록 B. API 버전 4의 변경 사항

YAML 지원이 완전히 제거되었습니다.

다음과 같은 XML 스키마 복잡한 유형의 이름이 변경되었습니다.

현재 상태 유형을 사용하여 다양한 오브젝트의 상태를 보고하며, 여기에는 상태 및 추가 세부 정보에 대한 상태 문자열을 설명하는 상태 문자열이 포함됩니다. 예를 들어 IO 오류로 인해 일시 중지된 가상 머신의 상태는 현재 다음과 같이 보고됩니다.

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

API 버전 4에서는 이 상태 유형이 제거되어 enum 유형으로 교체되었습니다. 추가 세부 문자열이 필요한 경우 추가 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 활성 속성이 plugged 로 교체되었습니다. 이제 완전히 제거되었습니다.

디스크의 type 속성이 제거되었지만 XML 스키마에 보관되어 무시됩니다. 이제 완전히 제거되었습니다.

디스크 크기 속성이 오래 전에 provisioned_size 로 교체되었습니다. 이제 완전히 제거되었습니다.

버전 3.6 이전에는 API가 VM 엔티티의 placement_policy 요소를 사용하여 VM을 단일 호스트에 고정할 수 있었습니다.

PUT /ovirt-engine/api/vms/123

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

버전 3.6에서는 이 기능이 여러 호스트를 지원하도록 향상되었으며 이를 위해 새 hosts 요소가 추가되었습니다.

PUT /ovirt-engine/api/vms/123

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

이전 버전과의 호환성을 유지하기 위해 단일 호스트 요소가 보존되었습니다. 4.0에서 이 기능이 제거되었으므로 단일 호스트에 고정하더라도 애플리케이션이 hosts 요소를 사용해야 합니다.

허용 목록은 각 클러스터 수준에 따라 잠재적이며, 이전에 버전 요소에 추가되었지만 이전 버전과의 호환성을 위해 기능 요소에도 유지되었습니다.

4.0에서는 capabilities 서비스가 완전히 제거되었으며 새 clusterlevels 서비스로 교체됩니다. 클러스터 수준 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, Fiber Channel, iSCSI 등)에 연결하는 데 사용한 데이터 센터는 로컬 스토리지와 공유 스토리지를 사용하는 두 가지 유형만 있도록 변경되었습니다. 이를 나타내기 위해 새로운 로컬 요소가 도입되었으며, 이전의 호환성을 위해 이전 storage_type 이 보존되었습니다. 이 오래된 요소는 이제 완전히 제거되었습니다.

시간대를 나타내는 시간대 요소를 포함하는 데 사용되는 VM 리소스입니다. 이 요소에는 문자열만 사용할 수 있습니다.

<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>

이전 timezone 요소는 보존되었지만 이제 완전히 제거되었습니다.

guest_info 요소는 IP 주소 및 정규화된 호스트 이름과 같이 게스트 에이전트에서 수집한 정보를 저장하는 데 사용되었습니다. 이 정보는 다른 위치에서도 제공됩니다. 예를 들어 VM 리소스 내에서 IP 주소를 사용할 수 있습니다.

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>

또한 새로운 reported_devices 요소를 사용하여 NIC 리소스 내에서 다음을 수행합니다.

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>

또한 이 최신 reported_devices 요소는 여러 IP 주소, MAC 주소 등과 같은 보다 완전한 정보를 제공합니다.

이 중복을 제거하려면 guest_info 요소가 제거되었습니다.

정규화된 도메인 이름을 지원하기 위해 새 fqdn 요소가 VM 리소스에 추가되었습니다.

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>

이전에는 overcommit 요소가 해당 속성에 사용된 특성을 사용했습니다.

<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 address 요소가 속성에 사용된 특성을 사용했습니다.

<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 address 요소가 속성에 사용된 특성을 사용했습니다.

<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>

데이터베이스에서 검색하기 전에 호스트 데이터를 새로 고쳐 호스트 기능 및 장치를 다시 로드해야 함을 나타내는 강제 매트릭스 매개 변수를 지원하는 데 사용되는 호스트 검색 요청:

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 컬렉션을 도입하기 위해 변경되었습니다.

이전 type 속성, 이전 주소,사용자 이름 및 암호 요소 및 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의 다른 부분의 일반적인 관행은 래퍼 요소로 배열을 나타내는 것입니다. 이 경우 래퍼 요소의 이름은 부팅 이지만 부팅 시퀀스가 아닌 부팅 장치가 여러 개 있을 수 있으므로 이러한 점에서 의미가 없습니다. 이 불일치를 수정하려면 이 장치가 여러 장치를 포함할 수 있는 단일 부팅 요소로 교체되었습니다.

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>

이제 이 매개변수가 제거되었으며 새 clone 쿼리 매개변수로 교체됩니다.

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 및 vmpools 에 사용된 가상 머신의 풀을 나타내는 요소의 이름입니다. 복잡한 유형(이 경우 VmPool과VmPool ) 간의 일관된 일치를 유지하기 위해 vm_pool 및 vm_pool로 이름이 변경되었습니다.

바인딩되지 않은 논리 _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>

이제 이 매개변수가 제거되었으며 새로운 collapse_snapshots 쿼리 매개변수로 교체됩니다.

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

<action/>

호스트 스토리지 컬렉션에서는 storage 및 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>

이름이 해당 사용을 반영한 요소로 래핑된 소스 요소 컬렉션을 사용하여 보고하는 데 사용되는 난수 생성기 소스입니다.The random number generator sources used to be reported using a collection of source elements wrapped by an element with a name reflecting its use. 예를 들어 다음과 같이 보고하는 데 사용되는 클러스터의 필요한 난수 생성기 소스가 다음과 같습니다.

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는 나머지 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 를 사용하십시오.

관계는 태그를 설정할 때 intermedite 부모 태그를 사용하여 나타내는 데 사용되는 부모 태그, 즉 다른 태그 요소를 포함합니다.

<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

통계 종류 (gauge, counter 등)와 값의 유형을 나타내는 type 속성 (integer, string 등)을 사용하여 표시되는 통계입니다.

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

두 가지 모두에 type 개념을 사용하지 않도록 하려면 첫 번째가 kind 로 교체되었으며, kind 와 type 둘 다 이제 요소가 됩니다.

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

이전에는 가상 머신의 물리적 CPU 고정으로 가상을 지정하는 방법은 여러 vcpu_pin 요소를 사용하는 것이었습니다.

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

API의 다른 부분에서 공통의 관행을 준수하기 위해 래퍼 요소를 사용하도록 변경되었습니다.이 경우 vcpu_pins:

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

데이터 센터를 제거하는 작업은 force 매개 변수를 지원합니다. 선택적 작업 매개 변수를 지원하는 데 사용되는 DELETE 작업을 사용하려면 다음을 수행합니다.

DELETE /ovirt-engine/api/datacenters/123

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

이 선택적 action 매개변수는 선택적 매개변수로 교체되었습니다.

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

호스트를 제거하는 작업은 force 매개 변수를 지원합니다. 선택적 작업 매개 변수를 지원하는 데 사용되는 DELETE 작업을 사용하려면 다음을 수행합니다.

DELETE /ovirt-engine/api/host/123

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

이 선택적 action 매개변수는 선택적 매개변수로 교체되었습니다.

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

스토리지 도메인을 제거하는 작업은 force,destroy 및 host 매개 변수를 지원합니다. 이러한 매개변수는 스토리지 도메인의 표현을 본문으로 사용하여 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

스토리지 서버 연결을 제거하는 작업은 호스트 매개 변수를 지원합니다. 선택적 작업 매개 변수를 지원하는 데 사용되는 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 메서드를 사용합니다.

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

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

이 작업의 버전 4에서는 이 작업이 새 diskattachments 컬렉션으로 이동되었으며 요청 본문이 쿼리 매개 변수 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 을 삭제하여 엔터티를 제거하면 VM과 디스크 간의 관계를 제거할 수 있습니다. 즉, 이 작업은 VM에서 디스크를 분리해야 합니다. 이 작업은 더 이상 시스템에서 디스크를 완전히 제거할 수 없으며 이로 인해 사용자 오류가 발생하여 복구할 수 없는 결과가 발생했습니다. 디스크를 제거하려면 대신 /disk/456 API를 사용합니다.

DELETE /ovirt-engine/api/disks/456

가상 머신을 제거하는 작업은 force 매개 변수를 지원합니다. 선택적 작업 매개 변수를 지원하는 데 사용되는 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>

Enumerator는 점진적으로 API를 도입하고 있습니다. 현재 string이었던 일부 필드는 적절한 enum으로 교체됩니다. 이러한 필드 중 하나는 vm.type입니다. 그러나 이 필드는 스냅샷에 의해 상속되며 스냅샷 유형은 vm 유형과 다릅니다. 따라서 스냅샷 엔티티에 새 필드가 추가되었습니다. snapshot.snapshot_type.

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

더 이상 사용되지 않는 VM 엔티티의 이동 작업이 제거되었습니다. 대신 무차별 디스크를 이동할 수 있습니다.

API 버전 3에서 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에서 템플릿에는 연결된 디스크 의 모든 정보가 포함된 디스크 컬렉션이 있었습니다. 이러한 디스크 버전 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

디스크가 존재하지 않는 경우 다음 본문을 사용하여 만듭니다.With the following body if the disk doesn't exist and you want to create it:

<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>

이 경우 iscsi_target 과 같은 API 버전 4에서는 모두 다른 요소 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>