付録B API バージョン 4 の変更点

YAML のサポートは完全に削除されました。

次の XML スキーマ複合型の名前が変更されました。

現在、さまざまなオブジェクトのステータスは、ステータスを説明する state 文字列と追加の詳細を示す別の detail 文字列を含む Status タイプを使用して報告されます。たとえば、IO エラーが原因で一時停止している仮想マシンのステータスは、現在次のように報告されています。

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

API のバージョン 4 では、この Status 型が削除され、enum 型に置き換えられました。追加の 詳細 文字列が必要な場合は、追加の status_detail 属性に置き換えられています。たとえば、同じ仮想マシンのステータスは次のように報告されます。

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

NIC network および 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>

古い要素とその意味は後方互換性のために保持されていましたが、現在は完全に削除されています。

network 要素は initialization 要素でまだ使用されているため、XML スキーマから削除されていませんが、NIC の作成または更新時に指定された場合は完全に無視されることに注意してください。

NIC の active プロパティーは、しばらく前に plugged に置き換えられました。現在は完全に削除されています。

ディスクの type プロパティーは削除されましたが、XML スキーマに保持され、無視されます。現在は完全に削除されています。

ディスク size プロパティーは、だいぶ前に 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>

後方互換性を維持するために、単一の host 要素が保持されました。4.0 ではこれが削除されたため、単一のホストにピニングする場合でも、アプリケーションは hosts 要素を使用する必要があります。

permits のリストは、クラスターレベルごとに異なる可能性があり、かなり前に version 要素に追加されましたが、後方互換性のために、capabilities 要素にも保持されています。

4.0 では、capabilities サービスが完全に削除され、新しい clusterlevels サービスに置き換えられました。クラスターレベル 4.0 でサポートされる permits を見つけるには、以下のようなリクエストを使用する必要があります。

GET /ovirt-engine/api/clusterlevels/4.0

結果は、そのクラスターレベルに固有の情報、特にサポートされている一連の permits を含むドキュメントになります。

<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 など) に関連付けられていましたが、しばらくして変更され、ローカルストレージと共有ストレージの 2 つのタイプのみになりました。これを示すために新しい local 要素が導入され、古い storage_type 要素は後方互換性のために保持されました。この古い要素は完全に削除されました。

タイムゾーンを表す timezone 要素を格納するために使用される 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 アドレスや完全修飾ホスト名など、ゲストエージェントによって収集された情報を保持するために使用されていました。この情報は他の場所でも入手できます。たとえば、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 リソース内で、新しい reported_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>

さらに、この新しい 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 要素には、CPU のタイプを示す id 属性がありました。

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

これは、id 属性が不透明な識別子に使用される API モデルの残りの要素と矛盾しています。この 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 ピン要素はそのプロパティーに属性を使用していました。

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

電源管理 type プロパティーは属性として表されていました。

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

これは、API の一般的な慣行に反しています。内部要素に置き換えられました。

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

以前は、電源管理エージェントの option 要素は、そのプロパティーに属性を使用していました。

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

オペレーティングシステム type プロパティーは属性として表されていました。

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

これは、API の一般的な慣行に反しています。内部要素に置き換えられました。

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

データベースからデータを取得する前に、ホストのデータを更新する (VDSM を呼び出してホストの機能とデバイスをリロードする) 必要があることを示す force マトリクスパラメーターをサポートするために使用されるホストを取得するリクエスト。

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

この force パラメーターは、ホストの refresh アクションに取って代わられましたが、後方互換性のために保持されています。現在は完全に削除されています。この機能を必要とするアプリケーションは、2 つのリクエストを実行する必要があります。1 つ目は、ホストをリフレッシュするためのリクエストです。

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

<action/>

2 つ目は、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 属性、古い address 要素、username 要素、password 要素、および power_management の内部に直接ある agents 要素は、後方互換性のために保持されました。これらの要素はすべて完全に削除されたため、電源管理エージェントをクエリーまたは変更する方法は、現時点では /hosts/123/fenceagents サブコレクションのみになります。

これまで、仮想マシンの起動時にブートシーケンスを指定する方法は、それぞれが dev 要素を含む複数の boot 要素を使用することでした。たとえば、仮想マシンが最初に CDROM から起動し、次にハードディスクから起動するように指定するには、以下のリクエストが使用されました。

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

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

API の他の部分での一般的な方法は、配列をラッパー要素で表すことです。その場合、そのラッパー要素に boots という名前を付けることができますが、ここで複数の値を指定できるのはブートシーケンスではなくブートデバイスであるため、あまり意味がありません。この矛盾を修正するために、これは複数のデバイスを含むことができる単一の boot 要素に置き換えられました。

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 と VmPools) と要素の名前間での対応を統一するために、vm_pool と vm_pools に改名されました。

ボリュームグループの一部である論理ユニットは、無制限数の 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>

これは削除され、新しい 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>

乱数ジェネレーターのソースは、その使用を反映した名前の要素でラップされた source 要素のコレクションを使用して報告されていました。たとえば、従来は、クラスターの必要な乱数ジェネレーターソースは以下のように報告されていました。

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>

source だけでなく、required_rng_source と supported_rng_source を使用していることに注意してください。

タグとその親タグの間の関係は、中間の parent タグを使用して表されていましたが、これには別の tag 要素が含まれていました。

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

この構造体は単純化され、1 つの parent 要素のみが使用されるようになりました。

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

後方互換性を維持するために、古い policy 要素および thresholds 要素が保持されました。クラスター内に組み込まれたスケジューリングポリシー表現も保持されました。これらはすべて完全に削除されたため、クラスターを取得、作成、または更新するときにスケジューリングポリシーを参照する唯一の方法は、識別子を使用して既存のポリシーを参照することです。たとえば、クラスターを取得する場合、id (および href) のみが入力されます。

GET /ovirt-engine/api/clusters/123

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

クラスターを作成または更新する場合、id のみが受け入れられます。

これらの要素は、実際にはブリックのコレクションの表現の一部ではなく、ブリックを追加および削除する操作のパラメーターです。これらは削除され、新しい replica_count および strip_count パラメーターに置き換えられました。

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

DELETE .../bricks?replica_count=3

統計は、統計の種類 (ゲージ、カウンターなど) を示す type 要素と、値の型 (整数、文字列など) を示す type 属性を使用して表されていました。

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

両方の 型 概念の使用を避けるために、最初のものが 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>

このオプションのアクションパラメーターは、オプションのパラメーターに置き換えられました。

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

ホストを削除する操作では、force パラメーターがサポートされています。これを使用するために、DELETE オペレーションはオプションのアクションパラメーターをサポートしていました。

DELETE /ovirt-engine/api/host/123

<action>
  <force>true</force>
</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

ストレージサーバー接続を削除する操作は、host パラメーターをサポートします。これを使用するには、オプションのアクションパラメーターをサポートするために使用される DELETE メソッドを使用します。

DELETE /ovirt-engine/api/storageconnections/123

<action>
  <host id="...">
    <name>...</name>
  </host>
</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>

API のバージョン 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>

このオプションのアクションパラメーターは、オプションのクエリーパラメーターに置き換えられました。

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

複数の Gluster ブリックを削除する操作は、DELETE メソッドを使用して実装され、ブリックのリストをリクエストの本文として渡します。

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>

Enum は徐々に API に導入されています。これまで文字列だった一部のフィールドは、適切な列挙型に置き換えられます。そのようなフィールドの 1 つが vm.type です。ただし、このフィールドはスナップショットによって継承され、スナップショットタイプは vm タイプとは異なります。そのため、新しいフィールド (snapshot.snapshot_type) がスナップショットエンティティーに追加されました。

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

VM エンティティーの非推奨の move アクションは削除されました。代わりに、個々のディスクを移動できます。

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 で使用される仕様メカニズムでは、これを表現することはできません。それを表現できるようにするために、属性は in_sync を囲む network_attachment に移動されました。

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

最上位の capabilities コレクションは、新しい clusterlevels コレクションに置き換えられました。この新しいコレクションには、各クラスターレベルで使用可能な 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>

バージョン 3 の API 仮想マシンとテンプレートには、接続されているディスクのすべての情報を含む disks コレクションがありました。API のバージョン 4 では、これらの disks コレクションは削除され、新しい diskattachments コレクションに置き換えられました。このコレクションには、ディスクへの参照と、ディスクとディスクが接続されている仮想マシンまたはテンプレートとの関係に固有の属性のみ (interface と bootable) が含まれます。

たとえば、仮想マシンに接続されているディスクを見つけるには、以下のようなリクエストを送信します。

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 属性には、すべての用途に対して 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) でラップされます。したがって、同じリクエストは次のようになります。

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>