ネットワークの管理

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

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

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

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

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

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

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

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

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

この時点では、ネットワークはPIFに接続されておらず、したがって内部ネットワークです。

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

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

プール内のすべてのホストは共通のネットワークセットを共有するため、プール内のXenServerホストに対して同じ物理ネットワーク構成を持つことが重要です。 個々のホスト上のPIFは、デバイス名に基づいてプール全体のネットワークに接続されます。 ネットワークXは、Dom0ネットワーク命名モデルの下で位置Xにあるネットワークインターフェースに対応します。

プール内の他のホストと異なる数のNICを持つXenServerホストがある場合、問題が発生する可能性があります。この問題は、すべてのプールネットワークがすべてのプールホストに対して有効であるとは限らないために発生する可能性があります。たとえば、host1とhost2が同じプールにあり、host1が4つのNICを持ち、host2が2つしか持たない場合、host1の最初の2つのネットワークインターフェースに対応するPIFに接続されたネットワークのみがhost2で有効です。残りのネットワークインターフェースに対応するネットワークに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つのサブネットです。

注記：

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 で、ネットワーク タブの 新しいネットワーク ウィザードを使用して、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の最大数は自動的に決定されます。レガシー ドライバー（例：Intel I350ファミリー）を使用するNICの場合、制限はドライバーモジュールの構成ファイル内で定義されます。この制限は手動で調整する必要がある場合があります。最大値に設定するには、エディターを使用してファイルを開き、次の行を変更します。

## 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ホストのネットワーク構成を変更する方法について説明します。これには以下が含まれます。

• ホスト名（つまり、Domain Name System (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-->

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

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

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

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

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

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

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

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

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

XenServer と通信するには、ポート 443 経由の HTTPS またはポート 80 経由の HTTP のいずれかを使用できます。セキュリティ上の理由から、新規インストールではデフォルトでポート 80 は閉じられています。アップグレードでは既存のポート設定が保持されます。

ポート 80 を開閉するには、XenCenter ドキュメントの https-only xe CLI コマンドまたは 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から送信されるトラフィックを制御できます。これは、VMが割り当てられていないMACアドレスやIPアドレスを持っていると偽る能力を制限することによって行われます。ポートロックコマンドを使用すると、デフォルトですべてのネットワークトラフィックをブロックしたり、個々のVMがトラフィックを送信することを許可する特定のIPアドレスを定義したりできます。

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

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

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

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

要件

• 環境でロールベースアクセス制御 (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アドレス宛に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: Webホスティング:

シナリオ:

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

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

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

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

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

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

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

VIFロックモードの状態

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

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

  -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アドレスを使用します。

• Unlocked。すべてのネットワークトラフィックはVIFを通過できます。つまり、VIFとの間で送受信されるトラフィックにはフィルターが適用されません。

• Disabled。VIFを通過するトラフィックは許可されません。(つまり、XenServerはフィルタリングルールを適用し、VIFがすべてのトラフィックを破棄するようにします。)

スイッチポートロックを構成する

このセクションでは、3つの異なる手順を提供します。

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

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

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

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

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

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

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

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アドレスの1つをリストから削除できます。

既存のリストから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の「Networking」タブで仮想ネットワークインターフェイスを選択し、「Deactivate」をクリックします。

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

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

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を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-->