ネットワークの管理

最終公開日 : Oct 07, 2026
このセクションのネットワーク構成手順は、スタンドアロンホストを構成しているか、リソースプールの一部であるホストを構成しているかによって異なります。
Related information
ネットワーク
index

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

ホストのインストール中に各PIFに対して外部ネットワークが作成されるため、追加のネットワークを作成する必要があるのは通常、次の目的の場合のみです。
  • プライベートネットワークを使用する
  • VLANやNICボンディングなどの高度な操作をサポートする
XenCenterを使用してネットワークを追加または削除する方法については、XenCenterドキュメントの「新しいネットワークの追加」を参照してください。
XenServer®ホストのテキストコンソールを開きます。
network-create コマンドを使用してネットワークを作成します。このコマンドは、新しく作成されたネットワークのUUIDを返します。
xe network-create name-label=mynetwork
この時点では、ネットワークは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しか持たない場合、eth0とeth1に対応するPIFに接続されたネットワークのみがhost2で有効です。eth2とeth3に対応するネットワークにVIFが接続されているhost1上のVMは、ホストhost2に移行できません。

VLANの作成

リソースプール内のホストの場合、pool-vlan-create コマンドを使用できます。このコマンドはVLANを作成し、プール内のホストに必要なPIFを自動的に作成してプラグインします。詳細については、pool-vlan-createを参照してください。
XenServerホストコンソールを開きます。
VLANで使用するネットワークを作成します。新しいネットワークのUUIDが返されます。
xe network-create name-label=network5
pif-list コマンドを使用して、目的のVLANタグをサポートする物理NICに対応するPIFのUUIDを見つけます。既存のVLANを含むすべてのPIFのUUIDとデバイス名が返されます。
xe pif-list
新しいVLANに接続するすべてのVMで、目的の物理PIFとVLANタグを指定してVLANオブジェクトを作成します。新しいPIFが作成され、指定されたネットワークに接続されます。新しいPIFオブジェクトのUUIDが返されます。
xe vlan-create network-uuid=network_uuid pif-uuid=pif_uuid vlan=5
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
  2. pif-list コマンドを使用して、ボンディングで使用するPIFのUUIDを特定します。
    xe pif-list
  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
      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

ボンドの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

リソースプールで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
NIC ボンドを作成する で説明されているように、NIC ボンドを作成します。
プールに参加させたいホストでコンソールを開き、次のコマンドを実行します。
xe pool-join master-address=host1 master-username=root master-password=password
ネットワークとボンドの情報は、新しいホストに自動的にレプリケートされます。管理インターフェースは、元々構成されていたホスト NIC からボンディングされた PIF に自動的に移動されます。つまり、管理インターフェースはボンドに吸収され、ボンド全体が管理インターフェースとして機能するようになります。
構成中のホストの UUID を見つけるには、host-list コマンドを使用します。
xe host-list
警告:
高可用性が有効になっている間は、ネットワークボンディングを作成しないでください。ボンディング作成のプロセスは、進行中の高可用性ハートビートを妨害し、ホストが自己フェンス（シャットダウン）する原因となります。ホストが適切に再起動できない場合があり、回復のために host-emergency-ha-disable コマンドを実行する必要があるかもしれません。

専用ストレージNICの構成

XenCenterまたはxe CLIを使用して、NICにIPアドレスを割り当て、ストレージトラフィックなどの特定の機能に専用することができます。NICをIPアドレスで構成する場合、セカンダリインターフェースを作成することで行います。（XenServerが管理に使用するIP対応NICは、管理インターフェースとして知られています。）
特定の目的のためにセカンダリインターフェースを専用したい場合は、適切なネットワーク構成が整っていることを確認してください。これは、NICが目的のトラフィックのみに使用されるようにするためです。NICをストレージトラフィックに専用するには、NIC、ストレージターゲット、スイッチ、およびVLANを構成し、ターゲットが割り当てられたNIC経由でのみアクセスできるようにします。物理およびIP構成がストレージNICを介して送信されるトラフィックを制限しない場合、管理トラフィックなどのトラフィックをセカンダリインターフェース経由で送信できます。
ストレージトラフィック用に新しいセカンダリインターフェースを作成する場合、次のIPアドレスを割り当てる必要があります。
  • 該当する場合、ストレージコントローラーと同じサブネット上にあること、および
  • 他のセカンダリインターフェースまたは管理インターフェースと同じサブネット上にないこと。
セカンダリインターフェースを構成する場合、各セカンダリインターフェースは個別のサブネット上にある必要があります。たとえば、ストレージ用にさらに2つのセカンダリインターフェースを構成したい場合、3つの異なるサブネット上にIPアドレスが必要です。1つは管理インターフェース用、1つはセカンダリインターフェース1用、もう1つはセカンダリインターフェース2用です。
ストレージトラフィックの回復性のためにボンディングを使用している場合は、Linuxブリッジ（非推奨）ボンディングの代わりにLACPの使用を検討してください。LACPボンディングを使用するには、vSwitchをネットワークスタックとして構成する必要があります。詳細については、「ネットワークスタックの選択」を参照してください。
注記：
iSCSIまたはNFS SRで使用するためにセカンダリインターフェースとして構成するNICを選択する際は、専用NICが管理インターフェースからルーティングできない個別のIPサブネットを使用していることを確認してください。これが強制されない場合、ネットワークインターフェースの初期化順序により、ホストの再起動後にストレージトラフィックがメインの管理インターフェース経由でルーティングされる可能性があります。
PIFが別のサブネット上にあるか、または選択したPIF経由で目的のトラフィックを強制するようにルーティングがネットワークトポロジに合わせて構成されていることを確認してください。
PIFのIP構成を設定し、モードパラメーターに適切な値を追加します。静的IPアドレス指定を使用する場合は、IP、ネットマスク、ゲートウェイ、およびDNSパラメーターを追加します。
xe pif-reconfigure-ip mode=DHCP | Static uuid=pif-uuid
PIFのdisallow-unplugパラメーターをtrueに設定します。
xe pif-param-set disallow-unplug=true uuid=pif-uuid
xe pif-param-set other-config:management_purpose="Storage" uuid=pif-uuid
管理インターフェースからもルーティング可能なストレージ用のセカンダリインターフェースを使用したい場合（この構成はベストプラクティスではないことに留意してください）、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で、**「ネットワーク」タブの「新規ネットワーク」**ウィザードを使用して、NIC上にSR-IOVネットワークを作成および有効にします。

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

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

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

サポートされているハードウェアプラットフォームとNICのリストについては、「ハードウェア互換性リスト」を参照してください。特定のゲストが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:
例えば、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
注:
  • 値は、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 commands 以下のセクションのコマンドを使用して、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
注:
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
基盤となる制御ドメインのホスト名は、新しいホスト名を反映するように動的に変更されます。

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

スタンドアロンホストの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
host-list CLIコマンドを使用して、プール内の他のすべてのXenServerホストが表示されていることを確認し、メンバーホストがプールコーディネーターに正常に再接続されたことを確認します。
xe host-list
プールコーディネーターのXenServerホストのIPアドレスを変更するには、追加の手順が必要です。これは、各プールメンバーが通信のためにプールコーディネーターの通知されたIPアドレスを使用するためです。IPアドレスが変更されると、プールメンバーはプールコーディネーターに連絡する方法を知りません。
可能な限り、プールコーディネーターには、プールの存続期間中に変更される可能性が低い専用のIPアドレスを使用してください。
pif-reconfigure-ip CLIコマンドを使用して、必要に応じてIPアドレスを設定します。
xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
プールコーディネーターのIPアドレスが変更されると、すべてのメンバーホストはプールコーディネーターに連絡できなくなり、緊急モードに入ります。
プールコーディネーター上で、pool-recover-slavesコマンドを使用して、プールコーディネーターが各プールメンバーに連絡し、新しいプールコーディネーターのIPアドレスを通知するように強制します。
xe pool-recover-slaves

管理インターフェース

ホストにXenServerをインストールすると、そのNICの1つが管理インターフェースとして指定されます。これはXenServerの管理トラフィックに使用されるNICです。管理インターフェースは、XenCenterからホストへの接続（Citrix Virtual Apps and Desktops™など）やホスト間の通信に使用されます。
pif-listコマンドを使用して、管理インターフェースとして使用するNICに対応するPIFを特定します。各PIFのUUIDが返されます。
xe pif-list
pif-param-listコマンドを使用して、管理インターフェースに使用されるPIFのIPアドレス設定を確認します。必要に応じて、pif-reconfigure-ipコマンドを使用して、使用するPIFのIPアドレスを設定します。
xe pif-param-list uuid=pif_uuid
管理インターフェースに使用されるPIFを変更するには、host-management-reconfigure CLIコマンドを使用します。このホストがリソースプールの一部である場合、このコマンドはメンバーホストのコンソールで発行する必要があります:
xe host-management-reconfigure pif-uuid=pif_uuid
プール内のすべてのホストの管理インターフェースとして使用されるNICに対応するPIFを特定するには、network-list コマンドを使用します。プール全体のネットワークのUUIDが返されます。
xe network-list
プール内のすべてのホストのPIF UUIDを取得するには、network-param-list コマンドを使用します。管理インターフェースのPIFのIPアドレス設定を確認するには、pif-param-list コマンドを使用します。必要に応じて、使用するPIFのIPアドレス設定を行うには、pif-reconfigure-ip コマンドを使用します。
xe pif-param-list uuid=pif_uuid
ネットワークリストに表示されている管理インターフェースに使用されるPIFを変更するには、pool-management-reconfigure CLIコマンドを使用します。
xe pool-management-reconfigure network-uuid=network_uuid

ポート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
ネットワークの目的を削除するには、xe network-param-remove コマンドを使用します。
xe network-param-remove param-name=purpose param-key=purpose uuid=network-uuid
現在、ネットワークの目的に使用できる値は 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レベルの攻撃を実行しようとする場合、スイッチポートロックはそれを防ぎます。a) クラウド内の別のテナントまたはユーザーになりすます、または b) 別のユーザー宛てのトラフィックの傍受を開始する。
  • ネットワークリソースを使い果たすこと。
  • 通常のスイッチフラッディング動作（ブロードキャスト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アドレス宛にVM-aから仮想マシンB（VM-b）へIPトラフィックを送信したいと考えています。仮想マシン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がトラフィックを送信するのを防いだり、VIFを制限して割り当てられたIPアドレスを使用するトラフィックのみを送信できるようにしたり、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 アドレスを入力しないでください。
    XenServer では、Linux ブリッジがアクティブなときに 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
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
  • 1つ以上のIPv6 IPアドレスの宛先を指定します。例:
    xe vif-param-set uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
前の例に示すように、複数の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
  • IPv6 IPアドレスを指定します。例:
    xe vif-param-add uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
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
  • 削除するIPv6 IPアドレスを指定します。例:
    xe vif-param-remove uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses

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

次の手順では、仮想マシンが特定の 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
XenCenterでVIFを無効にするには、VMの「ネットワーク」タブで仮想ネットワークインターフェースを選択し、「無効化」をクリックします。

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

デフォルト（元の）ロックモードの状態に戻すには、以下の手順を使用します。デフォルトでは、VIFを作成すると、XenServerは特定のIPアドレスの使用に制限されないように構成します。
VIFをロック解除状態に戻すには、VIFのデフォルトロックモードを「ロック解除」に変更します。すでにそのモードを使用していない場合は、次のコマンドを実行します。
xe vif-param-set uuid=vif_uuid locking-mode=unlocked

クラウドでの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]
注：
ネットワークのUUIDを取得するには、xe network-listコマンドを実行します。このコマンドは、コマンドを実行したホスト上のすべてのネットワークのUUIDを表示します。
ネットワークのデフォルトロックモード設定を確認するには：
次のいずれかのコマンドを実行します。
xe network-param-get uuid=network-uuid param-name=default-locking-mode
または
xe network-list uuid=network-uuid params=default-locking-mode

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

次の手順では、仮想マシン上のVIFが、トラフィックをフィルタリングする方法を決定するために、ネットワーク自体のXenServerネットワークdefault-locking-mode設定を使用するように指示します。
  1. VIFロック状態がまだそのモードを使用していない場合は、次のコマンドを実行してnetwork_defaultに変更します。
    xe vif-param-set uuid=vif_uuid locking-mode=network_default
  2. デフォルトのロックモードがまだそのモードを使用していない場合は、次のコマンドを実行してunlockedに変更します。
    xe network-param-set uuid=network-uuid default-locking-mode=unlocked