Citrix Hypervisor

ホストとリソースプール

April 23, 2024

寄稿者:

ここでは、xeコマンドラインインターフェイス（CLI）の使用例を基に、リソースプールの作成方法について説明します。シンプルなNFSベースの共有ストレージ構成を使用した例を挙げて、仮想マシンの管理について説明します。また、物理ノードの障害に対処する手順についても説明します。

Citrix Hypervisorサーバーとリソースプールの概要

「リソースプール」（または単に「プール」）は、複数のCitrix Hypervisorサーバーで構成され、仮想マシンをホストする単一の管理対象としてグループ化したものです。リソースプールに共有ストレージを接続すると、十分なメモリを備えた任意のCitrix Hypervisorサーバー上で仮想マシンを起動できるようになります。さらに、最小限のダウンタイムで、実行中の仮想マシンを別のCitrix Hypervisorサーバー上に動的に移行することもできます（「ライブマイグレーション」とも呼ばれます）。Citrix Hypervisorサーバーでハードウェア障害が生じた場合、管理者は、そのサーバー上の仮想マシンを、同じリソースプール内の別のCitrix Hypervisorサーバー上で再起動させることができます。リソースプールの高可用性機能を有効にすると、ホストに障害が発生した場合に、そのホスト上の仮想マシンが自動的に移行されるようになります。リソースプールでは、最大で64台のホストがサポートされます。ただし、この制限は強制的なものではありません。

リソースプールには、プールマスターと呼ばれる1つの物理ノードが常に存在します。プールマスターだけが、XenCenterおよびCitrix Hypervisorコマンドラインインターフェイス（xe CLI）に管理インターフェイスを提供します。管理者が実行する管理コマンドは、プールマスターにより、必要に応じて個々のメンバーホストに転送されます。

注：

高可用性機能が有効なリソースプールでは、プールマスターに障害が発生すると、別のホストがマスターとして選出されます。

リソースプール作成の要件

リソースプールは、同種（または制限付きの異種混在型）のCitrix Hypervisorサーバーの集合であり、最大ホスト数は64です。同種の定義は以下のとおりです：

プールに追加するサーバー上のCPUは、ベンダー、モデル、および機能が、プール内の既存のサーバー上のCPUと同じである。
インストールされているCitrix Hypervisorソフトウェアが同じバージョンである。

以上のほか、リソースプールに追加するサーバーに適用される制限として、Citrix Hypervisorによって、以下の条件を満たしていることが確認されます：

ほかのリソースプールのメンバーではない。
共有ストレージが設定されていない。
実行中または一時停止している仮想マシンをホストしていない。
仮想マシンのシャットダウンなど、サーバー上で処理をアクティブに実行している仮想マシンがない。
システムの時計が、プールマスターと同期している（NTPを使用している場合など）。
サーバーの管理インターフェイスがボンディングされていない（リソースプールに追加した後はボンディング可能）。
管理IPが静的である（そのサーバー上またはDHCPサーバー上で固定アドレスが指定されている）。

Citrix Hypervisorサーバーに搭載されている物理ネットワークインターフェイスの数やローカルストレージリポジトリのサイズは、リソースプール内で異なっていても構いません。また、完全に同一のCPUを搭載した複数のサーバーを入手することは難しい場合が多いため、軽微なばらつきは許容されます。CPUが異なるホストをリソースプールに追加しても問題がないと判断できる場合は、--forceパラメーターを指定してホストを強制的に追加することもできます。

プール内のすべてのホストは同じサイトに存在し、低遅延のネットワークで接続されている必要があります。

注：

リソースプールで共有されるNFSまたはiSCSIストレージを提供するサーバーは、静的なIPアドレスが設定されている必要があります。

プールには、仮想マシンを実行するCitrix Hypervisorサーバーを動的に選択したり、Citrix Hypervisorサーバー間で仮想マシンを動的に移行したりするための共有ストレージリポジトリが含まれている必要があります。可能な場合は、共有ストレージを設定してからリソースプールを作成してください。共有ストレージを追加したら、ローカルストレージ上にディスクを持つ既存の仮想マシンを共有ストレージ上に移動しておくことをお勧めします。仮想マシンを移動するには、xe vm-copyコマンドまたはXenCenterを使用します。

リソースプールを作成する

リソースプールは、XenCenterまたはCLIを使用して作成できます。新しいホストをリソースプールに追加すると、そのホスト上のローカルデータベースがプールのデータベースと同期され、プールに適用されているいくつかの設定がそのホストに継承されます：

仮想マシン、ローカル、およびリモートのストレージ設定は、プールのデータベースに追加されます。プールへの追加処理が完了し、管理者がリソースを明示的に共有するまで、この設定はプールに追加するホストに適用されません。
リソースプールに追加したホストには、プールに設定されている既存の共有ストレージリポジトリが継承され、その共有ストレージへのアクセスが自動的に可能になるように適切な物理ブロックデバイス（PBD）レコードが作成されます。
一部のネットワーク設定も、新しいホストに継承されます。つまり、ネットワークインターフェイスカード（NIC）の構造的な詳細、仮想LAN（VLAN）、およびボンディングされたインターフェイスはすべて継承されますが、ポリシー情報は継承されません。追加したホスト上で再設定する必要があるポリシーには、以下のものが含まれます：
- 管理インターフェイスのIPアドレス（プールに追加する前に設定済みのアドレスが保持されます）。
- 管理インターフェイスの場所（プールに追加する前の設定が保持されます）。たとえば、プール内のほかのホストの管理インターフェイスがボンディングされたインターフェイス上に設定されている場合は、新しいホストの管理インターフェイスをそのボンディングに移行する必要があります。
- ストレージ専用のネットワークインターフェイス。XenCenterまたはCLIを使って新しいホストに再割り当てし、トラフィックが正しく転送されるように物理ブロックデバイスを接続し直す必要があります。これは、プールに追加するときにIPアドレスが割り当てられないためで、このように正しく設定しないとストレージ用のネットワークインターフェイスを使用できません。CLIを使用したストレージ専用ネットワークインターフェイスカードの設定について詳しくは、「ネットワークの管理」を参照してください。

注：

ホストの管理インターフェイスがリソースプールと同じタグが付けられたVLANにある場合にのみ、新しいホストをリソースプールに追加することができます。

xe CLIを使用してプールにホストを追加する

プールに追加するCitrix Hypervisorホストでコンソールを開きます。
次のコマンドを実行して、Citrix Hypervisorホストをプールに追加します：
```
xe pool-join master-address=<address of pool coordinator> master-username=<administrator username> master-password=<password>

```
master-addressにはプールコーディネーターの完全修飾ドメイン名を指定します。passwordにはプールコーディネーターのインストール時に設定した管理者パスワードを指定します。

注：

ホストをプールに参加させると、参加したホストの管理者パスワードは、プールコーディネーターの管理者パスワードと一致するように自動的に変更されます。

前の手順で使用した2つのCitrix Hypervisorサーバーは、デフォルトでは、名前のないリソースプールに属しています。リソースプールを作成するには、次のコマンドを実行して、名前のないリソースプールに名前を設定します。Tabキーを押してpool_uuidを取得することもできます：

xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->

異種混在型リソースプールを作成する

Citrix Hypervisorでは、種類の異なるハードウェアを使って異種混在型のリソースプールを作成できるため、新しいハードウェアによる環境の拡張が簡単に行えます。異種混在型のリソースプールを作成するには、マスキングまたはレベリングと呼ばれる技術をサポートするIntel社（FlexMigration）またはAMD社（Extended Migration）のCPUが必要です。これらの機能では、CPUを実際とは異なる製造元、モデル、および機能のものとして見せかけることができます。これにより、異なる種類のCPUを搭載したホストでプールを構成しても、ライブマイグレーションがサポートされます。

注：

異種混在型プールに追加するCitrix HypervisorサーバーのCPUが、プール内のホストと同一ベンダー（AMDまたはIntel）のものである必要があります。ただし、サーバーは、ファミリ、モデル、またはステップ数が同じタイプである必要はありません。

Citrix Hypervisorでは、異種混在型プールのサポートが簡素化されました。ホストは、（CPUが同じベンダーファミリーからのものである限り）基になるCPUの種類に関係なく既存のリソースプールに追加できるようになりました。プールの機能セットは、以下が行われるたびに動的に計算されます：

新しいホストをプールに追加した場合
プールメンバーをプールから除外した場合
プールメンバーが再起動の後に再接続した場合

プールの機能セットにおける変更は、プールで実行中の仮想マシンには影響しません。実行中の仮想マシンは、開始時に適用された機能セットを引き続き使用します。この機能セットは起動時に固定され、移行、一時停止、および再開操作中も継続されます。機能の劣るホストがプールに追加されてプールのレベルが低下する場合、実行中の仮想マシンはプール内の新しく追加されたホストを除く任意のホストに移行できます。仮想マシンをプール内またはプール間で別のホストに移動または移行しようとすると、Citrix Hypervisorによって、移行先ホストの機能セットに対して仮想マシンの機能セットが比較されます。機能セットに互換性があることが分かった場合は、仮想マシンの移行が許可されます。これによって、仮想マシンで使用しているCPU機能に関係なく、仮想マシンをプール間で自由に移動できるようになります。ワークロードバランスを使用して、仮想マシンを移行するのに最適な移行先ホストを選択すると、互換性のない機能セットが使用されているホストは、移行先ホストとして推奨されません。

共有ストレージを追加する

サポートされている共有ストレージの種類の一覧については、「ストレージリポジトリの形式」を参照してください。ここでは、共有ストレージ（ストレージリポジトリと呼びます）を既存のNFSサーバー上に作成する方法について説明します。

CLIを使用してNFS共有ストレージをリソースプールに追加するには

プール内の任意のCitrix Hypervisorサーバーで、コンソールを開きます。
次のコマンドを実行して、server:/pathにストレージリポジトリを作成します：
```
xe sr-create content-type=user type=nfs name-label="Example SR" shared=true \
    device-config:server=server \
    device-config:serverpath=path

```
ここで、device-config:serverはNFSサーバーのホスト名であり、device-config:serverpathはNFSサーバー上のパスです。sharedにtrueを指定しているため、プール内のすべてのCitrix Hypervisorサーバーに共有ストレージが自動的に接続されます。また、このプールに後で追加するすべてのCitrix Hypervisorサーバーにもこの共有ストレージが自動的に接続されます。ストレージリポジトリの汎用一意識別子（Universally Unique Identifier：UUID）が、画面上に出力されます。
次のコマンドを実行して、プールのUUIDを確認します：
```
xe pool-list

```
次のコマンドを実行して、共有ストレージをプール全体のデフォルトとして設定します：
```
xe pool-param-set uuid=pool_uuid default-SR=sr_uuid

```
共有ストレージがプールのデフォルトとして設定されたため、今後作成するすべての仮想マシンのディスクがデフォルトで共有ストレージに作成されます。ほかの種類の共有ストレージを作成する方法については、「ストレージリポジトリの形式」を参照してください。

リソースプールからCitrix Hypervisorサーバーを削除する

注：

Citrix Hypervisorサーバーをプールから削除する前に、そのホスト上のすべての仮想マシンがシャットダウン状態であることを確認してください。シャットダウンされていない仮想マシンが検出されると、警告メッセージが表示され、ホストを削除できません。

リソースプールからホストを削除（イジェクト）すると、サーバーが再起動して再初期化され、新規インストールと同じ状態になります。ただし、ローカルディスク上に重要なデータがある場合は、プールからCitrix Hypervisorサーバーを削除しないでください。

CLIを使用してホストをリソースプールから削除するには

プール内の任意のホストで、コンソールを開きます。
次のコマンドを実行して、ホストのUUIDを確認します：
```
xe host-list

```
次のコマンドを実行して、そのホストをプールから削除します：
```
xe pool-eject host-uuid=host_uuid

```
Citrix Hypervisorサーバーがリソースプールから削除され、新規インストールの状態になります。

警告：

ローカルディスクに重要なデータが格納されている場合は、そのホストをリソースプールから削除しないでください。ホストをプールから削除すると、すべてのデータが消去されます。ローカルディスク上のデータを保持するには、XenCenter、またはxe vm-copy CLIコマンドを使用して、仮想マシンをプール上の共有ストレージにコピーしておきます。

ローカルディスク上に仮想マシンがあるCitrix Hypervisorサーバーをプールから削除すると、これらの仮想マシンはプールのデータベースに残り、ほかのCitrix Hypervisorサーバーからもプール内に存在しているように見えます。このような仮想マシンを起動可能にするためには、その仮想マシンに関連付けられている仮想ディスクを、プール内のほかのCitrix Hypervisorサーバーからアクセスできる共有ストレージ上のものに変更するか、仮想ディスクを削除する必要があります。このため、プールにホストを追加する場合には、ローカルストレージの内容を共有ストレージ上に移動することをお勧めします。これにより、プールからCitrix Hypervisorサーバーを削除したりホストに物理的な障害が発生したりしたときのデータの損失を回避することができます。

注：

ホストがタグ付きVLANネットワーク上で管理インターフェイスがあるプールから削除されると再起動され、このマシンの管理インターフェイスが同じネットワーク上で利用できるようになります。

Citrix Hypervisorサーバーのプールを保守するための準備

リソースプール内のホストの保守を行う場合は、そのホストを無効にして、仮想マシンが起動しなくなるようにしてから、仮想マシンをプール内の別のCitrix Hypervisorサーバーに移行しておく必要があります。これを行うには、XenCenterを使用して、Citrix Hypervisorサーバーを保守モードに切り替えます。詳しくは、XenCenterドキュメントで「保守モードでの実行」を参照してください。

予備の同期処理は24時間ごとに機能します。プールマスターを保守モードにすると、オフラインになった仮想マシンに対するラウンドロビンデータベースが最大で24時間分失われます。

警告：

アップデートをインストールする前に、すべてのCitrix Hypervisorサーバーを再起動して、設定を確認することを強くお勧めします。これにより、Citrix Hypervisorサーバーが再起動されるまで適用されない変更内容が原因で、アップデートに失敗することを回避できます。

CLIを使用してプール内のホストを保守するための準備を行うには

次のコマンドを実行します：
```
xe host-disable uuid=Citrix Hypervisor_host_uuid
xe host-evacuate uuid=Citrix Hypervisor_host_uuid

```
これにより、Citrix Hypervisorサーバーが無効になり、実行中の仮想マシンがプール内の別のCitrix Hypervisorサーバーに移行されます。
保守作業を行います。
保守作業が終了したら、次のコマンドを実行して、Citrix Hypervisorサーバーを有効にします：
```
xe host-enable

```
シャットダウンまたは一時停止した仮想マシンを起動または再開します。

リソースプールデータのエクスポート

［リソースデータのエクスポート］オプションを使用すると、リソースプールのリソースデータレポートを生成し、それをXLSファイルやCSVファイルとしてエクスポートできます。このレポートには、リソースプール内のサーバー、ネットワーク、ストレージ、仮想マシン、VDI、GPUなど、さまざまなリソースについての詳細な情報が記述されます。これにより、管理者はCPU、ストレージ、およびネットワークなどのワークロードに基づいて、リソースの追跡、計画、および割り当てを行うことができます。

注：

［リソースプールデータのエクスポート］は、Citrix Hypervisor Premium Editionのユーザー、またはCitrix Virtual Apps and DesktopsやCitrix DaaSの利用特典によりCitrix Hypervisorにアクセスできるユーザーが使用できます。

このレポートに記述されるリソースおよびリソースデータの一覧を以下に示します：

サーバー：

名前
プールマスター
UUID
アドレス
CPU使用率
ネットワーク（平均/最大KB/秒）
使用メモリ
ストレージ
アップタイム
説明

ネットワーク

名前
接続状態
MAC
MTU
VLAN
種類
場所

VDI：

名前
種類
UUID
サイズ
ストレージ
説明

ストレージ：

名前
種類
UUID
サイズ
場所
説明

仮想マシン：

名前
電源状態
実行サーバー
アドレス
MAC
NIC
オペレーティングシステム
ストレージ
使用メモリ
CPU使用率
UUID
アップタイム
テンプレート
説明

GPU：

名前
サーバー
PCIバスのパス
UUID
使用電力
温度
使用メモリ
コンピューター使用率

注：

GPUに関する情報は、GPUを搭載したCitrix Hypervisorサーバーでのみ記述されます。

リソースデータをエクスポートするには

XenCenterのナビゲーションペインで ［インフラストラクチャ］ をクリックし、プールをクリックします。
［プール］ メニューをクリックし、［リソースデータのエクスポート］ を選択します。
レポートの保存先を指定して、［保存］ をクリックします。

ホストの電源投入

リモートからのホストの電源投入

Citrix Hypervisorサーバーの電源投入機能を使用すると、XenCenterやCLIを使ってリモートでサーバーの電源を投入したり切断（シャットダウン）したりできます。

ホストの電源投入機能を有効にするには、以下のいずれかの電源管理ソリューションが必要です。

Wake-on-LANが有効なネットワークカード。
Dell Remote Access Card（DRAC）。Citrix HypervisorでDRACを使用するには、Dellサプリメンタルパックをインストールしておく必要があります。DRACをサポートするには、DRACのサーバーにRACADMコマンドラインユーティリティをインストールして、DRACおよびそのインターフェイスを有効にする必要があります。通常、RACADMはDRAC管理ソフトウェアに含まれています。詳しくは、Dell社のDRACドキュメントを参照してください。
Citrix Hypervisorを介して電源を投入または切断するための、管理APIに基づいたカスタムスクリプト。詳しくは、次のセクションの「ホストの電源投入機能のカスタムスクリプトを作成する」を参照してください。

電源を自動的に投入または切断できるようにXenServerホストを設定するには、以下の操作を行います：

プール内のホストがリモートからの電源制御をサポートしていること（Wake-on-LAN機能、DRACカード、またはカスタムスクリプトが設定されていることなど）を確認します。
CLIまたはXenCenterを使用して、ホスト電源投入機能を有効にします。

CLIを使用してホストの電源投入を管理する

ホスト電源投入機能は、CLIまたはXenCenterで管理できます。このセクションでは、CLIでの管理について説明します。

ホスト電源投入機能は、ホストレベル（つまり各Citrix Hypervisorホスト上）で有効になります。

この機能を有効にすると、CLIやXenCenterからホストの電源を入れることができます。

CLIを使用してホスト電源投入を有効にするには

次のコマンドを実行します：

xe host-set-power-on-mode host=<host uuid> \
    power-on-mode=("" , "wake-on-lan", "DRAC","custom") \
    power-on-config=key:value
<!--NeedCopy-->

DRACでは、シークレット機能を使用している場合、power_on_ipキーでパスワードを指定します。詳しくは、「シークレット」を参照してください。

CLIを使用してホストの電源をリモートから投入するには

次のコマンドを実行します：

xe host-power-on host=<host uuid>
<!--NeedCopy-->

ホスト電源投入機能のカスタムスクリプトを作成する

ご使用のサーバーのリモート電源投入ソリューションで、デフォルトではサポートされていないプロトコル（Wake-On-RingやIntel Active Management Technologyなど）が使用されている場合は、Citrix Hypervisorコンピューターの電源を投入するカスタムLinux Pythonスクリプトを作成します。ただし、DRAC、およびWake-On-LANソリューション用のカスタムスクリプトを作成することもできます。

このセクションでは、Citrix Hypervisor APIコールhost.power_onのキー/値ペアを使用したホスト電源投入用カスタムスクリプトの作成について説明します。

カスタムスクリプトは、Citrix Hypervisorサーバー上でリモートで電源投入を制御する必要があるときにコマンドラインから実行します。また、XenCenterでスクリプトの実行を指定し、XenCenter UI機能を使用して操作することもできます。

Citrix Hypervisor APIについては、開発者向けドキュメントのWebサイトで公開されている「Citrix Hypervisor Management API」を参照してください。

警告：

/etc/xapi.d/plugins/ディレクトリにインストールされるデフォルトのスクリプトを変更することはできません。新しく作成したスクリプトをこのディレクトリに追加することはできますが、Citrix Hypervisorに付属のスクリプトは編集しないでください。

キー/値ペア

ホスト電源投入機能を使用するには、host.power_on_modeキーとhost.power_on_configキーを設定します。値については、後のセクションを参照してください。

次のAPIコールを使用すると、これらのフィールドを一度に設定することもできます：

void host.set_host_power_on_mode(string mode, Dictionary<string,string> config)
<!--NeedCopy-->

host.power_on_mode

定義： 電源管理ソリューションの種類（Dell DRACなど）を指定するキー/値ペアを含みます。
設定可能な値：
- 空文字。電源管理を無効にします。
- DRAC：Dell DRACを示します。DRACを使用するには、Dellサプリメンタルパックをインストールしておく必要があります。
- wake-on-lan：Wake on LANを示します。
- そのほかの名前（カスタムの電源投入スクリプトの指定）。このオプションでは、カスタムの電源管理スクリプトを指定できます。
種類：文字列

host.power_on_config

定義： 電源投入モードを指定するキー/値ペアを含みます。DRACに関する追加情報を指定します。
設定可能な値：
- 電源管理ソリューションの種類としてDRACを指定する場合は、このキーで以下のいずれかの値を指定します：
  - power_on_ip：電源管理カードとの通信で使用されるIPアドレスです。DRACが構成されたネットワークインターフェイスのドメイン名を入力することもできます。
  - power_on_user：管理プロセッサに関連付けられたDRACのユーザー名です。工場出荷時のものから変更されている場合があります。
  - power_on_password_secret：セキュリティを保護するシークレット機能を使用してパスワードを指定します。
- シークレット機能を使用してパスワードを保存するには、キー「power_on_password_secret」を指定します。詳しくは、「シークレット」を参照してください。
種類：マップ（文字列, 文字列）

サンプルスクリプト

このサンプルスクリプトでは、Citrix Hypervisor APIをインポートし、それ自体をカスタムスクリプトとして定義し、さらにリモートから制御するホストに特定のパラメーターを渡します。カスタムスクリプトでは、常にsessionパラメーターを定義する必要があります。

このスクリプトの結果は、実行に失敗した場合のみ表示されます。

import XenAPI
def custom(session,remote_host,
power_on_config):
result="Power On Not Successful"
for key in power_on_config.keys():
result=result+''
key=''+key+''
value=''+power_on_config[key]
return result
<!--NeedCopy-->

注：

作成したスクリプトは、拡張子.pyで/etc/xapi.d/pluginsディレクトリに保存します。

Citrix Hypervisorサーバーとリソースプールとの通信

TLS

Citrix Hypervisorでは、管理APIトラフィックの暗号化にTLS 1.2プロトコルが使用されます。Citrix Hypervisorと管理APIクライアント（またはアプライアンス）との間のあらゆる通信で、TLS 1.2プロトコルが使用されます。

重要：

製品の暗号化機能に対する顧客の変更はサポートされていません。

Citrix Hypervisorでは、次の暗号の組み合わせが使用されます：

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

さらに、Citrix Virtual Apps and Desktopsの一部のバージョンとの後方互換性のために、次の暗号の組み合わせもサポートされています。

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256

注：

これらの追加の暗号の組み合わせはCBCモードを使用します。一部の組織はGCMモードを優先しますが、Windows Server 2012 R2はGCMモードとRSA暗号の組み合わせをサポートしていません。Citrix Hypervisorサーバーまたはプールに接続するWindows Server 2012 R2で実行されているクライアントは、これらのCBCモードの暗号の組み合わせを使用することが必要な場合があります。

SSH

SSHクライアントを使用してCitrix Hypervisorサーバーに直接接続する場合、次のアルゴリズムを使用できます：

暗号：

aes128-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
aes128-cbc
aes256-cbc

MAC：

hmac-sha2-256
hmac-sha2-512
hmac-sha1

KexAlgorithms：

curve25519-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
diffie-hellman-group14-sha1

HostKeyAlgorithms：

ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-ed25519
ssh-rsa

注：

使用可能な暗号スイートを上記のリストにあるものだけに制限するには、Hotfix XS82E015 - For Citrix Hypervisor 8.2をインストールしてください。

Citrix HypervisorサーバーへのSSHアクセスを無効にする場合は、xsconsoleでこれを行うことができます。

XenCenterからサーバーコンソールを開き、rootとしてログインします。
「xsconsole」と入力します。
xsconsoleで、［リモートサービス構成］ > ［リモートシェルの有効化/無効化］ に移動します。

コンソールには、リモートシェルが有効であるかが表示されます。
リモートシェルを有効にするか無効にするかを変更するには、Enterキーを押します。

重要：

製品の暗号化機能に対する顧客の変更はサポートされていません。

TLS証明書のサーバーへのインストール

Citrix Hypervisorサーバーには、デフォルトのTLS証明書がインストールされています。ただし、HTTPSを使用してCitrix HypervisorとCitrix Virtual Apps and Desktops間の通信を保護するには、信頼できる証明機関から提供された証明書をインストールします。

ここでは、xe CLIを使用して証明書をインストールする方法について説明します。XenCenterでの証明書の取り扱いについて詳しくは、XenCenterのドキュメントを参照してください。

TLS証明書とそのキーが次の要件を満たしていることを確認します：

証明書とキーペアがRSAキーである。
キーが証明書と一致する。
キーは、証明書とは別のファイルで提供される。
証明書は、中間証明書とは別のファイルで提供される。
キーファイルの種類は、.pemまたは.keyのいずれかである。
証明書ファイルの種類は、.pem、.cer、または.crtのいずれかである。
キーの長さは、2,048ビット以上4,096ビット以下である。
キーは暗号化されていないPKCS#8形式のキーで、パスキーがない。
キーと証明書は、Base64で暗号化された「PEM」形式である。
有効期限が切れていない、有効な証明書である。
署名アルゴリズムはSHA-2（SHA256）である。

選択した証明書とキーがこれらの要件を満たしていない場合は、xe CLIにより警告が表示されます。

TLS証明書はどこで入手できますか?

Citrix Hypervisorサーバーにインストールする、信頼された機関からの証明書が既にあるかもしれません。
また、サーバーで証明書を作成し、目的の証明機関に送信して署名を要求することができます。この方法だと、Citrix Hypervisorサーバーに秘密キーが保管されてシステム間でコピーされないため、より安全です。

TLS証明書の作成には次の手順があります：

1. 証明書署名要求の生成

最初に、秘密キーと証明書署名要求を生成します。Citrix Hypervisorサーバーで、以下の手順を実行します：

秘密キーファイルを作成するには、次のコマンドを実行します：
```
openssl genrsa -des3 -out privatekey.pem 2048

```

キーからパスワードを削除します：

openssl rsa -in privatekey.pem -out privatekey.nop.pem
<!--NeedCopy-->

秘密キーを使用して証明書署名要求を作成します：
```
openssl req -new -key privatekey.nop.pem -out csr

```
画面のメッセージに従って以下の情報を入力し、証明書署名要求を生成します。
- Country Name：TLS証明書の国コードを入力します。日本の国コードは「JP」です。国コードの一覧については、インターネット上を検索して入手できます。
- State or Province Name（full name）：プールが動作する場所の都道府県名を入力します。たとえば、東京の場合は「Tokyo」と入力します。
- Locality Name：プールが動作する場所の市区町村名を入力します。
- Organization Name：所属組織または会社の名前を入力します。
- Organizational Unit Name：部門や部署の名前を入力します。この情報は入力しなくても構いません。
- Common Name：Citrix Hypervisorサーバーの完全修飾ドメイン名（FQDN）を入力します。有効期限のないFQDNまたはIPアドレスを使用することをお勧めします。
- Email Address：証明書に含めるメールアドレスを入力します。
現在のディレクトリに証明書署名要求が生成され、「csr」という名前で保存されます。
証明書署名要求をコンソールウィンドウに表示するには、次のコマンドを実行します：
```
cat csr

```

証明書署名要求の全内容をコピーし、この情報を使用して、証明機関に証明書を要求します。

証明書署名要求の例：

-----BEGIN CERTIFICATE REQUEST-----
MIIDBDCCAewCAQAwgYsxCzAJBgNVBAYTAlVLMRcwFQYDVQQIDA5DYW1icmlkZ2Vz
aGlyZTESMBAGA1UEBwwJQ2FtYnJpZGdlMRIwEAYDVQQKDAlYZW5TZXJ2ZXIxFTAT
...
SdYCkFdo+85z8hBULFzSH6jgSP0UGQU0PcfIy7KPKyI4jnFQqeCDvLdWyhtAx9gq
Fu40qMSm1dNCFfnACRwYQkQgqCt/RHeUtl8srxyZC+odbunnV+ZyQdmLwLuQySUk
ZL8naumG3yU=
-----END CERTIFICATE REQUEST-----
<!--NeedCopy-->

2. 証明書署名要求を証明機関に送信

証明書署名要求を生成したら、組織の優先認証機関に要求を送信できます。

認証機関は、デジタル証明書を提供する信頼できるサードパーティです。一部の認証機関では、証明書がインターネットからアクセス可能なシステム上でホストされている必要があります。この要件がある認証機関を使用しないことをお勧めします。

認証機関は署名要求に対応し、次のファイルを提供します：

署名された証明書
ルート証明書
該当する場合、中間証明書

これで、これらすべてのファイルをCitrix Hypervisorサーバーにインストールできるようになります。

3. Citrix Hypervisorサーバーへの署名証明書のインストール

証明機関から証明書署名要求に対する応答を受信したら、次の手順を実行して、Citrix Hypervisorサーバーに証明書をインストールします：

証明機関から、署名入り証明書、ルート証明書、および中間証明書（証明機関により提供される場合）を取得します。
キーと証明書をCitrix Hypervisorサーバーにコピーします。

サーバーで次のコマンドを実行します：

xe host-server-certificate-install certificate=<path_to_certificate_file> private-key=<path_to_private_key> certificate-chain=<path_to_chain_file>

certificate-chainパラメーターはオプションです。

証明書をインストールしたら秘密キーファイルを削除して、セキュリティを強化することができます。

管理者パスワードの管理

Citrix Hypervisorサーバーを最初にインストールするときに、管理者パスワードまたはルートパスワードを設定します。このパスワードを使用して、XenCenterをサーバーに接続するか、システム設定コンソールであるxsconsoleに（ユーザー名root）でログインします。

サーバーをプールに参加させると、サーバーの管理者パスワードは、プールマスターの管理者パスワードと一致するように自動的に変更されます。

注：

Citrix Hypervisorの管理者パスワードには、ASCII文字のみを使用する必要があります。

パスワードを変更する

XenCenter、xe CLI、またはxsconsoleを使用して、管理者パスワードを変更できます。

XenCenter

XenCenterを使用してプールまたはスタンドアロンサーバーの管理者パスワードを変更するには、次の手順を実行します：

［リソース］ ペインでリソースプール、またはプール内のサーバーを選択します。
［プール］ メニューまたは ［サーバー］ メニューで、［サーバーのパスワードの変更］ を選択します。

スタンドアロンサーバーのルートパスワードを変更する場合は、［リソース］ ペインでそのサーバーを選択し、［サーバー］ メニューで ［パスワード］ 、［変更］ の順に選択します。

サーバーにログインするための資格情報をXenCenterセッションの終了後も保持するオプションが有効な場合は、ここで変更したパスワードが保持されます。詳しくは、「サーバー接続状態の保存」を参照してください。

管理者パスワードを変更した後、プールシークレットをローテーションします。詳しくは、「プールシークレットを入れ替える」を参照してください。

xe CLI

xe CLIを使用して管理者パスワードを変更するには、プール内のサーバーで次のコマンドを実行します：

  xe user-password-change new=<new_password>
<!--NeedCopy-->

注：

コマンド履歴にプレーンテキストのパスワードが保存されないように、コマンドの前に必ずスペースを入れてください。

xsconsole

xsconsoleを使用してプールまたはスタンドアロンサーバーの管理者パスワードを変更するには、次の手順を実行します：

プールマスターで、コンソールに移動します。
rootとしてログインします。
「xsconsole」と入力します。Enterキーを押します。xsconsoleが表示されます。
xsconsoleで、矢印キーを使用してAuthenticationオプションに移動します。Enterキーを押します。
Change Passwordに移動します。 Enterキーを押します。
管理者パスワードで認証します。
Change Passwordダイアログで、以下を実行します：
1. 現在のパスワードを入力する。
2. 新しいパスワードを入力する。
3. 新しいパスワードをもう一度入力して確認する。
Password Change Successful画面が開きます。閉じるには、Enterキーを押します。

サーバーがプールマスターの場合、この更新されたパスワードはプール内の他のサーバーに伝達されます。

紛失したパスワードをリセットする

Citrix Hypervisorサーバーの管理者（ルート）パスワードを紛失した場合は、サーバーに直接アクセスしてパスワードをリセットできます。

Citrix Hypervisorサーバーを再起動します。
GRUBメニューが表示されたら、eを押してブートメニューのエントリを編集します。
module2で始まる行にinit=/sysroot/bin/shを追加します。
Ctrl+Xを押して、ルートシェルを起動します。

コマンドシェルで、次のコマンドを実行します：

chroot /sysroot
passwd

(type the new password twice)

sync
/sbin/reboot -f
<!--NeedCopy-->

サーバーがプールマスターの場合、この更新されたパスワードはプール内の他のサーバーに伝達されます。

管理者パスワードを変更した後、プールシークレットをローテーションします。

プールシークレットを入れ替える

プールシークレットは、プール内のサーバー間で共有されるシークレットです。これにより、サーバーはプールに対するメンバーシップを証明できます。

プール管理者の役割を持つユーザーはこのシークレットを検出できるため、これらのユーザーのいずれかが組織を離れたり、プール管理者の役割を失ったりした場合は、プールシークレットをローテーションすることをお勧めします。

プールシークレットは、XenCenterまたはxe CLIを使用して入れ替えることができます。

XenCenter

XenCenterを使用してプールのプールシークレットを入れ替えるには、次の手順を実行します：

［リソース］ ペインでリソースプール、またはプール内のサーバーを選択します。
［プール］ メニューで ［プールシークレットを入れ替える］ を選択します。

プールシークレットを入れ替えるときに、ルートパスワードの変更を求められます。不正使用の可能性があってプールシークレットを入れ替えた場合は、ルートパスワードも変更してください。詳しくは、「パスワードを変更する」を参照してください。

xe CLI

xe CLIを使用してプールシークレットを入れ替えるには、プール内のサーバーで次のコマンドを実行します：

xe pool-secret-rotate
<!--NeedCopy-->

不正使用の可能性があってプールシークレットを入れ替えた場合は、ルートパスワードも変更してください。詳しくは、「パスワードを変更する」を参照してください。

Citrix HypervisorプールのIGMPスヌーピングを有効にする

Citrix Hypervisorがマルチキャストトラフィックをすべてのゲスト仮想マシンに送信すると、ホストデバイスは想定外のパケットを処理する必要があるため、不必要な負荷が発生することになります。IGMPスヌーピングを有効にすると、ローカルネットワーク上のホストは明示的に参加していないマルチキャストグループのトラフィックを受信しなくなるため、マルチキャストのパフォーマンスが向上します。IGMPスヌーピングは、IPTVのように帯域幅を大幅に消費するIPマルチキャストアプリケーションの場合、特に有効です。

メモ：

IGMPスヌーピングは、ネットワークのバックエンドがOpen vSwitchを使用している場合のみ使用できます。

この機能をプールで有効にする場合、物理スイッチの1つでIGMPクエリアを有効にすることが必要なこともあります。これを有効にしないと、サブネットワークのマルチキャストがブロードキャストにフォールバックし、Citrix Hypervisorのパフォーマンスが低下する可能性があります。

IGMP v3を実行しているプールでこの機能を有効にすると、仮想マシンの移行またはネットワークボンディングのフェイルオーバーによってIGMPのバージョンがv2に切り替わることがあります。

GREネットワークでこの機能を有効にするには、GREネットワークにIGMPクエリアを設定する必要があります。または、物理ネットワークからGREネットワークにIGMPクエリメッセージを転送することもできます。これをしない場合、GREネットワーク内のマルチキャストトラフィックがブロックされます。

リソースプールのIGMPスヌーピングを有効にするには、XenCenterまたはxe CLIを使用します。

XenCenter

［Pool Properties］ に移動します。
［ネットワークオプション］ を選択します。ここで、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	GROUP	Age
14	0	227.0.0.1	15
1	0	querier	24

最初のレコードは、マルチキャストグループ227.0.0.1をポート14でリッスンしているレシーバーが存在することを示しています。Open vSwitchは、227.0.0.1マルチキャストグループ宛てのトラフィックを、すべてのポートにブロードキャストするのではなく、このグループのリスニングポート（この例ではポート14）にのみ転送します。ポート14とグループ227.0.0.1をリンクするレコードは15秒前に作成されました。デフォルトでは、タイムアウト時間は300秒です。これは、レコードを追加した後、スイッチがポート14で300秒間IGMPレポートメッセージを受信しない場合、レコードの有効期限が切れ、テーブルから削除されることを意味します。

2番目のレコードでは、GROUPはquerier（クエリア）です。これは、関連するポートでIGMPクエリメッセージが受信されたことを意味します。クエリアは、どのネットワークノードがマルチキャストグループをリッスンしているかを判断するために、すべてのスイッチポートにブロードキャストされるIGMPクエリメッセージを定期的に送信します。IGMPクエリメッセージを受信すると、レシーバーはIGMPレポートメッセージで応答します。これにより、レシーバーのマルチキャストレコードが更新され、期限切れが回避されます。

VLAN列は、VLANに対して、レシーバー/クエリアが機能していることを示します。「0」はネイティブVLANを意味します。タグ付きVLAN上でマルチキャストを実行する場合は、VLAN上にレコードがあることを確認してください。

注：

VLANシナリオの場合、ネットワークのVLAN IDと等しいVLAN列値を持つクエリアレコードが必要です。そうしないと、VLANネットワークでマルチキャストが機能しません。

このコンテンツの正式なバージョンは英語で提供されています。Cloud Software Groupドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Cloud Software Groupは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いのCloud Software Group製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいはCloud Software Groupとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Cloud Software Groupは責任を負わないものとします。

この情報は役に立ちましたか?

ホストとリソースプール

April 23, 2024

寄稿者:

April 23, 2024

寄稿者:

この情報は役に立ちましたか?