6.108. ホスト
ホストを管理するサービス
名前 | Summary |
---|---|
| 仮想マシンを実行するなど、使用するホストをアクティベートします。 |
| 仮想化環境で使用するために事前にインストールされたハイパーバイザーホストを承認します。 |
| ネットワーク設定を正常としてマークし、ホスト内にその設定を持続させます。 |
| 指定したホストのネットワーク設定を現在のホストにコピーします。 |
| ホストを無効にして、メンテナンスタスクを実行します。 |
| イニシエーターの詳細を使用して、ホスト上の iSCSI ターゲットを検出します。 |
| ホストの証明書を登録します。 |
| ホストの電源管理デバイスを制御します。 |
| ホストを Storage Pool Manager (SPM) として手動で設定します。 |
| ホストの詳細を取得します。 |
| 最新バージョンの VDSM と関連ソフトウェアをホストにインストールします。 |
| このメソッドは、Engine バージョン 4 以降非推奨となりました。 |
| ターゲットの詳細を使用して、ホストの iSCSI ターゲットにログインします。 |
| ホストデバイスと機能を更新します。 |
| システムからホストを削除します。 |
| この方法は、ホストのネットワークインターフェイスの設定を変更するために使用されます。 |
| ホスト上の全ネットワークを同期するには、以下のような要求を送信します。 [source] ---- POST /ovirt-engine/api/hosts/123/syncallnetworks ---- リクエスト本文は以下のようになります。 [source,xml] ---- <action/> ---- |
| 設定にインポートする候補であるブロックストレージドメインを検出します。 |
| ホストのプロパティーを更新します。 |
| ホストで VDSM および選択したソフトウェアをアップグレードします。 |
| ホストにアップグレードが利用可能であるかどうかを確認します。 |
6.108.1. activate POST
仮想マシンを実行するなど、使用するホストをアクティベートします。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | アクティベーションを非同期で実行する必要があるかどうかを示します。 |
6.108.2. approve POST
仮想化環境で使用するために事前にインストールされたハイパーバイザーホストを承認します。
このアクションは、このホストのターゲットクラスターを定義するためのオプションのクラスター要素も受け入れます。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | 'true' に設定すると、このホストは承認の完了後にアクティベートされます。 | |
| In | 承認を非同期的に実行するかどうかを指定します。 | |
| In | ホストが承認後に追加されるクラスター。 | |
| In | 承認するホスト。 | |
| In | インストールに成功した後にホストを再起動するかどうかを示します。 |
6.108.2.1. activate
'true' に設定すると、このホストは承認の完了後にアクティベートされます。'false' に設定すると、ホストは承認後も 'maintenance' ステータスのままになります。このパラメーターがない場合は 'true' と解釈されます。これは、望ましいデフォルトの動作が承認後にホストをアクティブ化するからです。
6.108.2.2. reboot
インストールに成功した後にホストを再起動するかどうかを示します。デフォルト値は true
です。
6.108.3. commitnetconfig POST
ネットワーク設定を正常としてマークし、ホスト内にその設定を持続させます。
API ユーザーは、ネットワーク設定をコミットして、ホストネットワークインターフェイスのアタッチメントまたはデタッチメントを永続化するか、ボンディングされたインターフェイスの作成と削除を永続化します。
ネットワーク設定は、設定の変更によってホスト接続が失われないことをエンジンが確認した後にのみ、コミットされます。ホストの接続が失われた場合、ホストを再起動する必要があり、自動的に以前のネットワーク設定に戻ります。
たとえば、ID が 123
のホストのネットワーク設定をコミットするには、次のようなリクエストを送信します。
POST /ovirt-engine/api/hosts/123/commitnetconfig
リクエスト本文は以下のようになります。
<action/>
Red Hat Virtualization Manager 4.3 以降、setupnetworks リクエストで commit_on_success
を指定することもできます。この場合、セットアップが完了し、{hypervisor-name} と Red Hat Virtualization Manager 間の接続が再確立され、個別の commitnetconfig リクエストを待つことなく、新しい設定が {hypervisor-name} に自動的に保存されます。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | アクションを非同期で実行する必要があるかどうかを示します。 |
6.108.4. copyhostnetworks POST
指定したホストのネットワーク設定を現在のホストにコピーします。
ソースホストに存在しないネットワークアタッチメントは、コピー操作によってターゲットホストから消去されます。
別のホストからネットワークをコピーするには、次のようなリクエストを送信します。
POST /ovirt-engine/api/hosts/123/copyhostnetworks
リクエスト本文は以下のようになります。
<action> <source_host id="456"/> </action>
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | アクションを非同期で実行する必要があるかどうかを示します。 | |
| In | ネットワークのコピー元となるホスト。 |
6.108.5. deactivate POST
ホストを無効にして、メンテナンスタスクを実行します。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | 非アクティブ化を非同期で実行する必要があるかどうかを示します。 | |
| In | ||
| In | ホストの非アクティブ化の一環として gluster サービスを停止する必要があるかどうかを示します。 |
6.108.5.1. stop_gluster_service
ホストの非アクティブ化の一環として gluster サービスを停止する必要があるかどうかを示します。gluster ホストのメンテナンス操作中に使用できます。この変数のデフォルト値は false
です。
6.108.6. discoveriscsi POST
イニシエーターの詳細を使用して、ホスト上の iSCSI ターゲットを検出します。検出されたデータを含む IscsiDetails オブジェクトのリストを返します。
たとえば、myiscsi.example.com
で利用可能な iSCSI ターゲットをホスト 123
から検出するには、次のようなリクエストを送信します。
POST /ovirt-engine/api/hosts/123/discoveriscsi
リクエスト本文は以下のようになります。
<action> <iscsi> <address>myiscsi.example.com</address> </iscsi> </action>
結果は以下のようになります。
<discovered_targets> <iscsi_details> <address>10.35.1.72</address> <port>3260</port> <portal>10.35.1.72:3260,1</portal> <target>iqn.2015-08.com.tgt:444</target> </iscsi_details> </discovered_targets>
このメソッドを使用して、iSCSI ターゲットを検出する場合には、FQDN または IP アドレスを使用できますが、REST API メソッドを使用してログインするには、検出された iSCSI ターゲットの詳細を使用する必要があります。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | 検出を非同期で実行する必要があるかどうかを示します。 | |
| Out | すべての接続情報を含む検出されたターゲット。 | |
| In | ターゲット iSCSI デバイス。 |
6.108.7. enrollcertificate POST
ホストの証明書を登録します。有効期限が近づいている、またはすでに有効期限が切れているという警告が表示された場合に便利です。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | 登録を非同期で実行する必要があるかどうかを示します。 |
6.108.8. fence POST
ホストの電源管理デバイスを制御します。
たとえば、ホストを起動するとします。これは、以下の方法で実行できます。
#!/bin/sh -ex url="https://engine.example.com/ovirt-engine/api" user="admin@internal" password="..." curl \ --verbose \ --cacert /etc/pki/ovirt-engine/ca.pem \ --user "${user}:${password}" \ --request POST \ --header "Version: 4" \ --header "Content-Type: application/xml" \ --header "Accept: application/xml" \ --data ' <action> <fence_type>start</fence_type> </action> ' \ "${url}/hosts/123/fence"
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | フェンシングを非同期で実行する必要があるかどうかを示します。 | |
| In | ||
| In | 再起動後にホストをメンテナンスする必要があるかどうかを示します。 | |
| Out |
6.108.9. forceselectspm POST
ホストを Storage Pool Manager (SPM) として手動で設定します。
POST /ovirt-engine/api/hosts/123/forceselectspm
リクエスト本文は以下のようになります。
<action/>
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | アクションを非同期で実行する必要があるかどうかを示します。 |
6.108.10. get GET
ホストの詳細を取得します。
GET /ovirt-engine/api/hosts/123
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | ホストのすべての属性を応答に含めるかどうかを指定します。 | |
| In | ユーザーのパーミッションにしたがって、結果をフィルターする必要があるかどうかを示します。 | |
| In | たどる 必要のある内部リンクを指定します。 | |
| Out | クエリーされたホスト。 |
6.108.10.1. all_content
ホストのすべての属性を応答に含めるかどうかを指定します。
デフォルトでは、以下の属性が除外されます。
-
hosted_engine
たとえば、ホスト '123' の完全な表現を取得するには、以下を実行します。
GET /ovirt-engine/api/hosts/123?all_content=true
これらの属性は、取得後にパフォーマンスに影響を及ぼすため、デフォルトでは含まれていません。これらはめったに使用されず、データベースへの追加のクエリーを必要とします。このパラメーターは、特に必要な場合にのみ注意して使用してください。
6.108.10.2. follow
たどる 必要のある内部リンクを指定します。これらのリンクで参照されるオブジェクトは、現在の要求の一部としてフェッチされます。詳細は、こちら を参照してください。
6.108.11. install POST
最新バージョンの VDSM と関連ソフトウェアをホストにインストールします。
このアクションは、ホストをエンジンに追加するときに実行されるホスト上のすべての設定ステップ (kdump 設定、ホスト型エンジンのデプロイ、カーネルオプションの変更など) も実行します。
ホストタイプは、アクションの追加パラメーターを定義します。
curl
と JSON を使用してホストをインストールする例、プレーン:
curl \ --verbose \ --cacert /etc/pki/ovirt-engine/ca.pem \ --request PUT \ --header "Content-Type: application/json" \ --header "Accept: application/json" \ --header "Version: 4" \ --user "admin@internal:..." \ --data ' { "root_password": "myrootpassword" } ' \ "https://engine.example.com/ovirt-engine/api/hosts/123"
ホスト型エンジンコンポーネントで curl
と JSON を使用してホストをインストールする例:
curl \ curl \ --verbose \ --cacert /etc/pki/ovirt-engine/ca.pem \ --request PUT \ --header "Content-Type: application/json" \ --header "Accept: application/json" \ --header "Version: 4" \ --user "admin@internal:..." \ --data ' { "root_password": "myrootpassword" "deploy_hosted_engine" : "true" } ' \ "https://engine.example.com/ovirt-engine/api/hosts/123"
エンジンのバージョン 4.1.2 以降、ホストが再インストールされると、デフォルトでホストファイアウォールの定義をオーバーライドするようになりました。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | 'true' に設定すると、このホストはインストールの完了後にアクティブになります。 | |
| In | インストールを非同期で実行する必要があるかどうかを示します。 | |
| In |
| |
| In |
| |
| In | {hypervisor-name} をインストールする場合、ISO イメージファイルが必要です。 | |
| In | インストールに成功した後にホストを再起動するかどうかを示します。 | |
| In |
SSH 経由でホストに接続するために使用される | |
| In | ホストへの接続に使用される SSH の詳細。 | |
| In |
|
6.108.11.1. activate
'true' に設定すると、このホストはインストールの完了後にアクティブになります。'false' に設定すると、ホストはインストール後も 'maintenance' ステータスのままになります。このパラメーターがない場合は 'true' と解釈されます。これは、望ましいデフォルトの動作がインストール後にホストをアクティブ化するからです。
6.108.11.2. deploy_hosted_engine
true
に設定すると、このホストは自己ホスト型エンジンコンポーネントもデプロイします。欠落している値は true
、つまりデプロイとして扱われます。このパラメーターを省略すると、false
を意味し、セルフホスト型エンジン領域での操作は一切行われません。
6.108.11.3. reboot
インストールに成功した後にホストを再起動するかどうかを示します。デフォルト値は true
です。
6.108.11.4. undeploy_hosted_engine
true
に設定すると、このホストは自己ホスト型エンジンコンポーネントをアンデプロイし、このホストは高可用性クラスターの一部として機能しなくなります。欠落している値は true
、つまりアンデプロイとして扱われます。このパラメーターを省略すると、false
を意味し、セルフホスト型エンジン領域での操作は一切行われません。
6.108.12. iscsidiscover POST
このメソッドは、Engine バージョン 4.4.6 以降非推奨となりました。代わりに DiscoverIscsi を使用する必要があります。
イニシエーターの詳細を使用して、ホスト上の iSCSI ターゲットを検出します。検出されたデータを含む文字列の配列を返します。
たとえば、myiscsi.example.com
で利用可能な iSCSI ターゲットをホスト 123
から検出するには、次のようなリクエストを送信します。
POST /ovirt-engine/api/hosts/123/iscsidiscover
リクエスト本文は以下のようになります。
<action> <iscsi> <address>myiscsi.example.com</address> </iscsi> </action>
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | 検出を非同期で実行する必要があるかどうかを示します。 | |
| In | ターゲット iSCSI デバイス。 | |
| Out | iSCSI ターゲット。 |
6.108.12.1. iscsi_targets
iSCSI ターゲット。*
6.108.13. iscsilogin POST
ターゲットの詳細を使用して、ホストの iSCSI ターゲットにログインします。
このメソッドを使用してログインする場合は、discoveriscsi メソッドで検出された iSCSI ターゲットの詳細を使用する必要があります。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | ログインを非同期で実行する必要があるかどうかを示します。 | |
| In | ターゲット iSCSI デバイス。 |
6.108.14. refresh POST
ホストデバイスと機能を更新します。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | リフレッシュを非同期で実行する必要があるかどうかを示します。 |
6.108.15. remove DELETE
システムからホストを削除します。
#!/bin/sh -ex url="https://engine.example.com/ovirt-engine/api" user="admin@internal" password="..." curl \ --verbose \ --cacert /etc/pki/ovirt-engine/ca.pem \ --user "${user}:${password}" \ --request DELETE \ --header "Version: 4" \ "${url}/hosts/1ff7a191-2f3b-4eff-812b-9f91a30c3acc"
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | 削除を非同期的に実行するかどうかを指定します。 | |
| In | ホストが応答しない場合、またはホストが Gluster Storage クラスターの一部であり、ボリュームブリックがある場合でも、ホストを削除する必要があることを示します。 |
6.108.16. setupnetworks POST
この方法は、ホストのネットワークインターフェイスの設定を変更するために使用されます。
たとえば、3 つのネットワークインターフェイス eth0
、eth1
、および eth2
を持つホストがあり、eth0
と eth1
を使用して新しいボンディングを設定し、その上に VLAN を配置するとします。簡単なシェルスクリプトと curl
コマンドライン HTTP クライアントを使用すると、以下のように実行できます。
#!/bin/sh -ex url="https://engine.example.com/ovirt-engine/api" user="admin@internal" password="..." curl \ --verbose \ --cacert /etc/pki/ovirt-engine/ca.pem \ --user "${user}:${password}" \ --request POST \ --header "Version: 4" \ --header "Content-Type: application/xml" \ --header "Accept: application/xml" \ --data ' <action> <modified_bonds> <host_nic> <name>bond0</name> <bonding> <options> <option> <name>mode</name> <value>4</value> </option> <option> <name>miimon</name> <value>100</value> </option> </options> <slaves> <host_nic> <name>eth1</name> </host_nic> <host_nic> <name>eth2</name> </host_nic> </slaves> </bonding> </host_nic> </modified_bonds> <modified_network_attachments> <network_attachment> <network> <name>myvlan</name> </network> <host_nic> <name>bond0</name> </host_nic> <ip_address_assignments> <ip_address_assignment> <assignment_method>static</assignment_method> <ip> <address>192.168.122.10</address> <netmask>255.255.255.0</netmask> </ip> </ip_address_assignment> </ip_address_assignments> <dns_resolver_configuration> <name_servers> <name_server>1.1.1.1</name_server> <name_server>2.2.2.2</name_server> </name_servers> </dns_resolver_configuration> </network_attachment> </modified_network_attachments> </action> ' \ "${url}/hosts/1ff7a191-2f3b-4eff-812b-9f91a30c3acc/setupnetworks"
これは、API のバージョン 4 で有効です。以前のバージョンでは、一部の要素は XML 要素ではなく XML 属性として表されていました。特に、options
と ip
要素は次のように表されました。
<options name="mode" value="4"/> <options name="miimon" value="100"/> <ip address="192.168.122.10" netmask="255.255.255.0"/>
次のコードで Python SDK を使用しても、同じことができます。
# Find the service that manages the collection of hosts: hosts_service = connection.system_service().hosts_service() # Find the host: host = hosts_service.list(search='name=myhost')[0] # Find the service that manages the host: host_service = hosts_service.host_service(host.id) # Configure the network adding a bond with two slaves and attaching it to a # network with an static IP address: host_service.setup_networks( modified_bonds=[ types.HostNic( name='bond0', bonding=types.Bonding( options=[ types.Option( name='mode', value='4', ), types.Option( name='miimon', value='100', ), ], slaves=[ types.HostNic( name='eth1', ), types.HostNic( name='eth2', ), ], ), ), ], modified_network_attachments=[ types.NetworkAttachment( network=types.Network( name='myvlan', ), host_nic=types.HostNic( name='bond0', ), ip_address_assignments=[ types.IpAddressAssignment( assignment_method=types.BootProtocol.STATIC, ip=types.Ip( address='192.168.122.10', netmask='255.255.255.0', ), ), ], dns_resolver_configuration=types.DnsResolverConfiguration( name_servers=[ '1.1.1.1', '2.2.2.2', ], ), ), ], ) # After modifying the network configuration it is very important to make it # persistent: host_service.commit_net_config()
ネットワーク設定がホストに保存されていること、およびホストの再起動時に適用されることを確認するには、commitnetconfig を呼び出すことを忘れないでください。
Red Hat Virtualization Manager 4.3 以降、setupnetworks リクエストで commit_on_success
を指定することもできます。この場合、セットアップが完了し、{hypervisor-name} と Red Hat Virtualization Manager 間の接続が再確立され、個別の commitnetconfig リクエストを待つことなく、新しい設定が {hypervisor-name} に自動的に保存されます。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | アクションを非同期で実行する必要があるかどうかを示します。 | |
| In | ||
| In | セットアップが完了し、{hypervisor-name} と Red Hat Virtualization Manager 間の接続が再確立され、個別の commitnetconfig リクエストを待つことなく、設定を {hypervisor-name} に自動的に保存するかどうかを指定します。 | |
| In | ||
| In | ||
| In | ||
| In | ||
| In | ||
| In | ||
| In | ||
| In | 同期されるネットワーク接続のリスト。 |
6.108.16.1. commit_on_success
セットアップが完了し、{hypervisor-name} と Red Hat Virtualization Manager 間の接続が再確立され、個別の commitnetconfig リクエストを待つことなく、設定を {hypervisor-name} に自動的に保存するかどうかを指定します。デフォルト値は false
です。これは、設定が自動的に保存されないことを意味します。
6.108.17. syncallnetworks POST
ホスト上の全ネットワークを同期するには、以下のような要求を送信します。
POST /ovirt-engine/api/hosts/123/syncallnetworks
リクエスト本文は以下のようになります。
<action/>
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | アクションを非同期で実行する必要があるかどうかを示します。 |
6.108.18. unregisteredstoragedomainsdiscover POST
設定にインポートする候補であるブロックストレージドメインを検出します。FCP の場合は、引数は必要ありません。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | 検出を非同期で実行する必要があるかどうかを示します。 | |
| In | ||
| Out |
6.108.19. update PUT
ホストのプロパティーを更新します。
たとえば、ホストのカーネルコマンドラインを更新するには、以下のようなリクエストを送信します。
PUT /ovirt-engine/api/hosts/123
リクエスト本文は以下のようになります。
<host> <os> <custom_kernel_cmdline>vfio_iommu_type1.allow_unsafe_interrupts=1</custom_kernel_cmdline> </os> </host>
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | 更新を非同期的に実行するかどうかを指定します。 | |
| In/Out |
6.108.20. upgrade POST
ホストで VDSM および選択したソフトウェアをアップグレードします。
名前 | 型 | 方向 | Summary |
---|---|---|---|
| In | アップグレードを非同期で実行する必要があるかどうかを示します。 | |
| In | Vintage Node はサポートされなくなり、非推奨になったため、このプロパティーは関連しなくなりました。 | |
| In | アップグレード後にホストを再起動する必要があるかどうかを示します。 | |
| In | アップグレードのタイムアウト。 |
6.108.20.1. reboot
アップグレード後にホストを再起動する必要があるかどうかを示します。デフォルトでは、ホストは再起動されます。
{hypervisor-name} の場合、このパラメーターは無視されます。{hypervisor-name} は、アップグレード後に常に再起動されます。
6.108.20.2. timeout
アップグレードのタイムアウト。
アップグレードが完了するまでの最大待機時間 (分単位)。デフォルト値は ANSIBLE_PLAYBOOK_EXEC_DEFAULT_TIMEOUT
設定オプションで指定します。
6.108.21. upgradecheck POST
ホストにアップグレードが利用可能であるかどうかを確認します。利用可能なアップグレードがある場合は、管理ポータルのホストステータスアイコンの横にアイコンが表示されます。また、アップグレードの可否を示す監査ログメッセージも追加されます。アップグレードは、webadmin から、または アップグレード ホストアクションを使用して開始できます。