ネットワークの管理

このセクションのネットワーク構成手順は、スタンドアロンホストを構成しているか、リソースプールの一部であるホストを構成しているかによって異なります。

スタンドアロンホストでネットワークを作成する

ホストのインストール中に各PIFに対して外部ネットワークが作成されるため、追加のネットワークを作成する必要があるのは通常、次の目的の場合のみです。

• プライベートネットワークを使用する

• VLANやNICボンディングなどの高度な操作をサポートする

XenCenterを使用してネットワークを追加または削除する方法については、XenCenterドキュメントの「新しいネットワークの追加」を参照してください。

XenServer®ホストのテキストコンソールを開きます。

network-create コマンドを使用してネットワークを作成します。このコマンドは、新しく作成されたネットワークのUUIDを返します。

xe network-create name-label=mynetwork
<!--NeedCopy-->

この時点では、ネットワークはPIFに接続されていないため、内部ネットワークです。

リソースプールでネットワークを作成する

リソースプール内のすべてのXenServerホストは、同じ数の物理NICを持つ必要があります。この要件は、ホストがプールに参加する際には厳密には強制されません。NICの1つは常に、XenServer管理トラフィックに使用される管理インターフェイスとして指定されます。

プール内のすべてのホストは共通のネットワークセットを共有するため、プール内のXenServerホストには同じ物理ネットワーク構成を持たせることが重要です。個々のホスト上のPIFは、デバイス名に基づいてプール全体のネットワークに接続されます。たとえば、eth0 NICを持つプール内のすべてのXenServerホストは、プール全体のNetwork 0ネットワークに接続された対応するPIFを持っています。eth1 NICとNetwork 1を持つホスト、およびプール内の少なくとも1つのXenServerホストに存在する他のNICについても同様です。

プール内の他のホストと異なる数のNICを持つXenServerホストがある場合、問題が発生する可能性があります。これは、すべてのプールネットワークがすべてのプールホストに対して有効であるとは限らないためです。たとえば、host1とhost2が同じプールにあり、host1が4つのNICを持ち、host2が2つのNICしか持たない場合、host2ではeth0とeth1に対応するPIFに接続されたネットワークのみが有効です。eth2とeth3に対応するネットワークに接続されたVIFを持つhost1上のVMは、host2に移行できません。

VLANを作成する

リソースプール内のホストの場合、pool-vlan-create コマンドを使用できます。このコマンドはVLANを作成し、プール内のホストに必要なPIFを自動的に作成してプラグインします。詳細については、pool-vlan-create を参照してください。

XenServerホストコンソールを開きます。

VLANで使用するネットワークを作成します。新しいネットワークのUUIDが返されます。

xe network-create name-label=network5
<!--NeedCopy-->

pif-list コマンドを使用して、目的のVLANタグをサポートする物理NICに対応するPIFのUUIDを見つけます。既存のVLANを含むすべてのPIFのUUIDとデバイス名が返されます。

xe pif-list
<!--NeedCopy-->

新しいVLANに接続するすべてのVMで、目的の物理PIFとVLANタグを指定してVLANオブジェクトを作成します。新しいPIFが作成され、指定されたネットワークに接続されます。新しいPIFオブジェクトのUUIDが返されます。

xe vlan-create network-uuid=network_uuid pif-uuid=pif_uuid vlan=5
<!--NeedCopy-->

VM VIFを新しいネットワークに接続します。詳細については、スタンドアロンホストでのネットワークの作成 を参照してください。

スタンドアロンホストでNICボンディングを作成する

NICボンディングの作成にはXenCenterを使用することをお勧めします。詳細については、NICの構成 を参照してください。

このセクションでは、プールに属していないXenServerホストでxe CLIを使用してNICインターフェースをボンディングする方法について説明します。リソースプールを構成するXenServerホストでxe CLIを使用してNICボンディングを作成する方法については、「リソースプールでのNICボンディングの作成」を参照してください。

NICボンディングを作成する

NICをボンディングすると、ボンディングは管理インターフェースとして使用されているPIF/NICを吸収します。管理インターフェースは自動的にボンディングPIFに移動されます。

1. network-create コマンドを使用して、ボンディングされたNICで使用するネットワークを作成します。新しいネットワークのUUIDが返されます。

   xe network-create name-label=bond0
   <!--NeedCopy-->
   

2. pif-list コマンドを使用して、ボンディングで使用するPIFのUUIDを特定します。

   xe pif-list
   <!--NeedCopy-->
   

3. 次のいずれかを実行します。

   • ボンディングをアクティブ/アクティブモード（デフォルト）で構成するには、bond-create コマンドを使用してボンディングを作成します。パラメータをコンマで区切り、新しく作成されたネットワークのUUIDとボンディングするPIFのUUIDを指定します。

      xe bond-create network-uuid=network_uuid /
           pif-uuids=pif_uuid_1,pif_uuid_2,pif_uuid_3,pif_uuid_4
      <!--NeedCopy-->
     

     2つのNICをボンディングする場合は2つのUUIDを、4つのNICをボンディングする場合は4つのUUIDを入力します。コマンド実行後、ボンドのUUIDが返されます。

   • アクティブ/パッシブまたはLACPボンドモードでボンドを設定するには、同じ構文を使用し、オプションのmodeパラメーターを追加して、lacpまたはactive-backupを指定します。

      xe bond-create network-uuid=network_uuid pif-uuids=pif_uuid_1, /
           pif_uuid_2,pif_uuid_3,pif_uuid_4 /
           mode=balance-slb | active-backup | lacp
      <!--NeedCopy-->
     

ボンドのMACアドレスを制御する

管理インターフェースをボンディングすると、管理インターフェースとして使用されているPIF/NICがその一部となります。ホストがDHCPを使用している場合、ボンドのMACアドレスは使用中のPIF/NICと同じになります。管理インターフェースのIPアドレスは変更されません。

ボンドのMACアドレスを、(現在の)管理インターフェースNICのMACアドレスとは異なるように変更できます。ただし、ボンドが有効になり、使用中のMAC/IPアドレスが変更されると、ホストへの既存のネットワークセッションは切断されます。

ボンドのMACアドレスは、次の2つの方法で制御できます。

• オプションのmacパラメーターは、bond-createコマンドで指定できます。このパラメーターを使用して、ボンドのMACアドレスを任意の任意のアドレスに設定できます。

• macパラメーターが指定されていない場合、XenServerは、管理インターフェースがボンド内のインターフェースの1つである場合、その管理インターフェースのMACアドレスを使用します。管理インターフェースがボンドの一部ではないが、別の管理インターフェースがボンドの一部である場合、ボンドはその管理インターフェースのMACアドレス（およびIPアドレス）を使用します。ボンド内のNICのいずれも管理インターフェースではない場合、ボンドは最初に指定されたNICのMACを使用します。

NICボンドを元に戻す

XenServerホストを非ボンディング構成に戻す場合、bond-destroyコマンドはプライマリNICを管理インターフェースのインターフェースとして自動的に構成します。そのため、すべてのVIFは管理インターフェースに移動されます。ホストの管理インターフェースがタグ付きVLANボンディングインターフェース上にある場合、bond-destroyを実行すると、管理VLANはプライマリNICに移動されます。

プライマリNICという用語は、ボンド作成時にMACおよびIP構成がコピーされたPIFを指します。2つのNICをボンディングする場合、プライマリNICは次のとおりです。

1. 管理インターフェースNIC（管理インターフェースがボンディングされたNICの1つである場合）。

2. IPアドレスを持つその他のNIC（管理インターフェースがボンドの一部ではなかった場合）。

3. 最初に指定されたNIC。以下のコマンドを実行して、それがどれであるかを確認できます。

   xe bond-list params=all
   <!--NeedCopy-->
   

リソースプールでNICボンドを作成する

可能な限り、NIC ボンドは、より多くのホストをプールに参加させたり、VM を作成したりする前に、初期リソースプール作成の一部として作成してください。そうすることで、ホストがプールに参加する際にボンド構成が自動的にレプリケートされ、必要な手順の数が減ります。

既存のプールに NIC ボンドを追加するには、次のいずれかが必要です。

• CLI を使用して、プールコーディネーターとプールの各メンバーでボンドを構成する。

• CLI を使用してプールコーディネーターでボンドを構成し、その後、各プールメンバーを再起動して、プールコーディネーターから設定を継承させる。

• XenCenter® を使用してプールコーディネーターでボンドを構成する。XenCenter はメンバーホストのネットワーク設定をプールコーディネーターと自動的に同期するため、メンバーホストを再起動する必要はありません。

簡素化と誤設定の防止のため、NIC ボンドの作成には XenCenter を使用することをお勧めします。詳細については、「NIC の構成」を参照してください。

このセクションでは、xe CLI を使用して、リソースプールを構成する XenServer ホスト上にボンディングされた NIC インターフェースを作成する方法について説明します。スタンドアロンホスト上に xe CLI を使用して NIC ボンドを作成する方法については、「スタンドアロンホストでの NIC ボンドの作成」を参照してください。

警告:

高可用性が有効になっているときにネットワークボンドを作成しようとしないでください。ボンド作成プロセスは、進行中の高可用性ハートビートを妨害し、ホストが自己フェンス（シャットダウン）する原因となります。ホストが適切に再起動できない場合があり、回復には host-emergency-ha-disable コマンドが必要になることがあります。

プールコーディネーターにするホストを選択します。プールコーディネーターは、デフォルトでは名前のないプールに属しています。CLI でリソースプールを作成するには、既存の名前のないプール名を変更します。

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

NIC ボンドの作成 で説明されているように、NIC ボンドを作成します。

プールに参加させたいホストでコンソールを開き、次のコマンドを実行します。

xe pool-join master-address=host1 master-username=root master-password=password
<!--NeedCopy-->

ネットワークとボンドの情報は、新しいホストに自動的にレプリケートされます。管理インターフェースは、元々構成されていたホスト NIC からボンディングされた PIF に自動的に移動されます。つまり、管理インターフェースはボンドに吸収され、ボンド全体が管理インターフェースとして機能するようになります。

設定中のホストの UUID を見つけるには、host-list コマンドを使用します。

xe host-list
<!--NeedCopy-->

警告:

高可用性が有効になっている間は、ネットワークボンディングを作成しないでください。ボンディングの作成プロセスは、進行中の高可用性ハートビートを妨害し、ホストが自己フェンス（シャットダウン）する原因となります。ホストが適切に再起動できない場合があり、回復のためにhost-emergency-ha-disableコマンドを実行する必要があるかもしれません。

専用ストレージNICの構成

XenCenterまたはxe CLIを使用して、NICにIPアドレスを割り当て、ストレージトラフィックなどの特定の機能に専用化できます。NICにIPアドレスを設定する場合、セカンダリインターフェースを作成することで行います。（管理に使用されるIP対応NIC XenServerは、管理インターフェースとして知られています。）

特定の目的のためにセカンダリインターフェースを専用化したい場合は、適切なネットワーク構成が整っていることを確認してください。これは、NICが目的のトラフィックのみに使用されるようにするためです。NICをストレージトラフィックに専用化するには、NIC、ストレージターゲット、スイッチ、およびVLANを、ターゲットが割り当てられたNIC経由でのみアクセスできるように構成します。物理およびIP構成がストレージNICを介して送信されるトラフィックを制限しない場合、管理トラフィックなどのトラフィックをセカンダリインターフェースを介して送信できます。

ストレージトラフィック用に新しいセカンダリインターフェースを作成する場合、以下のIPアドレスを割り当てる必要があります。

• 該当する場合、ストレージコントローラーと同じサブネット上にあること、および

• 他のセカンダリインターフェースまたは管理インターフェースと同じサブネット上にないこと。

セカンダリインターフェースを構成する場合、各セカンダリインターフェースは個別のサブネット上にある必要があります。たとえば、ストレージ用にさらに2つのセカンダリインターフェースを構成したい場合、3つの異なるサブネットにIPアドレスが必要になります。管理インターフェース用に1つ、セカンダリインターフェース1用に1つ、セカンダリインターフェース2用に1つです。

ストレージトラフィックの冗長性のためにボンディングを使用している場合は、Linuxブリッジ（非推奨）ボンディングの代わりにLACPを使用することを検討してください。LACPボンディングを使用するには、vSwitchをネットワークスタックとして構成する必要があります。詳細については、「ネットワークスタックの選択」を参照してください。

注:

iSCSIまたはNFS SRで使用するセカンダリインターフェースとしてNICを選択する際は、専用NICが管理インターフェースからルーティングできない個別のIPサブネットを使用していることを確認してください。これが強制されない場合、ネットワークインターフェースの初期化順序により、ホストの再起動後にストレージトラフィックがメインの管理インターフェース経由でルーティングされる可能性があります。

PIFが別のサブネット上にあること、または選択したPIF経由で目的のトラフィックを強制するようにルーティングがネットワークトポロジに合わせて構成されていることを確認してください。

PIFのIP構成を設定し、modeパラメーターに適切な値を追加します。静的IPアドレス指定を使用する場合は、IP、ネットマスク、ゲートウェイ、およびDNSパラメーターを追加します。

xe pif-reconfigure-ip mode=DHCP | Static uuid=pif-uuid
<!--NeedCopy-->

PIFのdisallow-unplugパラメーターをtrueに設定します：

xe pif-param-set disallow-unplug=true uuid=pif-uuid
<!--NeedCopy-->

xe pif-param-set other-config:management_purpose="Storage" uuid=pif-uuid
<!--NeedCopy-->

管理インターフェースからもルーティングできるストレージ用のセカンダリインターフェースを使用したい場合（この構成はベストプラクティスではないことに留意してください）、2つの選択肢があります。

• ホストの再起動後、セカンダリインターフェースが正しく構成されていることを確認してください。xe pbd-unplug および xe pbd-plug コマンドを使用して、ホスト上のストレージ接続を再初期化します。このコマンドはストレージ接続を再起動し、正しいインターフェース経由でルーティングします。

• あるいは、xe pif-forget を使用して XenServer データベースからインターフェースを削除し、コントロール ドメインで手動で構成することもできます。xe pif-forget は高度なオプションであり、Linux ネットワークを手動で構成する方法に精通している必要があります。

SR-IOV対応NICを使用する

Single Root I/O Virtualization (SR-IOV) は、単一のPCIデバイスが物理システム上で複数のPCIデバイスとして表示されることを可能にする仮想化技術です。実際の物理デバイスは物理機能 (PF) と呼ばれ、その他のデバイスは仮想機能 (VF) と呼ばれます。ハイパーバイザーは1つ以上のVFを仮想マシン (VM) に割り当てることができ、ゲストはデバイスが直接割り当てられているかのように使用できます。

1つ以上のNIC VFをVMに割り当てることで、そのネットワークトラフィックが仮想スイッチをバイパスできるようになります。構成されると、各VMはNICを直接使用しているかのように動作し、処理オーバーヘッドを削減し、パフォーマンスを向上させます。

SR-IOVの利点

SR-IOV VFはVIFよりも優れたパフォーマンスを発揮します。同じNICを介した異なるVMからのトラフィック間のハードウェアベースの分離を保証できます（XenServerネットワークスタックをバイパスします）。

この機能を使用すると、次のことができます。

• SR-IOVをサポートするNICでSR-IOVを有効にする。

• SR-IOVをサポートするNICでSR-IOVを無効にする。

• SR-IOV VFをVFリソースプールとして管理する。

• SR-IOV VFをVMに割り当てる。

• SR-IOV VFを構成する（例：MACアドレス、VLAN、レート）。

• 自動認定キットの一部としてSR-IOVがサポートされているかを確認するためのテストを実行する。

システム構成

SR-IOVをサポートするようにハードウェアプラットフォームを正しく構成します。次のテクノロジーが必要です。

• I/O MMU仮想化（AMD-ViおよびIntel VT-d）

• 代替ルーティングID解釈（ARI）

• アドレス変換サービス（ATS）

• アクセスコントロールサービス（ACS）

上記のテクノロジーを有効にするためのシステムファームウェアの構成方法については、システムに付属のドキュメントを確認してください。

NICでSR-IOVネットワークを有効にする

XenCenterで、NetworkingタブのNew Networkウィザードを使用して、NIC上にSR-IOVネットワークを作成し、有効にします。

仮想インターフェースにSR-IOVネットワークを割り当てる（VMレベル）

XenCenterで、VMレベルで、NetworkingタブのAdd Virtual Interfaceウィザードを使用して、SR-IOV対応ネットワークをそのVMの仮想インターフェースとして追加します。詳細については、Add a New Networkを参照してください。

サポートされるNICとゲスト

サポートされるハードウェアプラットフォームとNICのリストについては、Hardware Compatibility Listを参照してください。特定のゲストがSR-IOVをサポートしているかどうかを判断するには、ベンダーが提供するドキュメントを参照してください。

制限事項

• レガシードライバーを使用する特定のNIC（例：Intel I350ファミリー）の場合、これらのデバイスでSR-IOVを有効または無効にするには、ホストを再起動する必要があります。

• 異なる種類のNICを持つプールレベルのSR-IOVネットワークはサポートされていません。

• 同じNICのSR-IOV VFと通常のVIFは、NICのハードウェア制限により相互に通信できない場合があります。これらのVMが通信できるようにするには、通信がVFからVFまたはVIFからVIFのパターンを使用し、VFからVIFではないことを確認してください。

• 一部のSR-IOV VFでは、ネットワーク速度のレート制限をサポートしていないため、Quality of Service設定が有効になりません。

• SR-IOV VFを使用するVMでは、ライブマイグレーション、サスペンド、チェックポイントの実行はサポートされていません。

• SR-IOV VFはホットプラグをサポートしていません。

• SR-IOV VFはネットワークブートをサポートしていません。

• レガシーNICドライバーを使用する一部のNICでは、ホストの再起動後でも再起動が必要になる場合があります。これは、NICがSR-IOVを有効にできないことを示しています。

• VMにSR-IOV VFがある場合、ライブマイグレーションを必要とする機能は利用できません。これは、VMが物理的なSR-IOV対応NIC VFに直接関連付けられているためです。

• SR-IOVは、高可用性を使用する環境で利用できます。ただし、SR-IOVはキャパシティプランニングでは考慮されません。SR-IOV VFが割り当てられているVMは、適切なリソースを持つホストがプール内に存在する場合、ベストエフォートで再起動されます。これらのリソースには、適切なネットワークでSR-IOVが有効になっていることと、空きVFが含まれます。

• SR-IOV VFはPVS-Acceleratorではサポートされていません。

レガシードライバーのSR-IOV VFを構成する

通常、NICがサポートできるVFの最大数は自動的に決定されます。レガシードライバーを使用するNIC（例：Intel I350ファミリー）の場合、制限はドライバーモジュールの構成ファイル内で定義されます。この制限は手動で調整する必要がある場合があります。最大値に設定するには、エディターを使用してファイルを開き、次の行を変更します。

## VFs-maxvfs-by-user:
<!--NeedCopy-->

例えば、igb ドライバーの最大VF数を4に設定するには、/etc/modprobe.d/igb.conf を次のように編集します。

## VFs-param: max_vfs
## VFs-maxvfs-by-default: 7
## VFs-maxvfs-by-user: 4
options igb max_vfs=0
<!--NeedCopy-->

注記:

• 値は、VFs-maxvfs-by-default の行の値以下である必要があります。

• これらのファイルの他の行は変更しないでください。

• SR-IOVを有効にする前に変更を行ってください。

CLI

SR-IOVネットワークの作成、削除、表示、およびSR-IOV VFをVMに割り当てるためのCLI手順については、SR-IOVコマンドを参照してください。

送信データレートの制御 (QoS)

VMが1秒あたりに送信できる送信データの量を制限するには、VM仮想インターフェース (VIF) でオプションのQuality of Service (QoS) 値を設定します。この設定により、送信パケットの最大送信レートを1秒あたりのキロバイト単位で指定できます。

Quality of Service値は、VMからの送信レートを制限します。Quality of Service設定は、VMが受信できるデータの量を制限しません。そのような制限が必要な場合は、ネットワークの上位（たとえば、スイッチレベル）で受信パケットのレートを制限することをお勧めします。

プールに構成されているネットワークスタックに応じて、VM仮想インターフェース (VIF) のQuality of Service値を2つの場所のいずれかで設定できます。この値は、xe CLIを使用するか、XenCenterで設定できます。

• XenCenter 仮想インターフェースのプロパティダイアログで、Quality of Service送信レート制限値を設定できます。
• xeコマンド 以下のセクションのコマンドを使用して、CLIでQuality of Service送信レートを設定できます。

QoSのCLIコマンドの例

CLIを使用してVIFの最大送信レートを1秒あたり100キロバイトに制限するには、vif-param-setコマンドを使用します。

xe vif-param-set uuid=vif_uuid qos_algorithm_type=ratelimit
xe vif-param-set uuid=vif_uuid qos_algorithm_params:kbps=100
<!--NeedCopy-->

注:

kbpsパラメータは、1秒あたりのキロバイト (kBps) を示し、1秒あたりのキロビット (kbps) ではありません。

ネットワーク構成オプションの変更

このセクションでは、XenServerホストのネットワーク構成を変更する方法について説明します。内容は次のとおりです。

• ホスト名の変更（つまり、ドメインネームシステム（DNS）名）

• DNSサーバーの追加または削除

• IPアドレスの変更

• 管理インターフェースとして使用されるNICの変更

• サーバーへの新しい物理NICの追加

• ネットワークへの目的の追加

• ARPフィルタリングの有効化（スイッチポートロック）

ホスト名

システムのホスト名（ドメイン名またはDNS名とも呼ばれる）は、プール全体のデータベースで定義されており、次のように xe host-set-hostname-live CLIコマンドを使用して変更されます。

xe host-set-hostname-live host-uuid=host_uuid host-name=host-name
<!--NeedCopy-->

基盤となるコントロール ドメインのホスト名は、新しいホスト名を反映するように動的に変更されます。

DNSサーバー

XenServerホストのIPアドレス設定でDNSサーバーを追加または削除するには、pif-reconfigure-ip コマンドを使用します。たとえば、静的IPを持つPIFの場合：

xe pif-reconfigure-ip uuid=pif_uuid mode=static DNS=new_dns_ip IP=IP netmask=netmask
<!--NeedCopy-->

スタンドアロンホストのIPアドレス設定の変更

xe CLIを使用してネットワークインターフェース設定を変更できます。基盤となるネットワーク設定スクリプトを直接変更しないでください。

PIFのIPアドレス設定を変更するには、pif-reconfigure-ip CLIコマンドを使用します。pif-reconfigure-ip コマンドのパラメーターの詳細については、pif-reconfigure-ip を参照してください。リソースプールでのホストIPアドレスの変更に関する情報については、次のセクションを参照してください。

リソースプール内のIPアドレス設定を変更する

リソースプール内のXenServerホストは、管理およびプール内の他のホストとの通信に使用される単一の管理IPアドレスを持っています。ホストの管理インターフェースのIPアドレスを変更するために必要な手順は、プールコーディネーターと他のホストで異なります。

注:

ホストのIPアドレスやその他のネットワークパラメータを変更する際は注意が必要です。ネットワークトポロジや変更内容によっては、ネットワークストレージへの接続が失われる可能性があります。この場合、XenCenterのストレージの修復機能を使用するか、pbd-plug CLIコマンドを使用してストレージを再接続する必要があります。このため、IP構成を変更する前に、VMをホストから移行することをお勧めします。

pif-reconfigure-ip CLIコマンドを使用して、IPアドレスを希望どおりに設定します。pif-reconfigure-ipコマンドのパラメータの詳細については、pif-reconfigure-ipを参照してください。:

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

host-list CLIコマンドを使用して、プール内の他のすべてのXenServerホストが表示されていることを確認し、メンバーホストがプールコーディネーターに正常に再接続されたことを確認します。

xe host-list
<!--NeedCopy-->

プールコーディネーターのXenServerホストのIPアドレスを変更するには、追加の手順が必要です。これは、各プールメンバーが通信のためにプールコーディネーターの通知されたIPアドレスを使用するためです。IPアドレスが変更されると、プールメンバーはプールコーディネーターに連絡する方法がわからなくなります。

可能な限り、プールコーディネーターには、プールの存続期間中に変更される可能性が低い専用のIPアドレスを使用してください。

pif-reconfigure-ip CLIコマンドを使用して、IPアドレスを希望どおりに設定します。

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

プールコーディネーターのIPアドレスが変更されると、すべてのメンバーホストはプールコーディネーターに連絡できなくなり、緊急モードに入ります。

プールコーディネーターで、pool-recover-slavesコマンドを使用して、プールコーディネーターが各プールメンバーに連絡し、新しいプールコーディネーターのIPアドレスを通知するように強制します。

xe pool-recover-slaves
<!--NeedCopy-->

管理インターフェース

ホストにXenServerをインストールすると、そのNICの1つが管理インターフェースとして指定されます。これはXenServerの管理トラフィックに使用されるNICです。管理インターフェースは、XenCenterからホストへの接続（Citrix Virtual Apps and Desktops™など）やホスト間の通信に使用されます。

pif-listコマンドを使用して、管理インターフェースとして使用するNICに対応するPIFを特定します。各PIFのUUIDが返されます。

xe pif-list
<!--NeedCopy-->

pif-param-listコマンドを使用して、管理インターフェースに使用されるPIFのIPアドレス設定を確認します。必要に応じて、pif-reconfigure-ipコマンドを使用して、使用するPIFのIPアドレス設定を構成します。

xe pif-param-list uuid=pif_uuid
<!--NeedCopy-->

管理インターフェースに使用されるPIFを変更するには、host-management-reconfigure CLIコマンドを使用します。このホストがリソースプールの一部である場合、このコマンドはメンバーホストのコンソールで発行する必要があります:

xe host-management-reconfigure pif-uuid=pif_uuid
<!--NeedCopy-->

プール内のすべてのホストの管理インターフェースとして使用されるNICに対応するPIFを特定するには、network-list コマンドを使用します。プール全体のネットワークのUUIDが返されます。

xe network-list
<!--NeedCopy-->

プール内のすべてのホストのPIF UUIDを取得するには、network-param-list コマンドを使用します。管理インターフェースのPIFのIPアドレス設定を確認するには、pif-param-list コマンドを使用します。必要に応じて、使用するPIFのIPアドレス設定を行うには、pif-reconfigure-ip コマンドを使用します。

xe pif-param-list uuid=pif_uuid
<!--NeedCopy-->

ネットワークリストに表示されている管理インターフェースに使用されるPIFを変更するには、pool-management-reconfigure CLIコマンドを使用します。

xe pool-management-reconfigure network-uuid=network_uuid
<!--NeedCopy-->

ポート80の使用を制限する

XenServerとの通信には、ポート443経由のHTTPSまたはポート80経由のHTTPを使用できます。セキュリティ上の理由から、管理インターフェースのTCPポート80を閉じることができます。デフォルトでは、ポート80は開いたままです。ポートを閉じると、管理インターフェースを使用する外部クライアントは、XenServerに接続するためにポート443経由のHTTPSを使用する必要があります。ただし、ポート80を閉じる前に、すべてのAPIクライアント（特にCitrix Virtual Apps and Desktops）がポート443経由のHTTPSを使用できることを確認してください。

ポート80を閉じるには、https-only xe CLIコマンド、またはXenCenterドキュメントのChange Pool Propertiesを参照してください。

管理アクセスを無効にする

管理コンソールへのリモートアクセスを完全に無効にするには、host-management-disable CLIコマンドを使用します。

警告:

管理インターフェースが無効になっている場合、管理タスクを実行するには物理ホストコンソールにログインする必要があります。管理インターフェースが無効になっている場合、XenCenterなどの外部インターフェースは機能しません。

新しい物理NICを追加する

1. 通常の方法で、XenServerホストに新しい物理NICをインストールします。
2. XenServerホストを再起動します。

3. 次のコマンドを使用して、そのXenServerホストのすべての物理NICを一覧表示します。

   xe pif-list host-uuid=<host_uuid>
   

4. 追加のNICが表示されない場合は、次のコマンドを使用して新しい物理インターフェースをスキャンします。

   xe pif-scan host-uuid=<host_uuid>
   

   このコマンドは、新しいNICの新しいPIFオブジェクトを作成します。

5. 新しいNICが表示されていることを確認するために、XenServerホスト上の物理NICを再度リストします。

   xe pif-list host-uuid=<host_uuid>
   

6. 新しいPIFは最初、切断済み (currently-attached ( RO): false) としてリストされます。これを有効にするには、次のコマンドを使用します。

   xe pif-plug uuid=<uuid_of_pif>
   

または、XenCenterを使用して新しいNICを再スキャンすることもできます。詳細については、XenCenterドキュメントのNICの構成を参照してください。

物理NICを削除する

NICを削除する前に、対応するPIFのUUIDを把握していることを確認してください。通常の方法でXenServerホストから物理NICを削除します。ホストを再起動した後、xe CLIコマンド pif-forget uuid=<UUID> を実行してPIFオブジェクトを破棄します。

ネットワークに目的を追加する

ネットワークの目的は、ネットワークに追加機能を追加するために使用できます。たとえば、NBD接続を行うためにネットワークを使用する機能などです。

ネットワークの目的を追加するには、xe network-param-add コマンドを使用します。

xe network-param-add param-name=purpose param-key=purpose uuid=network-uuid
<!--NeedCopy-->

ネットワークの目的を削除するには、xe network-param-remove コマンドを使用します。

xe network-param-remove param-name=purpose param-key=purpose uuid=network-uuid
<!--NeedCopy-->

現在、ネットワークの目的として利用可能な値は nbd と insecure_nbd です。詳細については、XenServer Changed Block Tracking Guide を参照してください。

スイッチポートロックを使用する

XenServerのスイッチポートロック機能を使用すると、不明な、信頼できない、または潜在的に悪意のあるVMが、割り当てられていないMACアドレスやIPアドレスを持っているかのように偽装する能力を制限することで、それらのVMから送信されるトラフィックを制御できます。ポートロックコマンドを使用して、デフォルトですべてのネットワークトラフィックをブロックしたり、個々のVMがトラフィックを送信することを許可する特定のIPアドレスを定義したりできます。

スイッチポートロックを使用すると、すべてのテナントまたはゲストが同じレイヤー2ネットワークを使用できるようにすることで、ネットワーク構成を簡素化できます。

ポートロックコマンドの最も重要な機能の1つは、信頼されていないゲストが送信するトラフィックを制限できることです。これにより、ゲストが実際に所有していないMACアドレスやIPアドレスを持っているかのように偽装する能力が制限されます。具体的には、これらのコマンドを使用して、ゲストが次のことを行うのを防ぐことができます。

• XenServer管理者が使用を許可したIPアドレスまたはMACアドレス以外のものを要求すること

• 他のVMのトラフィックを傍受、偽装、または妨害すること

要件

• XenServerのスイッチポートロック機能は、Linuxブリッジ（非推奨）およびvSwitchネットワークスタックでサポートされています。

• 環境でロールベースアクセス制御（RBAC）を有効にしている場合、スイッチポートロックを設定するユーザーは、少なくともプールオペレーターまたはプール管理者ロールを持つアカウントでログインする必要があります。環境でRBACが有効になっていない場合、ユーザーはプールコーディネーターのrootアカウントでログインする必要があります。

• スイッチポートロックコマンドを実行するとき、ネットワークはオンラインでもオフラインでもかまいません。

• Windowsゲストでは、切断されたネットワークアイコンは、XenServer VM Toolsがゲストにインストールされている場合にのみ表示されます。

注記

スイッチポートロック設定がない場合、VIFは「network_default」に設定され、ネットワークは「unlocked」に設定されます。

環境でサードパーティ製コントローラーが使用されている場合、スイッチポートロックの設定はサポートされません。

スイッチポートロックは、クラウドテナントが次のことを行うのを防ぎません。

• 他のテナント/ユーザーに対してIPレベルの攻撃を実行すること。ただし、スイッチポートロックが構成されており、クラウド内の別のテナントまたはユーザーになりすます、または別のユーザー宛てのトラフィックの傍受を開始する、という以下の手段を使用してIPレベルの攻撃を実行しようとする場合は、スイッチポートロックによってそれが防止されます。

• ネットワークリソースを使い果たすこと。

• 通常のスイッチフラッディング動作（ブロードキャストMACアドレスまたは不明な宛先MACアドレスの場合）を介して、他の仮想マシン宛てのトラフィックの一部を受信すること。

同様に、スイッチポートロックはVMがトラフィックを送信できる場所を制限しません。

実装に関する注意

スイッチポートロック機能は、コマンドラインまたはXenServer APIを使用して実装できます。ただし、自動化が主な関心事である大規模な環境では、APIを使用するのが最も一般的な実装方法となるでしょう。

例

このセクションでは、スイッチポートロックが特定の種類の攻撃をどのように防ぐことができるかの例を示します。これらの例では、VM-cは敵対的なテナント（テナントC）がリースし、攻撃に使用している仮想マシンです。VM-aとVM-bは、攻撃を行わないテナントがリースしている仮想マシンです。

例1：スイッチポートロックによるARPスプーフィング防止の仕組み：

ARPスプーフィングは、攻撃者が自身のMACアドレスを別のノードのIPアドレスに関連付けようとする試みを示すために使用されます。ARPスプーフィングは、ノードのトラフィックが代わりに攻撃者に送信される結果となる可能性があります。この目的を達成するために、攻撃者は偽の（スプーフィングされた）ARPメッセージをイーサネットLANに送信します。

シナリオ：

仮想マシンA（VM-a）は、VM-bのIPアドレス宛にIPトラフィックをVM-aから仮想マシンB（VM-b）に送信したいと考えています。仮想マシンCの所有者は、ARPスプーフィングを使用して、自身のVMであるVM-cが実際にはVM-bであると偽装したいと考えています。

1. VM-cは、推測的なARP応答のストリームをVM-aに送信します。ARP応答は、応答内のMACアドレス（c_MAC）がIPアドレスb_IPに関連付けられていると主張します。

   結果：管理者がスイッチポートロックを有効にしているため、スイッチポートロックを有効にすることでなりすましが防止されるため、これらのパケットはすべて破棄されます。

2. VM-bは、応答内のMACアドレス（b_MAC）がIPアドレスb_IPに関連付けられていると主張して、ARP応答をVM-aに送信します。

   結果：VM-aはVM-bのARP応答を受信します。

例2：IPスプーフィング防止：

IPアドレススプーフィングは、偽造された送信元IPアドレスを持つインターネットプロトコル（IP）パケットを作成することにより、パケットの身元を隠蔽するプロセスです。

シナリオ:

テナントCは、自身の身元を隠すために、ホストHost-Cを使用してリモートシステムに対してサービス拒否攻撃を実行しようとしています。

試行1:

テナントCは、Host-CのIPアドレスとMACアドレスをVM-aのIPアドレスとMACアドレス（a_IPおよびa_MAC）に設定します。テナントCはHost-CにリモートシステムへIPトラフィックを送信するよう指示します。

結果: Host-Cのパケットは破棄されます。これは、管理者がスイッチポートロックを有効にしているためです。スイッチポートロックを有効にすることでなりすましが防止されるため、Host-Cのパケットは破棄されます。

試行2:

テナントCは、Host-CのIPアドレスをVM-aのIPアドレス（a_IP）に設定し、元のc_MACを保持します。

テナントCはHost-CにリモートシステムへIPトラフィックを送信するよう指示します。

結果: Host-Cのパケットは破棄されます。これは、管理者がスイッチポートロックを有効にしており、なりすましを防止しているためです。

例3: ウェブホスティング:

シナリオ:

アリスはインフラストラクチャ管理者です。

彼女のテナントの1つであるテナントBは、自身のVMであるVM-bから複数のウェブサイトをホストしています。各ウェブサイトは、同じ仮想ネットワークインターフェース（VIF）上でホストされる個別のIPアドレスを必要とします。

アリスは、Host-BのVIFを、単一のMACにロックしつつ複数のIPアドレスを使用できるように再構成します。

スイッチポートロックの仕組み

スイッチポートロック機能を使用すると、次の2つのレベルのいずれか、または両方でパケットフィルタリングを制御できます。

• VIFレベル。VIFで構成する設定によって、パケットのフィルタリング方法が決まります。VIFを設定して、VMがトラフィックを送信するのを防いだり、割り当てられたIPアドレスを使用してのみトラフィックを送信するようにVIFを制限したり、VIFに接続されたネットワーク上の任意のIPアドレスにVMがトラフィックを送信できるようにしたりできます。

• ネットワークレベル。XenServerネットワークは、パケットのフィルタリング方法を決定します。VIFのロックモードがnetwork_defaultに設定されている場合、許可するトラフィックを決定するためにネットワークレベルのロック設定を参照します。

どのネットワークスタックを使用しているかに関係なく、この機能は同じように動作します。ただし、以下のセクションで詳しく説明するように、Linuxブリッジ（非推奨）はIPv6でのスイッチポートロックを完全にサポートしていません。

VIFロックモードの状態

XenServerのスイッチポートロック機能は、VIFを4つの異なる状態で構成できるロックモードを提供します。これらの状態は、VIFが実行中の仮想マシンに接続されている場合にのみ適用されます。

• Network_default。VIFの状態がnetwork_defaultに設定されている場合、XenServerはネットワークのdefault-locking-modeパラメーターを使用して、VIFを通過するパケットをフィルタリングするかどうか、およびその方法を決定します。動作は、関連するネットワークのネットワークデフォルトロックモードパラメーターがdisabledまたはunlockedに設定されているかどうかによって異なります。

  -default-locking-mode=disabledの場合、XenServerはフィルタリングルールを適用し、VIFがすべてのトラフィックを破棄するようにします。

  -default-locking-mode=unlockedの場合、XenServerはVIFに関連付けられているすべてのフィルタリングルールを削除します。デフォルトでは、デフォルトのロックモードパラメーターはunlockedに設定されています。

  default-locking-modeパラメーターの詳細については、ネットワークコマンドを参照してください。

  ネットワークのデフォルトロックモードは、ロック状態がnetwork_default以外の接続されたVIFには影響しません。

  注:

  アクティブなVIFが接続されているネットワークのdefault-locking-modeを変更することはできません。

• Locked。XenServerはフィルタリングルールを適用し、指定されたMACアドレスとIPアドレスとの間で送受信されるトラフィックのみがVIFを介して送信されることを許可します。このモードでは、IPアドレスが指定されていない場合、VMはそのVIFを介して、そのネットワーク上でトラフィックを送信できません。

  VIFがトラフィックを受け入れるIPアドレスを指定するには、ipv4_allowedまたはipv6_allowedパラメーターを使用してIPv4またはIPv6 IPアドレスを使用します。ただし、Linuxブリッジ（非推奨）が構成されている場合は、IPv6アドレスを入力しないでください。

  Linuxブリッジがアクティブな場合、XenServerはIPv6アドレスを入力できます。ただし、XenServerは入力されたIPv6アドレスに基づいてフィルタリングできません。その理由は、Linuxブリッジには近隣探索プロトコル (NDP) パケットをフィルタリングするモジュールがないためです。したがって、完全な保護を実装できず、ゲストはNDPパケットを偽造することで他のゲストになりすますことができます。結果として、IPv6アドレスを1つでも指定すると、XenServerはすべてのIPv6トラフィックをVIFを介して通過させます。IPv6アドレスを指定しない場合、XenServerはIPv6トラフィックをVIFに通過させません。

  注:

  Linuxブリッジネットワークスタックは非推奨であり、将来のリリースで削除されます。

• ロック解除済み。すべてのネットワークトラフィックはVIFを通過できます。つまり、VIFに出入りするトラフィックにはフィルターが適用されません。

• 無効。VIFを介してトラフィックを通過させることはできません。（つまり、XenServerはVIFがすべてのトラフィックを破棄するようにフィルタリングルールを適用します。）

スイッチポートロックの構成

このセクションでは、3つの異なる手順について説明します。

• VIFが特定のIPアドレスを使用するように制限する

• 既存の制限リストにIPアドレスを追加します。たとえば、VMが実行中でネットワークに接続されているときにVIFにIPアドレスを追加する場合（一時的にネットワークをオフラインにする場合など）。

• 既存の制限リストからIPアドレスを削除する

VIFのロックモードがlockedに設定されている場合、ipv4-allowedまたはipv6-allowedパラメーターで指定されたアドレスのみを使用できます。

比較的まれなケースではありますが、VIFが複数のIPアドレスを持つ場合があるため、VIFに複数のIPアドレスを指定することが可能です。

これらの手順は、VIFが接続される前（またはVMが起動される前）でも後でも実行できます。

デフォルトのロックモードがまだそのモードを使用していない場合は、次のコマンドを実行してロックモードに変更します。

xe vif-param-set uuid=vif-uuid locking-mode=locked
<!--NeedCopy-->

vif-uuid は、トラフィックの送信を許可する VIF の UUID を表します。UUID を取得するには、ホストで xe vif-list コマンドを実行します。vm-uuid は、情報が表示される仮想マシンを示します。デバイス ID は、VIF のデバイス番号を示します。

仮想マシンがトラフィックを送信できる IP アドレスを指定するには、vif-param-set コマンドを実行します。次のいずれか、または複数を実行します。

• 1つ以上のIPv4 IPアドレスの宛先を指定します。例：

   xe vif-param-set uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
   <!--NeedCopy-->
  

• 1つ以上のIPv6 IPアドレスの宛先を指定します。例：

   xe vif-param-set uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
   <!--NeedCopy-->
  

前の例に示すように、複数のIPアドレスをコンマで区切って指定できます。

VIF を特定の IP アドレスの使用に制限する手順を実行した後、VIF が使用できる IP アドレスを 1 つ以上追加できます。

既存のリストに IP アドレスを追加するには、vif-param-add コマンドを実行します。次のいずれか、または複数を実行します。

• IPv4 IPアドレスを指定します。例：

   xe vif-param-add uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
   <!--NeedCopy-->
  

• IPv6 IPアドレスを指定します。例：

   xe vif-param-add uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
   <!--NeedCopy-->
  

VIF を 2 つ以上の IP アドレスの使用に制限している場合、それらの IP アドレスのいずれかをリストから削除できます。

既存のリストから IP アドレスを削除するには、vif-param-remove コマンドを実行します。次のいずれか、または複数を実行します。

• 削除するIPv4 IPアドレスを指定します。例：

   xe vif-param-remove uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
   <!--NeedCopy-->
  

• 削除するIPv6 IPアドレスを指定します。例：

   xe vif-param-remove uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
   <!--NeedCopy-->
  

仮想マシンが特定のネットワークからトラフィックを送受信するのを防ぐ

次の手順では、仮想マシンが特定の VIF を介して通信するのを防ぎます。VIF は特定の XenServer ネットワークに接続するため、この手順を使用して、仮想マシンが特定のネットワークからトラフィックを送受信するのを防ぐことができます。これにより、ネットワーク全体を無効にするよりも詳細なレベルの制御が可能になります。

CLIコマンドを使用する場合、VIFのロックモードを設定するためにVIFを抜き差しする必要はありません。コマンドはVIFの実行中にフィルタリングルールを変更します。この場合、ネットワーク接続はまだ存在するように見えますが、VIFはVMが送信しようとするすべてのパケットを破棄します。

ヒント:

VIFのUUIDを見つけるには、ホストでxe vif-list コマンドを実行します。デバイスIDはVIFのデバイス番号を示します。

VIFがトラフィックを受信しないようにするには、VMがトラフィックを受信するのを停止したいネットワークに接続されているVIFを無効にします。

xe vif-param-set uuid=vif-uuid locking-mode=disabled
<!--NeedCopy-->

XenCenterでVIFを無効にするには、VMの「ネットワーク」タブで仮想ネットワークインターフェースを選択し、「無効化」をクリックします。

VIFのIPアドレスへの制限を解除する

デフォルト（元の）ロックモードの状態に戻すには、以下の手順を使用します。デフォルトでは、VIFを作成すると、XenServerは特定のIPアドレスの使用に制限されないようにVIFを構成します。

VIFをロック解除状態に戻すには、VIFのデフォルトロックモードを「ロック解除」に変更します。すでにそのモードを使用していない場合は、次のコマンドを実行します。

xe vif-param-set uuid=vif_uuid locking-mode=unlocked
<!--NeedCopy-->

クラウドでのVIFロックモード構成を簡素化する

各VIFに対してVIFロックモードコマンドを実行する代わりに、すべてのVIFがデフォルトで無効になるようにすることができます。そのためには、ネットワークレベルでパケットフィルタリングを変更する必要があります。パケットフィルタリングを変更すると、前のセクション「スイッチポートロックの仕組み」で説明されているように、XenServerネットワークがパケットのフィルタリング方法を決定します。

具体的には、ネットワークのdefault-locking-mode 設定は、デフォルト設定の新しいVIFがどのように動作するかを決定します。VIFのlocking-mode がdefault に設定されている場合、VIFはネットワークロックモード (default-locking-mode) を参照して、VIFを通過するパケットをフィルタリングするかどうか、およびその方法を決定します。

• ロック解除済み。ネットワークのdefault-locking-mode パラメーターがunlocked に設定されている場合、XenServerはVMがVIFが接続するネットワーク上の任意のIPアドレスにトラフィックを送信することを許可します。

• 無効。default-locking-mode パラメーターがdisabled に設定されている場合、XenServerはVIFがすべてのトラフィックを破棄するようにフィルタリングルールを適用します。

デフォルトでは、XenCenterで作成され、CLIを使用するすべてのネットワークのdefault-locking-mode はunlocked に設定されています。

VIFのロックモードをデフォルト (network_default) に設定することで、特定のネットワークに接続するすべての新しく作成されたVIFに対して、基本的なデフォルト構成（ネットワークレベルで）を作成できます。

この図は、VIFのlocking-modeがデフォルト設定（network_default）に設定されている場合、VIFがネットワークdefault-locking-modeを使用してその動作を決定する方法を示しています。

VIFがデフォルト設定（locking-mode=network_default）で構成されている場合、default-locking-modeに関連付けられた設定を確認する方法を示す図です。この図では、ネットワークがdefault-locking-mode=disabledに設定されているため、VIFを介してトラフィックが通過できません。](/en-us/xenserver/8/media/networking-cloud-network-vif-locking-mode.png)

たとえば、デフォルトでは、VIFはlocking-modeがnetwork_defaultに設定された状態で作成されます。ネットワークのdefault-locking-modeをdisabledに設定すると、ロックモードが構成されていない新しいVIFはすべて無効になります。VIFは、(a)個々のVIFのlocking-modeパラメーターを変更するか、(b)VIFのlocking-modeを明示的に`unlocked. に設定するまで、無効のままです。これは、特定のVMを十分に信頼しており、そのトラフィックをまったくフィルタリングしたくない場合に役立ちます。

ネットワークのデフォルトロックモード設定を変更するには：

ネットワークを作成した後、次のコマンドを実行してデフォルトロックモードを変更します。

xe network-param-set uuid=network-uuid default-locking-mode=[unlocked|disabled]
<!--NeedCopy-->

注：

ネットワークのUUIDを取得するには、xe network-listコマンドを実行します。このコマンドは、コマンドを実行したホスト上のすべてのネットワークのUUIDを表示します。

ネットワークのデフォルトロックモード設定を確認するには：

次のいずれかのコマンドを実行します。

xe network-param-get uuid=network-uuid param-name=default-locking-mode
<!--NeedCopy-->

または

xe network-list uuid=network-uuid params=default-locking-mode
<!--NeedCopy-->

VIFトラフィックフィルタリングにネットワーク設定を使用する

次の手順では、仮想マシン上のVIFが、トラフィックをフィルタリングする方法を決定するために、ネットワーク自体のXenServerネットワークdefault-locking-mode設定を使用するように指示します。

1. VIFロック状態がまだそのモードを使用していない場合は、次のコマンドを実行してnetwork_defaultに変更します。

   xe vif-param-set uuid=vif_uuid locking-mode=network_default
   <!--NeedCopy-->
   

2. デフォルトロックモードがまだそのモードを使用していない場合は、次のコマンドを実行してunlockedに変更します。

   xe network-param-set uuid=network-uuid default-locking-mode=unlocked
   <!--NeedCopy-->