プールを管理する
この記事では、プールを管理するために実行できるいくつかのアクションについて説明します。
個々のホストを管理するには、「ホストの管理」(/ja-jp/xenserver/9/hosts-pools/manage-hosts)を参照してください。
リソースプールを作成する
リソースプールは、XenCenter®またはCLIを使用して作成できます。新しいホストがリソースプールに参加すると、参加するホストはローカルデータベースをプール全体のデータベースと同期し、プールから一部の設定を継承します。
-
VM、ローカル、およびリモートストレージ構成がプール全体のデータベースに追加されます。この構成は、ホストがプールに参加した後にリソースを明示的に共有しない限り、プール内の参加ホストに適用されます。
-
参加ホストは、プール内の既存の共有ストレージリポジトリを継承します。新しいホストが既存の共有ストレージに自動的にアクセスできるように、適切なPBDレコードが作成されます。
-
ネットワーク情報は、参加ホストに部分的に継承されます。NIC、VLAN、およびボンディングされたインターフェイスの構造に関する詳細はすべて継承されますが、ポリシーに関する情報は継承されません。再構成が必要なこのポリシー情報には、以下が含まれます。
-
管理NICのIPアドレスは、元の構成から保持されます。
-
管理インターフェイスの場所は、元の構成と同じままです。たとえば、他のプールホストがボンディングされたインターフェイス上に管理インターフェイスを持っている場合、参加ホストは参加後にそのボンディングに移行する必要があります。
-
専用ストレージNICは、XenCenterまたはCLIから参加ホストに再割り当てし、トラフィックを適切にルーティングするためにPBDを再接続する必要があります。これは、IPアドレスがプール参加操作の一部として割り当てられず、ストレージNICが正しく構成されている場合にのみ機能するためです。CLIからストレージNICを専用にする方法の詳細については、「ネットワークの管理」(/ja-jp/xenserver/9/networking/manage.html)を参照してください。
-
ホストをプールに追加する前に、管理インターフェイスを再構成し、物理NICに移動します。ホストがプールに参加した後、管理インターフェイスを再度再構成できます。
-
リソースプールを作成する前に、プールと参加ホストの要件を確認してください。詳細については、「リソースプール」(/ja-jp/xenserver/9/hosts-pools)を参照してください。
xe CLIを使用してホストをプールに追加する
-
参加を試みる前に、プールと参加ホストを同じレベルに更新してください。これを行うには、次のいずれかの方法があります。
-
参加するホストをプールと同じレベルに更新します。
- （推奨）参加するホストをプールと同期し、プールコーディネーターに保持されている更新ファイルから更新します。詳細については、「プールレベルへの更新」を参照してください。
- プールレベルに一致する更新バンドルをダウンロードし、それを使用して参加するホストを更新します。
-
プールと参加するホストの両方を最新レベルに更新します。
- ホストとプールを同じ更新チャネルと同期し、最新の更新を適用します。
- オフライン更新メカニズムを使用して、ホストとプールの両方に最新レベルの更新を適用します。
これらの更新方法の詳細については、「XenCenter を使用した更新の適用」または「xe CLI を使用した更新の適用」を参照してください。
-
-
プールに参加させたい XenServer® ホストでコンソールを開きます。
-
次のコマンドを発行して、XenServer ホストをプールに参加させます。
xe pool-join master-address=<address of pool coordinator> master-username=<administrator username> master-password=<password> <!--NeedCopy-->master-addressは、プールコーディネーターの完全修飾ドメイン名に設定する必要があります。passwordは、プールコーディネーターのインストール時に設定された管理者パスワードである必要があります。
注:
ホストをプールに参加させると、参加するホストの管理者パスワードは、プールコーディネーターの管理者パスワードと一致するように自動的に変更されます。
XenServer ホストは、デフォルトで名前のないプールに属しています。最初のリソースプールを作成するには、既存の名前のないプール名を変更します。タブ補完を使用して pool_uuid を見つけます。
xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->
異種混合リソースプールを作成する
XenServer は、異なるホストハードウェアをリソースプール（異種混合リソースプールとして知られています）に参加させることを可能にすることで、時間の経過とともに展開を拡張することを簡素化します。異種混合リソースプールは、Intel (FlexMigration) および AMD (Extended Migration) CPU のテクノロジーを使用して実現されており、CPU の「マスキング」または「レベリング」を提供します。CPU のマスキングおよびレベリング機能により、CPU を、実際とは異なるメーカー、モデル、または機能を提供しているかのように 見せる ように構成できます。この機能により、異なる CPU を持つホストのプールを作成しながら、ライブマイグレーションを安全にサポートできます。
注記:
異種混合プールに参加するXenServerホストのCPUは、プールにすでに存在するホストのCPUと同じベンダー（つまり、AMD、Intel）のものである必要があります。ただし、ホストはファミリー、モデル、またはステッピング番号のレベルで同じタイプである必要はありません。
XenServerは、異種混合プールのサポートを簡素化します。ホストは、基盤となるCPUタイプに関係なく（CPUが同じベンダーファミリーのものである限り）、既存のリソースプールに追加できるようになりました。プール機能セットは、以下のたびに動的に計算されます。
-
新しいホストがプールに参加する
-
プールメンバーがプールを離れる
-
プールメンバーが再起動後に再接続する
プール機能セットの変更は、現在プールで実行中のVMには影響しません。実行中のVMは、起動時に適用された機能セットを引き続き使用します。この機能セットは起動時に固定され、移行、一時停止、再開の操作全体で維持されます。能力の低いホストがプールに参加してプールレベルが低下した場合、実行中のVMは、新しく追加されたホストを除く、プール内の任意のホストに移行できます。VMをプール内またはプール間で別のホストに移動または移行すると、XenServerはVMの機能セットを宛先ホストの機能セットと比較します。機能セットに互換性がある場合、VMは移行を許可されます。これにより、VMは使用しているCPU機能に関係なく、プール内およびプール間で自由に移動できます。Workload Balancingを使用してVMを移行する最適な宛先ホストを選択する場合、互換性のない機能セットを持つホストは宛先ホストとして推奨されません。
共有ストレージの追加
このセクションでは、既存のNFSサーバー上に共有ストレージ（ストレージリポジトリとして表現される）を作成する方法の例を示します。サポートされている共有ストレージタイプの完全なリストについては、「ストレージ」を参照してください。
CLIを使用してNFS共有ストレージをリソースプールに追加するには
-
プール内の任意のXenServerホストでコンソールを開きます。
-
次のコマンドを発行して、server:/path にストレージリポジトリを作成します。
xe sr-create content-type=user type=nfs name-label="Example SR" shared=true \ device-config:server=server \ device-config:serverpath=path <!--NeedCopy-->device-config:serverはNFSサーバーのホスト名で、device-config:serverpathはNFSサーバー上のパスです。sharedがtrueに設定されているため、共有ストレージはプール内のすべてのXenServerホストに自動的に接続されます。後から参加するXenServerホストもストレージに接続されます。ストレージリポジトリのUniversally Unique Identifier (UUID)が画面に表示されます。 -
次のコマンドを実行して、プールのUUIDを見つけます。
xe pool-list <!--NeedCopy--> -
次のコマンドを使用して、共有ストレージをプール全体のデフォルトとして設定します。
xe pool-param-set uuid=pool_uuid default-SR=sr_uuid <!--NeedCopy-->共有ストレージがプール全体のデフォルトとして設定されているため、今後作成されるすべてのVMのディスクは、デフォルトで共有ストレージ上に作成されます。他の種類の共有ストレージの作成については、「SRの作成」を参照してください。
リソースプールからXenServerホストを削除する
注：
プールからXenServerホストを削除する前に、そのホストで実行されているすべてのVMをシャットダウンしてください。そうしないと、ホストを削除できないという警告が表示されることがあります。
ホストをプールから削除（排出）すると、マシンは再起動され、再初期化され、新規インストールと同様の状態になります。ローカルディスクに重要なデータがある場合は、XenServerホストをプールから排出しないでください。
CLIを使用してリソースプールからホストを削除するには
-
プール内の任意のホストでコンソールを開きます。
-
次のコマンドを実行して、ホストのUUIDを見つけます。
xe host-list <!--NeedCopy--> -
必要なホストをプールから排出します。
xe pool-eject host-uuid=host_uuid <!--NeedCopy-->XenServerホストは排出され、新規インストールされた状態になります。
警告：
ローカルディスクに重要なデータが保存されている場合は、リソースプールからホストを排出しないでください。ホストがプールから排出されると、すべてのデータが消去されます。このデータを保持したい場合は、XenCenterまたは
xe vm-copyCLIコマンドを使用して、VMをプールの共有ストレージにコピーしてください。
ローカルに保存されたVMを含むXenServerホストがプールから排出されると、VMはプールデータベースに存在します。ローカルに保存されたVMは、他のXenServerホストからも表示されます。VMは、関連付けられている仮想ディスクが、プール内の他のXenServerホストから見える共有ストレージを指すように変更されるか、または削除されるまで起動しません。したがって、プールに参加する際には、ローカルストレージを共有ストレージに移動することをお勧めします。共有ストレージに移動することで、個々のXenServerホストがデータ損失なしに排出（または物理的に故障）できるようになります。
注：
管理インターフェイスがタグ付きVLANネットワーク上にあるプールからホストが削除されると、マシンは再起動され、その管理インターフェイスは同じネットワーク上で利用可能になります。
プールシークレットをローテーションする
プールシークレットは、ホストがプールへのメンバーシップを証明できるように、プール内のホスト間で共有されるシークレットです。
プール管理者ロールを持つユーザーはこのシークレットを発見できるため、これらのユーザーのいずれかが組織を離れるか、プール管理者ロールを失った場合は、プールシークレットをローテーションすることをお勧めします。
XenCenterまたはxe CLIを使用して、プールシークレットをローテーションできます。
XenCenter
XenCenterを使用してプールのプールシークレットをローテーションするには、次の手順を実行します。
- リソースペインで、プールまたはプール内の任意のホストを選択します。
- プールメニューで、プールシークレットのローテーションを選択します。
プールシークレットをローテーションすると、ルートパスワードの変更も求められます。環境が侵害されたと思われるためにプールシークレットをローテーションした場合は、プールコーディネーターのルートパスワードも変更してください。詳細については、「パスワードの変更」を参照してください。
xe CLI
xe CLIを使用してプールシークレットをローテーションするには、プール内のホストで次のコマンドを実行します。
xe pool-secret-rotate
<!--NeedCopy-->
環境が侵害されたと思われるためにプールシークレットをローテーションした場合は、ルートパスワードも変更してください。詳細については、「パスワードの変更」を参照してください。
SSHアクセスの設定
XenServerプールへのSSHアクセスは、デフォルトで有効になっています。XenServerプールへのSSHアクセスを無効にする場合は、次のコマンドを実行します。
xe pool-disable-ssh pool=<pool_uuid_or_name_label>
<!--NeedCopy-->
このコマンドはSSHを無効にします。プールは新しいSSH接続を拒否しますが、既存のセッションは切断しません。
XenServerプールへのSSHアクセスを有効にするには、次のコマンドを実行します。
xe pool-enable-ssh pool=<pool_uuid_or_name_label>
<!--NeedCopy-->
現在のプールのSSH一時有効タイムアウト（秒）を設定するには：
xe pool-param-set uuid=<pool-uuid> ssh-enabled-timeout=<seconds>
<!--NeedCopy-->
タイムアウトパラメータはSSHサービスの期間を決定します。0に設定すると、SSHは無期限にアクティブなままになります。正の整数（秒）に設定すると、指定された期間後にSSHは自動的に無効になります。設定変更は、その後のアクティブなSSHセッションに即座に適用され、ユーザーがSSHを有効にするたびに適用されます。
注：
ssh-enabled-timeoutに設定できる最大値は172800秒（約2日）です。
現在のプールのSSHコンソールアイドルタイムアウト（秒）を設定するには
xe pool-param-set uuid=<pool-uuid> console-idle-timeout=<seconds>
<!--NeedCopy-->
VNCおよびSSHコンソール接続のアイドルセッションタイムアウトを、秒単位の非負の整数値で設定します。0はタイムアウトを無効にし（セッションは期限切れになりません）、正の値（例：3600）は指定された期間後にアイドルセッションを自動的に終了します。設定は、構成後に新しく作成されたコンソールセッションに適用されます。
現在のプールのSSH自動モードを設定するには
xe poolparam-set uuid=<pool-uuid> ssh-auto-mode=true
<!--NeedCopy-->
XAPIサービスの健全性ステータスに基づいて、SSHの自動管理を設定します。自動モードが有効な場合、SSHの有効化はXAPIステータスに従います。XAPIが正常な場合はSSHは無効になり、XAPIが異常な場合は有効になります。
自動モード有効 + ssh_enabled_timeout = 0: pool.enable_ssh を介した手動SSH有効化は、自動モードを永続的に無効にします。
自動モード有効 + ssh_enabled_timeout > 0: 手動SSH有効化は自動モードを一時的に無効にします。タイムアウトが期限切れになると、自動モードは元の設定に戻ります。（アクティブなSSHタイムアウト期間中にシステムが再起動した場合、元の自動モード設定は失われ、タイムアウト/復旧時に有効にリセットされます。）
これらのコマンドのいずれかにおけるプールパラメータの値には、プールセレクターを使用できます。詳細については、プールコマンド を参照してください。
XenServerプール内のすべてのプールのSSHアクセスを同時に管理できます。詳細については、プールのSSHアクセスを無効にする を参照してください。
プールの参加 / 削除の動作
-
参加 – サーバーがプールに参加すると、SSH設定（SSH有効タイムアウト、アイドルコンソールタイムアウト、自動モード）が継承されます。
-
削除 – サーバーがプールから削除されると、デフォルト設定が復元されます。
- XenServer 8.4: SSH 有効、自動モード無効
新しいSSH管理制御の定義
プールレベルで新しいXAPI API pool.set_ssh_auto_mode を設定してSSHを構成します
set_ssh_auto_mode: SSH自動モードを有効または無効にするように構成します。自動モードが有効な場合、SSHステータスはXAPIステータスに依存します。XAPIが正常な場合はSSHは無効になり、XAPIが異常な場合はSSHは有効になります。
ユーザーが自動モードを有効に設定し、現在のssh_enabled_timeoutが0の場合、pool.enable_ssh でSSHを有効にすると、自動モードは永続的に無効になります。
ユーザーがpool.set_auto_mode で自動モードを有効または無効に設定すると、これは「元の自動モード設定」と呼ばれます。現在のssh_enabled_timeout が正の数（例：1800秒）に設定されている場合、pool.enable_ssh でSSHを有効にすると、自動モードは一時的に無効になります。タイムアウト期間が終了すると、SSHは自動的に無効になり、自動モードは元の設定に復元されます。
ユーザーがssh_enabled_timeout を正の数（例：3600秒）に設定し、タイムアウト期間が終了する前にホストを再起動（またはXAPIを再起動）すると、タイムアウト期間が終了した時点で、再起動によって元の自動モード設定が失われるため、SSHは自動的に無効になり、自動モードはtrueに復元されます。
ssh_enabled_timeout を正の数（例：180秒）に構成し、その後XAPIが失敗した場合、タイムアウト期間が終了したときにXAPIが失敗状態のままであれば、XAPIが再起動するまでSSHは有効のままになります。XAPIの再起動時に、システムの再起動によって元の自動モード設定が失われるため、SSHは自動的に無効になり、自動モードはtrueに復元されます。
This command disables SSH. The hosts refuse new SSH connections, but do not disconnect any existing sessions.
To enable SSH access to all hosts in your pool, run the following command:
xe pool-enable-ssh
Both of these commands attempt to make a change on all hosts in the pool. If the command fails on one or more of the hosts in your pool, the command continues to run for all other hosts in the pool. The command returns a list of any hosts where the command fails.
You can manage the SSH access for an individual host. For more information, see [Disable SSH access for a host](/en-us/xenserver/9/hosts-pools/manage-hosts#configure-ssh-access).-->
## VNCコンソールセッションを構成する
デフォルトでは、XenServerはVMまたはホストごとの同時VNCコンソールセッション数を制限しません。プールレベルでアクセスを制限し、アイドルタイムアウトを適用できます。
各VMまたはホストコンソールを1つの同時セッションに制限するには：
xe pool-param-set uuid=
有効にすると、現在接続しているユーザーを特定するエラーとともに、追加の接続試行は拒否されます。現在の値をチェックするには：
xe pool-param-get uuid=
VM (domU) コンソールセッションのアイドルタイムアウトを設定するには：
xe pool-param-set uuid=
タイムアウトを無効にするには0 に設定します（セッションは期限切れになりません）。正の値を設定すると、指定された秒数後にアイドル状態のVMコンソールセッションが自動的に切断されます。
注記:
console-idle-timeoutパラメーターは、コントロール ドメイン (Dom0) コンソールと SSH セッションのアイドル タイムアウトを制御します。vm-console-idle-timeoutパラメーターは、VM コンソールにのみ適用されます。
XenServer プールで IGMP スヌーピングを有効にする
XenServer は、すべてのゲスト VM にマルチキャスト トラフィックを送信するため、ホスト デバイスが要求していないパケットを処理する必要が生じ、不要な負荷がかかります。IGMP スヌーピングを有効にすると、ローカル ネットワーク上のホストが明示的に参加していないマルチキャスト グループのトラフィックを受信するのを防ぎ、マルチキャストのパフォーマンスが向上します。IGMP スヌーピングは、IPTV のような帯域幅を大量に消費する IP マルチキャスト アプリケーションに特に役立ちます。
注記:
プールでこの機能を有効にする場合、物理スイッチのいずれかで IGMP クエリアを有効にする必要がある場合もあります。そうしないと、サブネットワーク内のマルチキャストがブロードキャストにフォールバックし、XenServer のパフォーマンスが低下する可能性があります。
IGMP v3 を実行しているプールでこの機能を有効にすると、VM の移行またはネットワーク ボンドのフェイルオーバーにより、IGMP バージョンが v2 に切り替わります。
GRE ネットワークでこの機能を有効にするには、ユーザーは GRE ネットワーク内に IGMP クエリアを設定する必要があります。または、物理ネットワークから GRE ネットワークに IGMP クエリ メッセージを転送することもできます。そうしないと、GRE ネットワーク内のマルチキャスト トラフィックがブロックされる可能性があります。
XenCenter または xe CLI を使用して、プールで IGMP スヌーピングを有効にできます。
XenCenter
- プール プロパティに移動します。
- ネットワーク オプションを選択します。ここで IGMP スヌーピングを有効または無効にできます。
xe CLI
-
プールの UUID を取得します。
xe pool-list -
プールでIGMPスヌーピングを有効/無効にする:
xe pool-param-set [uuid=pool-uuid] [igmp-snooping-enabled=true|false]
IGMPスヌーピングを有効にした後、xe CLIを使用してIGMPスヌーピングテーブルを表示できます。
IGMPスヌーピングテーブルを表示する
IGMPスヌーピングテーブルを表示するには、次のコマンドを使用します:
ovs-appctl mdb/show [bridge name]
注:
xe network-listを使用してブリッジ名を取得できます。これらのブリッジ名は、xenbr0、xenbr1、xenapi、またはxapi0のいずれかです。
これにより、4つの列を持つテーブルが出力されます:
- port: スイッチ (OVS) のポート。
- VLAN: トラフィックのVLAN ID。
- GROUP: ポートが要求したマルチキャストグループ。
- Age: このレコードの経過時間 (秒単位)。
GROUP がマルチキャストグループアドレスである場合、これは関連するスイッチポートでIGMPレポートメッセージが受信されたことを意味します。これは、マルチキャストグループのレシーバー (メンバー) がこのポートでリッスンしていることを意味します。
次に、2つのレコードを含む例を示します:
| ポート | VLAN | グループ | 経過時間 |
|---|---|---|---|
| 14 | 0 | 227.0.0.1 | 15 |
| 1 | 0 | クエリア | 24 |
最初のレコードは、マルチキャストグループ227.0.0.1に対してポート14でリッスンしているレシーバーがあることを示しています。Open vSwitchは、227.0.0.1マルチキャストグループ宛のトラフィックを、すべてのポートにブロードキャストするのではなく、このグループのリッスンポート（この例ではポート14）にのみ転送します。ポート14とグループ227.0.0.1をリンクするレコードは15秒前に作成されました。デフォルトでは、タイムアウト間隔は300秒です。これは、レコード追加後300秒間、スイッチがポート14でそれ以上のIGMPレポートメッセージを受信しない場合、そのレコードは期限切れとなり、テーブルから削除されることを意味します。
2番目のレコードでは、GROUPがquerierであり、関連するポートでIGMPクエリメッセージが受信されたことを意味します。クエリアは、どのネットワークノードがマルチキャストグループをリッスンしているかを判断するために、すべてのスイッチポートにブロードキャストされるIGMPクエリメッセージを定期的に送信します。IGMPクエリメッセージを受信すると、レシーバーはIGMPレポートメッセージで応答し、これによりレシーバーのマルチキャストレコードが更新され、期限切れが回避されます。
VLAN列は、レシーバー/クエリアが存在するVLANを示します。「0」はネイティブVLANを意味します。タグ付きVLANでマルチキャストを実行したい場合は、そのVLANにレコードがあることを確認してください。
注:
VLANシナリオの場合、ネットワークのVLAN IDと等しいVLAN列値を持つクエリアレコードが必要です。そうしないと、VLANネットワークでマルチキャストが機能しません。
XenServerプールで移行ストリーム圧縮を有効にする
VMのライブマイグレーション中、そのメモリはネットワークを使用して2つのホスト間でデータストリームとして転送されます。移行ストリーム圧縮機能はこのデータストリームを圧縮し、低速ネットワークでのメモリ転送を高速化します。この機能はデフォルトで無効になっていますが、XenCenterまたはxe CLIを使用して変更できます。詳細については、プールプロパティ - 詳細およびプールパラメータを参照してください。または、コマンドラインを使用してVMを移行する際に圧縮を有効にすることもできます。詳細については、VMコマンドのvm-migrateコマンドを参照してください。
リソースプールデータをエクスポートする
リソースデータのエクスポートオプションを使用すると、プールのリソースデータレポートを生成し、そのレポートを.xlsまたは.csvファイルにエクスポートできます。このレポートには、ホスト、ネットワーク、ストレージ、仮想マシン、VDI、GPUなど、プール内のさまざまなリソースに関する詳細情報が記載されています。この機能により、管理者はCPU、ストレージ、ネットワークなどのさまざまなワークロードに基づいてリソースを追跡、計画、割り当てることができます。
注:
リソースプールデータのエクスポートは、XenServer Premium Editionのお客様にご利用いただけます。
レポートに含まれるリソースのリストとさまざまな種類のリソースデータは次のとおりです。
サーバー:
- 名前
- プールコーディネーター
- UUID
- アドレス
- CPU使用率
- ネットワーク (平均/最大 KB)
- 使用済みメモリ
- ストレージ
- 稼働時間
- 説明
ネットワーク:
- 名前
- リンクステータス
- MAC
- MTU
- VLAN
- タイプ
- 場所
VDI:
- 名前
- タイプ
- UUID
- サイズ
- ストレージ
- 説明
ストレージ:
- 名前
- タイプ
- UUID
- サイズ
- 場所
- 説明
VM:
- 名前
- 電源状態
- 実行中
- アドレス
- MAC
- NIC
- オペレーティングシステム
- ストレージ
- 使用済みメモリ
- CPU使用率
- UUID
- 稼働時間
- テンプレート
- 説明
GPU:
- 名前
- サーバー
- PCI バスパス
- UUID
- 電力使用量
- 温度
- 使用済みメモリ
- コンピューター使用率
注:
GPUに関する情報は、XenServerホストにGPUが接続されている場合にのみ利用可能です。
リソースデータをエクスポートするには
-
XenCenterのナビゲーションペインで、インフラストラクチャを選択し、プールを選択します。
-
プールメニューを選択し、リソースデータのエクスポートを選択します。
-
レポートを保存したい場所を参照し、保存をクリックします。