ネットワークの管理

ここで説明するネットワーク設定手順は、スタンドアロンホストとリソースプール内のホストとで異なります。

サーバー間のプライベートネットワーク

以前のバージョンのXenServerでは、同一ホスト上の仮想マシン間でのみ通信が可能な「単一サーバーのプライベートネットワーク」を作成できました。このバージョンでは、この単一サーバーのプライベートネットワークの概念をリソースプールレベルに拡張するサーバー間のプライベートネットワークを作成できます。このプライベートネットワークでは、同一リソースプール内の仮想マシン間での通信が可能です。サーバー間のプライベートネットワークは、単一サーバーのプライベートネットワークの独立性と、リソースプール全体での接続性を兼ね備えています。このネットワークでは、XenMotionによる仮想マシンのライブマイグレーションなどのアジリティ機能も使用できます。

サーバー間のプライベートネットワークは、外部ネットワークから隔離されます。プライベートネットワークに接続していない仮想マシンでは、このネットワーク上にトラフィックを送受信できません。これは、その仮想マシンがほかの仮想マシンと同じ物理ホスト上にあり、同じPIF(物理ネットワークインターフェイス)上のネットワークにVIFが接続されている場合にも当てはまります。VLANでも同様の機能が提供されますが、サーバー間のプライベートネットワークでGRE(Generic Routing Encapsulation)IPトンネリングプロトコルを使用すると、物理スイッチファブリックを設定しなくても、ネットワークを隔離させることができます。

プライベートネットワークでは、物理スイッチファブリックを使用しなくても、以下の特長が提供されます。

  • 単一サーバーのプライベートネットワークと同様の独立したネットワークを構築できる。

  • リソースプール内の複数ホスト間で仮想マシンを移行できる。

  • XenMotionなどの機能を使用できる。

サーバー間のプライベートネットワークは、NICにIPアドレスを割り当てる必要があるため、管理インターフェイスまたはセカンダリインターフェイス上に作成する必要があります。IPアドレスが割り当てられた任意のNICを使用してこのネットワークを作成できます。サーバー間のプライベートネットワークをセカンダリインターフェイス上に作成する場合は、このインターフェイスが隔離されたサブネットに属している必要があります。

管理インターフェイスやほかのセカンダリインターフェイスが同じサブネットに属していると、ネットワークトラフィックが正しくルーティングされません。

注:

サーバー間のプライベートネットワークを作成するには、以下の条件を満たす必要があります。

  • リソースプール内のすべてのホストでXenServer 6.0以降が動作している。

  • リソースプール内のすべてのホストで、ネットワークスタックとしてvSwitchが使用されている。

  • vSwitchコントローラが実行されており、リソースプールが追加されている(vSwitch接続に必要な初期化および構成タスクを行うvSwitch Controllerがリソースプールに設定されている必要があります)。

  • サーバー間のプライベートネットワークは、管理インターフェイスとして設定されたNIC上で作成する必要があります。この管理インターフェイスには、サーバー間のプライベートネットワーク用に作成した、異なるサブネット上のセカンダリインターフェイス(IPが有効なPIF)も含まれます。

vSwitchの設定について詳しくは、「vSwitchとController」を参照してください。プライベートネットワークを作成する方法については、XenCenterのオンラインヘルプを参照してください。

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

ホストのインストール時に各PIFに対して外部ネットワークが作成されるため、追加のネットワーク作成が必要になるのは、通常以下の場合のみです:

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

  • VLANやNICボンディングなどの高度な機能を使用する。

XenCenterを使用してネットワークを追加または削除する方法については、XenCenterのオンラインヘルプを参照してください。

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

次のnetwork-createコマンドを実行してネットワークを作成します。これにより、新規に作成したネットワークのUUIDが返されます:

xe network-create name-label=mynetwork

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

リソースプールでのネットワークの作成

リソースプール内のすべてのXenServerホストで、同数の物理NICが装着されている必要があります。ただし、この要件はホストをプールに追加するときの絶対条件ではありません。

リソースプール内のすべてのホストでネットワークの共通セットが共有されるため、プール内のすべてのXenServerホストで同じ物理ネットワーク設定を使用することは重要です。個々のホスト上のPIFは、デバイス名に基づいたプール全体のネットワークに接続されます。たとえば、eth0 NICを持つすべてのXenServerホストでは、それに対応するPIFがプール全体のNetwork 0ネットワークに接続されます。eth1 NICを持つホストも同様にNetwork 1ネットワークに接続され、プール内の1つ以上のXenServerホストに装着されたほかのNICも同様にネットワークに接続されます。

リソースプール内のXenServerホストでNICの数が異なると、複雑な状況になります。その理由は、一部のプールネットワークが一部のホストに対して有効にならないためです。たとえば、リソースプール内にホストhost1とホストhost2があり、host1に4つのNICが装着されており、host2に2つのNICが装着されている場合、eth0とeth1に対応するPIFに接続されたネットワークだけがhost2上で有効になります。つまり、host1上の仮想マシンがeth2とeth3のネットワークに接続された2つのVIFを持つ場合、この仮想マシンはhost2上に移行できなくなります。

VLANの作成

リソースプール内の複数のホストで使用する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オブジェクトを作成します。このコマンドでは、その新規VLANに接続されるすべての仮想マシン上の物理PIFとVLANタグを指定します。これにより、新しいPIFが作成され、指定したネットワークにプラグされます。また、新しいPIFオブジェクトのUUIDが返されます。

xe vlan-create network-uuid=network_uuid pif-uuid=pif_uuid vlan=5

仮想マシンのVIFを新しいネットワークに接続します。詳しくは、「スタンドアロンサーバーでのネットワークの作成」を参照してください。

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

Citrixは、NICボンディングを作成する場合、XenCenterを使用することをお勧めします。詳しくは、XenCenterのオンラインヘルプを参照してください。

ここでは、xe CLIを使用して、リソースプールに属していない、スタンドアロンXenServerホストのNICボンディングを作成します。リソースプール内のXenServerホストでNICボンディングを作成する方法については、「リソースプールでのNICボンディングの作成」を参照してください。

NICボンディングの作成

管理インターフェイスでNICボンディングを使用する場合、管理インターフェイスで使用しているPIF/NICをボンディングPIFに移動する必要があります。XenServer 6.0以降では、管理インターフェイスが自動的にボンディングのPIFに移動します。

次のnetwork-createコマンドを実行して、NICボンディングで使用するネットワークを作成します。これにより、新しいネットワークのUUIDが返されます。

xe network-create name-label=bond0

次のpif-listコマンドを実行して、ボンディングに使用するPIFのUUIDを検出します:

xe pif-list

次のいずれかを行います。

  • アクティブ/アクティブモードのボンディング(デフォルト)を作成するには、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
    

    ボンディングを構成するNICの数に応じて、2つまたは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アドレス制御

管理インターフェイスでNICボンディングを作成するということは、その管理インターフェイスで使用しているPIF/NICが、ボンディングに含まれることを意味します。ホストでDHCPを使用する場合、ボンディングのMACアドレスは使用中のPIF/NICのものと同じになり、管理インターフェイスのIPアドレスはボンディング作成後も保持されます。

管理インターフェイスとして使用しているNICと異なるMACアドレスをボンディングに設定することもできますが、ボンディングが有効になってMACアドレスやIPアドレスが変更されたときに、そのホストとの既存のネットワークセッションが切断されます。

ボンディングのMACアドレスは、以下の2つの方法で制御できます。

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

  • 管理インターフェイスのボンディングでmacパラメータを指定しない場合、XenServerではその管理インターフェイスのMACアドレスが使用されます。そのほかの管理インターフェイスのボンディングでは、その管理インターフェイスのMACアドレス(およびIPアドレス)が使用されます。非管理インターフェイスのボンディングでは、最初のNICのMACアドレスが使用されます。

NICボンディングを元に戻す

XenServerホストのボンディングを解除する場合は、bond-destroyコマンドにより「プライマリスレーブ」が自動的に管理インターフェイスとして使用されます。このため、すべてのVIFが管理インターフェイスに移動します。ホストの管理インターフェイスがタグ付きVLANにボンディングされたインターフェイス上にある場合、bond-destroyを実行すると、管理VLANはプライマリスレーブに移行します。

「プライマリスレーブ」とは、ボンディング作成時にMACアドレスおよびIP設定の元になったPIFを指します。2つのNICをボンディングする場合、以下のようにプライマリスレーブが決定されます。

  1. ボンディングの一方が管理インターフェイスの場合はそのNIC。

  2. 管理インターフェイスが含まれないボンディングの場合はIPアドレスを持つNIC。

  3. それ以外の場合は最初のNIC。最初のNICは、次のコマンドで確認できます。

    xe bond-list params=all
    

リソースプールでのNICボンディングの作成

リソースプールでのNICボンディングの作成は、リソースプールにホストを追加したり仮想マシンを作成したりした後ではなく、リソースプールの初期作成時に行ってください。これにより、プールに追加するホストにボンディング設定が自動的に適用されるため、必要な手順を減らすことができます。

既存のプールにNICボンディングを作成する場合、以下のいずれかが必要です。

  • CLIでプールマスタ上にボンディングを作成し、さらにほかのホスト上にボンディングを作成する。

  • CLIでプールマスタ上にボンディングを作成し、ほかのホストを再起動する。これにより、プールマスタの設定がすべてのホストに継承されます。

  • XenCenterでプールマスタ上にボンディングを作成する。プールマスタのネットワーク設定がXenCenterによりすべてのホストに同期されます。ホストの再起動も不要です。

操作が簡単であり、不正な設定を防ぐためにも、Citrixは、XenCenterを使用してNICボンディングを作成することをお勧めします。詳しくは、XenCenterのオンラインヘルプを参照してください。

ここでは、xe CLIを使用して、リソースプール内のXenServerホストのNICボンディングを作成します。スタンドアロンホストでNICボンディングを作成する方法については、「スタンドアロンホストでのNICボンディングの作成」を参照してください。

警告:

高可用性機能が有効な場合は、ネットワークボンディングを作成しないでください。ボンディングの作成処理により、実行中の高可用性ハートビートが阻害されて、ホストの自己隔離(つまりシャットダウン)を引き起こします。ホストが正しく再起動しなくなり、復元するにはhost-emergency-ha-disableコマンドを実行する必要がある場合があります。

新しいリソースプールのプールマスタとして動作させるホストを選択します。XenServerホストは、デフォルトで名前のないリソースプールに属します。リソースプールを作成するには、次のコマンドを実行して、名前のないリソースプールに名前を設定します。

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に移動します。これにより、このボンディング全体が管理インターフェイスとして動作します。

次のhost-listコマンドを実行して、そのホストのUUIDを確認します:

xe host-list

警告:

高可用性機能が有効な場合は、ネットワークボンディングを作成しないでください。ボンディングの作成処理により、実行中の高可用性ハートビートが阻害されて、ホストの自己隔離(つまりシャットダウン)を引き起こします。ホストが正しく再起動しなくなり、復元するにはhost-emergency-ha-disableコマンドを実行する必要がある場合があります。

ストレージ専用NICの設定

ストレージなどの特定機能専用のNICを設定するには、XenCenterまたはxe CLIを使用してそのNICにIPアドレスを割り当てます。NICにIPアドレスを割り当てると、セカンダリインターフェイスが作成されます(IPアドレスが割り当てられるNICのうち、XenServerを管理するために使用される管理インターフェイスを「管理インターフェイス」と呼びます)。

セカンダリインターフェイスに特定の機能を割り当てる場合、適切なネットワーク設定を行う必要があります。これは、NICがほかの用途に使用されないようにするためです。NICをストレージトラフィック専用にするには、ストレージターゲットにそのNICからしかアクセスできないように、NIC、ストレージターゲット、スイッチ、およびVLANを設定する必要があります。つまり、ストレージ用のNICで送信するトラフィックを、物理的な構成やIPアドレスの設定により制限します。これにより、そのNICにほかのトラフィック(管理トラフィックなど)が送信されることを防ぎます。

ストレージトラフィック用のセカンダリインターフェイスを作成するには、次の条件を満たすIPアドレスを割り当てる必要があります:

  • 使用する記憶域コントローラーと同じサブネットに属し、

  • ほかのセカンダリインターフェイスや管理インターフェイスとは異なるサブネットに属しています。

複数のセカンダリインターフェイスを作成する場合は、各インターフェイスが個別のサブネットに属している必要があります。たとえば、ストレージトラフィック用のセカンダリインターフェイスを2つ追加する場合、3つの異なるサブネットに属するIPアドレスが必要です。つまり、管理インターフェイスのサブネット、1つ目のセカンダリインターフェイスのサブネット、および2つ目のセカンダリインターフェイスのサブネットです。

ストレージトラフィックの耐障害性を高めるためにボンディングを使用する場合は、LinuxブリッジボンディングではなくLACPを使用することを検討してください。LACPボンディングを使用するには、ネットワークスタックとしてvSwitchを設定する必要があります。詳しくは、「vSwitchネットワーク」を参照してください。

注:

iSCSIまたはNFSのストレージリポジトリで使用するセカンダリインターフェイスのNICを選択する場合、そのNICのIPサブネットが管理インターフェイスからルーティングできない隔離されたものである必要があります。ネットワークが隔離されていない場合、ホストを再起動した後のネットワークインターフェイスの初期化順序によっては、管理インターフェイスを経由してストレージトラフィックが送信される可能性があります。

PIFが別のサブネット上にあること、またはそのPIF経由で目的のトラフィックが転送されるようにネットワークトポロジに適したルーティングが設定されていることを確認します。

次のコマンドを実行して、そのPIFのIP設定を行います。このコマンドでは、modeパラメーターに適切な値を設定し、静的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の使用

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

1つまたは複数のNIC VFを仮想マシンに割り当てると、ネットワークトラフィックが仮想スイッチをバイパスできます。このように設定すると、各仮想マシンがNICを直接使用しているかのように動作するため、処理のオーバーヘッドが軽減されてパフォーマンスが向上します。

SR-IOVの利点

SR-IOV VFはVIFよりも優れたパフォーマンスを提供します。同じNICを経由する(XenServerネットワークスタックをバイパス)異なる仮想マシンからのトラフィックをハードウェアベースで分離できます。

この機能を使用することで、以下のことを実行できます:

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

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

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

  • 仮想マシンにSR-IOV VFを割り当てます。

  • SR-IOV VFを構成します(MACアドレス、VLAN、レートなど)。

  • SR-IOVがAutomated Certification Kitの一部としてサポートされているかを確認するテストを実行します。

システム構成

SR-IOVをサポートするには、ハードウェアプラットフォームを正しく構成する必要があります。次の技術が必要です:

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

  • Alternative Routing ID Interpretation(ARI)

  • Address Translation Services(ATS)

  • Access Control Services(ACS)

前述のテクノロジーを有効にするようにBIOSを構成する方法については、システム付属のマニュアルを参照してください。

NICでのSR-IOVネットワーク有効化

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

仮想インターフェイス(仮想マシンレベル)へのSR-IOVネットワーク割り当て

XenCenterの仮想マシンレベルで、[ネットワーク]タブの[仮想インターフェイスの追加]ウィザードを使用して、この仮想マシンの仮想インターフェイスとしてSR-IOV対応ネットワークを追加します。詳しくは、XenCenterのオンラインヘルプを参照してください。

サポートされているNICおよびゲスト

サポートされているハードウェアプラットフォームとNICの一覧については、ハードウェア互換性リストを参照してください。特定のゲストがSR-IOVをサポートしているかを判断するには、ベンダーが提供するマニュアルを参照してください。

制限事項

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

  • SR-IOVではHVMゲストのみがサポートされています。

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

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

  • 一部のSR-IOV VFのQoS(サービス品質)設定は、ネットワーク速度の制限をサポートしていないため、有効になりません。

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

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

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

  • 以前のリリースで作成された仮想マシンでは、XenCenterのこの機能を使用できません。

  • 仮想マシンにSR-IOV VFがある場合、ライブマイグレーションが必要な機能は使用できません。これは、仮想マシンが物理的なSR-IOV対応NICのVFに直接関連付けられるためです。SR-IOV VFで送信される仮想マシンネットワークトラフィックは、vSwitchをバイパスします。このため、ACLやQoS(サービス品質)などの機能を使用できません。

  • ハードウェア制限:ハイパーバイザーから機能レベルリセット(FLR)の実行を要求された場合、SR-IOV機能はControllerを使用してデバイスの機能を100ミリ秒以内に初期状態にリセットします。

  • SR-IOVは、高可用性を活用する環境で使用できます。ただし、容量計画ではSR-IOVは考慮されません。SR-IOV VFが割り当てられた仮想マシンは、適切なリソースを持つプール内にホストがある場合、ベストエフォート方式で再起動します。これらのリソースには、適切なネットワーク上で有効になっているSR-IOV、および空きVFが含まれます。

レガシードライバー用のSR-IOV VFの構成

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

## 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の仮想マシンへの割り当てについては、「SR-IOVコマンド」を参照してください。

出力データレート(QoS)の制御

仮想マシンが1秒間に送信可能な出力データ量を仮想インターフェイス(VIF)に設定して、QoS(Quality of Service:サービス品質)を制御できます。このQoS値は、出力パケットの最大転送レートを1秒あたりのキロバイト単位で設定します。

この値で制御されるのは、仮想マシンからの出力(送信)転送レートのみです。仮想マシンの受信データ量は制限されません。Citrixでは、受信データ量を制御する場合、ネットワークレベル(スイッチなど)で入力パケットを制限することをお勧めします。

VIFのQoS値を設定するには、リソースプールのネットワークスタック構成に応じて、vSwitch ControllerまたはXenServer(XenCenterまたはCLIによる)を使用します。

vSwitch

構成方法は次のとおりです:

  • vSwitch Controller - ネットワークスタックとしてvSwitchを使用する場合は、これが最適な設定方法です。vSwitchスタックが使用される環境では、XenCenterのQoSオプションを使用できません。
  • xeコマンド - xeコマンドでQoS転送レートを設定することもできます。後述の例を参照してください。ただし、vSwitchコントローラのユーザーインターフェイスを使用した方が詳細に制御できます。

Linuxブリッジ

設定方法:

  • XenCenter - [仮想インターフェイスプロパティ]ダイアログボックスで、QoS転送レートの上限値を設定できます。
  • xeコマンド - xeコマンドでQoS転送レートを設定することもできます。後のセクションを参照してください。

重要:

ネットワークスタックとしてvSwitchを使用する環境で、vSwitch ControllerXenServerホストで矛盾したQoS値を設定することができます。この場合、XenServerによって低い方の転送レートで出力トラフィックが制御されます。

CLIコマンドによるQoS値の設定例:

以下の例では、vif-param-setコマンドを使用してVIFの最大転送レートを毎秒100キロバイトに設定しています:

xe vif-param-set uuid=vif_uuid qos_algorithm_type=ratelimit
xe vif-param-set uuid=vif_uuid qos_algorithm_params:kbps=100

注:

Citrixでは、vSwitchコントローラを使用する場合、CLIコマンドではなくvSwitchコントローラで最大転送レートを設定することをお勧めします。vSwitch Controllerでの設定方法については、「vSwitchとController」を参照してください。

ネットワーク設定オプションの変更

ここでは、XenServerホストのネットワーク設定を変更する方法について説明します。これには以下のタスクが含まれます:

  • ホスト名(DNS名)を変更する。

  • DNSサーバーを追加または削除する。

  • IPアドレスを変更する。

  • 管理インターフェイスとして使用するNICを変更する。

  • サーバーに新しい物理NICを追加する。

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

  • ARPフィルタを有効にする(スイッチポートのロック)。

ホスト名

システムのホスト名(DNS名)はプール全体のデータベースに定義され、次のxe host-set-hostname-liveコマンドで変更できます:

xe host-set-hostname-live host-uuid=host_uuid host-name=host-name

新しいホスト名は、コントロールドメインのホスト名にも自動的に反映されます。

DNSサーバー

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

pif-reconfigure-ip uuid=pif_uuid mode=static DNS=new_dns_ip

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

ネットワークインターフェイスの設定は、xe CLIを使用して変更できます。ネットワーク設定スクリプトを直接編集することは避けてください。

PIFのIPアドレス設定を変更するには、pif-reconfigure-ipコマンドを使用します。pif-reconfigure-ipコマンドで使用可能なオプションについて詳しくは、「pif-reconfigure-ip」を参照してください。リソースプール内のホストのIPアドレスを変更する方法については、次のセクションを参照してください。

リソースプールでのIPアドレス設定の変更

リソースプール内のXenServerホストには、管理やプール内のほかのホストとの通信に使用する単一の管理IPアドレスがあります。管理インターフェイスのIPアドレスの変更手順は、プールマスタとそれ以外のホストで異なります。

注:

ホストのIPアドレスやほかのネットワークパラメータを変更するときは、注意が必要です。環境のネットワークトポロジや変更内容によっては、ネットワークストレージへの接続が切断される場合があります。この問題が発生した場合は、XenCenterの [ストレージ]>[修復] コマンドや、CLIのpbd-plugコマンドを使用してストレージを再プラグする必要があります。この理由から、仮想マシンをほかのホストに移行してから、IPアドレス設定を変更することをお勧めします。

次のpif-reconfigure-ipコマンドを実行して、IPアドレスを設定します。pif-reconfigure-ipコマンドで使用可能なオプションについて詳しくは、「pif-reconfigure-ip」を参照してください:

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP

次のhost-listコマンドを実行して、プール内のほかのすべてのXenServerホストが認識されることを確認します(メンバホストがプールマスタに正しく再接続されたことを示します):

xe host-list

プールマスタとして動作するXenServerホストのIPアドレスを変更する場合は、追加の手順が必要です。これは、各プールメンバーがプールマスタと通信するときに、変更前の古いIPアドレスが使用されるため、IPアドレスが変更されると、プールマスタとどのように接続すればよいかわからなくなるためです。

可能な場合は、リソースプールの運用中に変更される可能性が低いIPアドレスをプールマスタに割り当ててください。

次のpif-reconfigure-ipコマンドを実行して、IPアドレスを設定します:

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP

プールマスタのIPアドレスが変更され、メンバホストが接続できなくなると、すべてのメンバホストが緊急モードに切り替わります。

プールマスタ上で、次のpool-recover-slavesコマンドを実行します。これにより、プールマスタが各メンバホストと通信し、プールマスタの新しいIPアドレスが通知されます:

xe pool-recover-slaves

管理インターフェイス

複数のNICが装着されたコンピュータにXenServerをインストールすると、管理インターフェイスとして使用されるNICが1つ選択されます。管理インターフェイスは、XenCenterとそのホスト間の通信、およびホストどうしの通信で使用されます。

次の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

次のhost-management-reconfigureコマンドを実行して、管理インターフェイスとして使用するPIFを変更します。このホストがリソースプールに属している場合は、プールマスタ上のコンソールでこのコマンドを実行する必要があります

xe host-management-reconfigure pif-uuid=pif_uuid

次のnetwork-listコマンドを実行して、プールのすべてのホストで管理インターフェイスとして使用されるNICのPIFを確認します。このコマンドには、プール全体のネットワークUUIDが返されます。

xe network-list

network-param-listコマンドを使用して、リソースプールのすべてのホストのPIF UUIDを取得します。次のpif-param-listコマンドを実行して、管理インターフェイスとして使用するPIFのIPアドレス設定を確認します。必要な場合は、pif-reconfigure-ipコマンドを使用して、そのPIFのIPアドレス設定を変更します。

xe pif-param-list uuid=pif_uuid

次のpool-management-reconfigureコマンドを実行して、ネットワーク一覧で管理インターフェイスとして使用されるPIFを変更します。

xe pool-management-reconfigure network-uuid=network_uuid

管理アクセスの無効化

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

警告:

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

物理NICの新規追加

XenServerホストへの物理NICのインストールは、通常の手順で行います。その後、ホストを起動したら、pif-scanコマンドを実行して、新しいNIC用の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

現在、ネットワーク目的で使用可能な値はnbdinsecure_nbdです。詳しくは、「XenServer Changed Block Tracking Guide」を参照してください。

スイッチポートロックの使用

XenServerのスイッチポートロック機能を使用すると、仮想マシンがMACアドレスやIPアドレスを偽装できなくなり、不明な仮想マシンからの悪意のあるトラフィックを制御できるようになります。ポートロックコマンドでは、特定のネットワーク上のトラフィックをすべてブロック(デフォルト)したり、特定のIPアドレスからのトラフィック以外をブロックしたりできます。

クラウドサービスプロバイダでスイッチポートロック機能を使用すると、内部脅威に対するセキュリティを強化できます。仮想マシンがインターネットのパブリックなIPアドレスを使用するクラウド環境では、なりすましなどに対するセキュリティ対策を施して、クラウドのテナントがほかの仮想マシンを攻撃することを防ぐ必要があります。

スイッチポートロック機能を使用すると、すべてのテナントや仮想マシンで同じレイヤ2ネットワークを使用して、ネットワーク設定をシンプルにできます。

ポートロックコマンドの機能の1つに、信頼できない仮想マシンからのトラフィックを制限して、その仮想マシンがMACアドレスやIPアドレスを偽装することを不可能にするものがあります。これにより、以下の行為を制限できます。

  • XenServerの管理者が許可していないMACアドレスやIPアドレスを偽装する。

  • ほかの仮想マシンのトラフィックを傍受、なりすまし、または妨害する。

要件

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

  • 役割ベースのアクセス制御(RBAC)を使用する環境でこの機能を設定するには、プールオペレータまたはプール管理者以上の権限を持つアカウントでログインする必要があります。RBACを使用しない環境では、プールマスタのルートアカウントでログインする必要があります。

  • ポートロックコマンドは、オンラインおよびオフラインのネットワークに対して実行できます。

  • Windows仮想マシンで切断されたネットワークアイコンを表示するには、XenServer Toolsをインストールする必要があります。

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

vSwitchコントローラやそのほかのサードパーティコントローラを使用する環境でスイッチポートロックを設定することはサポートされません。

スイッチポートロックを設定しても、以下の行為は制限されません。

  • ほかのテナントやユーザーに対してIPレベルの攻撃をする。ただし、そのクラウド内のほかのテナントやユーザーになりすましたり、ほかのユーザーのトラフィックを傍受したりするIPレベル攻撃は、スイッチポートロックで防御できます。

  • ネットワークリソースを過度に消費する。

  • 通常のスイッチフラッディングの手段(ブロードキャストMACアドレスまたは不明な送信先MACアドレスを使用するなど)を使用して、ほかの仮想マシン宛てのトラフィックを受信する。

同様に、スイッチポートロックを設定しても、仮想マシンからのトラフィックの送信先は制限されません。

実装における注意事項

スイッチポートロック機能は、コマンドラインまたはXenServer APIを使って実装できます。特に、大規模な環境では、APIを使って自動化することが一般的です。

ここでは、スイッチポートロック機能を使用してさまざまな攻撃から環境を保護する方法について、例を挙げて説明します。これらの例で、「VM-c」は悪意のあるテナント(Tenant C)が使用している仮想マシンを表します。「VM-a」および「VM-b」は、通常のテナントが使用している仮想マシンを表します。

例1:ARPスプーフィングからの保護:

ARPスプーフィングとは、攻撃者が自分のMACアドレスを別のノードのIPアドレスに関連付けようとすることです。ARPスプーフィングにより、ノードのトラフィックが攻撃者に送信される可能性があります。攻撃者はこの目標を達成するために、偽の(なりすまされた)ARPメッセージをイーサネットLANに送信します。

シナリオ

VM-aがVM-bのIPアドレスを指定してVM-bにIPトラフィックを送信します。VM-cの攻撃者は、ARPスプーフィングを使用してVM-bになりすまします。

  1. VM-cから、推測的なARP応答のストリームがVM-aに送信されます。これらのARP応答では、VM-cのMACアドレス(c_MAC)とVM-bのIPアドレス(b_IP)との関連付けが偽装されます。

    結果:管理者がスイッチポートロック機能を有効にしたため、偽装が無効になり、これらのパケットはすべてドロップします。

  2. VM-bからVM-aへのARP応答により、VM-bのMACアドレス(b_MAC)がVM-bのIPアドレス(b_IP)に関連付けられます。

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

例2:IPアドレススプーフィングからの保護:

IPアドレススプーフィングは、ソースIPアドレスが偽装されたインターネットプロトコル(IP)パケットを作成することで、パケットの本当のIPアドレスを隠す手法です。

シナリオ

攻撃者(Tenant C)が自分のホスト(Host-C)を使用してリモートシステムにサービス拒否攻撃をしかけ、自分のIDを偽装しようとします。

攻撃1:

Tenant CがHost-CのIPアドレスとMACアドレスとして、VM-aのもの(a_IPとa_MAC)を設定します。Tenant Cは、Host-CからリモートシステムにIPトラフィックを送信します。

結果:Host-Cからのパケットはドロップします。これは、管理者がスイッチポートロック機能を有効にしたためです。これにより偽装が無効になり、Host-Cからのパケットがドロップします。

攻撃2:

Tenant CがHost-CのIPアドレスとして、VM-aのもの(a_IP)を設定し、元のc_MACは保持します。

Tenant Cは、Host-CからリモートシステムにIPトラフィックを送信します。

結果:Host-Cからのパケットはドロップします。これは、管理者がスイッチポートロック機能を有効にしたためです。これにより、偽装が無効になります。

例3:Webホスト:

シナリオ:

山田氏はインフラストラクチャ管理者です。

彼のテナント(Tenant B)は自分の仮想マシンVM-bで複数のWebサイトをホストしています。各Webサイトでは、同一仮想ネットワークインターフェイス(VIF)上でホストされる個別のIPアドレスが必要です。

山田氏はHost-BのVIFを再設定して、このVIFが単一MACアドレスと複数IPアドレスを保持するように変更します。

スイッチポートロック機能のしくみ

スイッチポートロック機能により、以下の2つのレベルでパケットフィルタを制御できます。

  • VIFレベル:VIF上での設定により、パケットがどのようにフィルタされるかが決定されます。仮想マシンからのすべてのトラフィックをブロックしたり、そのVIFに関連付けられているIPアドレスを使用したトラフィックだけを送信したり、そのVIFが接続しているネットワーク上のすべてのIPアドレスにトラフィックを送信したりできます。

  • ネットワークレベル:XenServerネットワークにより、パケットがどのようにフィルタされるかが決定されます。VIFのロックモードをnetwork_defaultに設定すると、ネットワークレベルのロック設定に基づいて許可されるトラフィックが決定されます。

使用するネットワークスタックにかかわらず、この機能は同じしくみで動作します。ただし、後続のセクションで説明するように、LinuxブリッジではIPv6でのスイッチポートロックが完全にはサポートされません。

VIFのロックモード

XenServerのスイッチポートロック機能では、VIFに4つのロックモードを設定できます。これらのロックモードは、実行中の仮想マシンに接続されているVIFに対してのみ適用されます。

![この図は、ネットワークのロックモードが「unlocked」に設定されているときのVIFのロックモードを示しています。左の図では、VIFのロックモードが「network_default」に設定されており、仮想マシンからのトラフィックはフィルタされません。中央の図では、VIFのロックモードが「disabled」に設定されており、すべての送受信パケットがブロックされます。右の図では、VIFのロックモードが「locked」に設定されており、正しいMACアドレスおよびIPアドレスを含んでいるパケットだけが送信されます。](/ja-jp/xenserver/current-release/media/vif-switch-port-locking-modes.png)

  • network_default:VIFのロックモードをnetwork_defaultに設定すると、XenServerはネットワークのdefault-locking-modeパラメーターに基づいてそのVIFを介したパケットをフィルタします。このため、ネットワークに設定されているロックモード(disabledまたはunlocked)により、VIFの動作が以下のように異なります。

    - ネットワークのロックモードがdefault-locking-mode=disabledの場合、XenServerによってVIFですべてのトラフィックをドロップするフィルタ規則が適用されます。

    - ネットワークのロックモードがdefault-locking-mode=unlockedの場合、XenServerによってVIFのすべてのフィルタ規則が解除されます。default-locking-modeパラメーターのデフォルト値はunlockedです。

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

    ネットワークのdefault-locking-modeパラメーターの設定がそのネットワークに接続しているVIFのフィルタ規則に影響するのは、そのVIFのロックモードがnetwork_defaultである場合のみです。

    注:

    VIFがアクティブな場合、そのネットワークのdefault-locking-modeパラメーターを変更することはできません。

  • locked:VIFのロックモードをlockedに設定すると、XenServerはそのVIFで特定のMACアドレスおよびIPアドレスとの送受信トラフィックのみを許可します。このモードでIPアドレスが指定されていない場合、仮想マシンはそのVIFを介してトラフィックを送信できなくなります。

    VIFでのトラフィックを許可するIPアドレスを指定するには、IPv4またはIPv6のIPアドレスをipv4_allowedまたはipv6_allowedパラメーターで指定します。ただし、Linuxブリッジを使用する環境では、IPv6アドレスを指定しないでください。

    XenServer Linuxブリッジがアクティブな場合でも、IPv6アドレスを指定すること自体は可能ですが、XenServerではそのIPv6アドレスでトラフィックをフィルタすることはできません。LinuxブリッジにはNDP(Neighbor Discovery Protocol)パケットをフィルタするモジュールがないため、完全な保護を実装できません。このため、NDPパケットを偽造することで仮想マシンが偽装される場合があります。この結果、Linuxブリッジ環境でIPv6アドレスを指定しても、XenServerによってすべてのIPv6トラフィックがそのVIFで許可されてしまいます。IPv6アドレスを指定しなければ、XenServerによってすべてのIPv6トラフィックがそのVIFでドロップされます。

  • unlocked:すべてのネットワークトラフィックが許可され、そのVIFを通過できるようになります。つまり、そのVIFで送受信されるトラフィックにいかなるフィルタも適用されません。

  • disabled:すべてのネットワークトラフィックが禁止され、そのVIFを通過できなくなります。つまり、XenServerによってVIFですべてのトラフィックをドロップするフィルタ規則が適用されます。

スイッチポートロックの設定

ここでは、以下の手順について説明します:

  • VIFで特定のIPアドレスのトラフィックだけを許可する。

  • 許可するIPアドレスの一覧にほかのIPアドレスを追加する。たとえば、仮想マシンがネットワークに接続されて実行中に、VIFにIPアドレスを追加する場合(たとえば、ネットワークを一時的にオフラインにしている場合)。

  • 許可するIPアドレスの一覧から特定のIPアドレスを削除する。

VIFのロックモードをlockedに設定すると、ipv4-allowedまたはipv6-allowedパラメーターで指定されたIPアドレスのトラフィックだけが許可されるようになります。

VIFに複数のIPアドレスが割り当てられることもあるため、これらのパラメータでは、複数のIPアドレスを指定することもできます。

これらの手順は、VIFの接続前および接続後(仮想マシンの起動後)に実行できます。

VIFのロックモードがlockedに設定されていない場合は、次のコマンドでlocking-modeパラメーターにlockedを指定します。

xe vif-param-set uuid=vif-uuid locking-mode=locked

ここで、vif-uuidにはVIFのUUIDを指定します。VIFのUUIDを確認するには、そのホスト上でxe vif-listコマンドを実行します。vm-uuid 仮想マシンのUUID(vm-uuid)ごとに各デバイスの一覧が表示され、デバイスIDによりVIFのデバイス番号が示されます。

vif-param-setコマンドに以下のパラメータを使用して、許可するIPアドレスを指定します。必要に応じて、以下のいずれかまたは両方を行います。

  • 許可するIPv4 IPアドレスを指定します。次に例を示します:

     xe vif-param-set uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
    
  • 許可するIPv6 IPアドレスを指定します。次に例を示します:

     xe vif-param-set uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
    

複数のIPアドレスをコンマで区切って入力できます。

上記の手順で許可されるIPアドレスを指定した後で、そのVIFに許可されるIPアドレスを追加することができます。

vif-param-addコマンドに以下のパラメータを使用して、許可するIPアドレスを追加します。必要に応じて、以下のいずれかまたは両方を行います。

  • 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
    

許可するIPアドレスとして複数のアドレスが指定されている場合は、特定のIPアドレスを削除して、そのアドレスのトラフィックをドロップできます。

vif-param-removeコマンドに以下のパラメータを使用して、削除するIPアドレスを指定します。必要に応じて、以下のいずれかまたは両方を行います。

  • 削除する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ですべてドロップされます。

ヒント:

VIFのUUIDを確認するには、そのホスト上でxe vif-listコマンドを実行します。デバイスIDによりVIFのデバイス番号が示されます。

VIFがトラフィックを受信することを禁止するには、次のコマンドを実行して、禁止するネットワークに接続しているVIFのロックモードをdisabledに設定します:

xe vif-param-set uuid=vif-uuid locking-mode=disabled

また、XenCenterでVIFを無効にすることもできます。これを行うには、仮想マシンの[ネットワーク]タブでそのVIFを選択して、[非アクティブ化]をクリックします。

VIFのIPアドレス制限の解除

VIFのロックモードを元のデフォルトの設定に戻すには、以下の手順に従います。新規に作成するVIFには、XenServerによって「unlocked」のロックモードが設定され、すべてのIPアドレスのトラフィックが許可されます。

VIFのロックモードをunlockedに戻すには、デフォルトのロックモードをunlockedに変更します。ロックモードがunlockedに設定されていない場合は、次のコマンドを実行します:

xe vif-param-set uuid=vif_uuid locking-mode=unlocked

クラウド環境でのVIFロックモードの簡単設定

クラウド環境では、各VIFに対してロックモードコマンドを個別に実行せずに、すべてのVIFがデフォルトでdisabledになるように設定できます。これを行うには、ネットワークレベルでパケットのフィルタ規則を変更します。これにより、前のセクション「スイッチポートロック機能のしくみ」で説明したように、パケットがどのようにフィルタされるかがXenServerネットワークにより決定されるようになります。

ネットワークのdefault-locking-modeパラメータにより、新しく作成するVIFのデフォルトの動作が決定されます。VIFのlocking-modeがnetwork_defaultの場合、ネットワークレベルのロックモード(default-locking-mode)が参照され、その設定によりVIFでパケットの通過を禁止するか許可するかが決定されます。

  • unlocked:ネットワークのdefault-locking-modeパラメータがunlockedの場合、XenServerによってそのネットワークが接続するVIFですべてのトラフィックが許可されます。

  • disabled:ネットワークのdefault-locking-modeパラメータがdisabledの場合、XenServerによってそのネットワークが接続するVIFですべてのトラフィックをドロップするフィルタ規則が適用されます。

XenCenterやCLIで作成するネットワークのdefault-locking-modeパラメータには、デフォルトでunlockedが設定されます。

VIFのロックモードをデフォルト(network_default)のままにしておくことで、ネットワークのdefault-locking-modeパラメーターでそのネットワークに接続するすべてのVIFのフィルタ規則を制御できます。

次の図は、各VIFのlocking-modeパラメーターがデフォルト値(network_default)の場合に、ネットワークのdefault-locking-modeパラメーターの設定がすべてのVIFに適用されることを示しています。

 この図は、デフォルトのロックモード設定の各VIFに、ネットワークのdefault-locking-mode設定が適用されることを示しています。この例では、ネットワークの設定(default-locking-mode=disabled)が各VIFに適用されるため、すべてのトラフィックがこれらのVIFを通過できなくなっています。

たとえば、デフォルトでは、新しく作成されるVIFのlocking-modenetwork_defaultに設定されるため、ネットワークのdefault-locking-modedisabledに設定した場合、ロックモードが設定されていないすべてのVIFにこの設定が適用されます。この設定を特定のVIFで変更するには、そのVIFのlocking-modeパラメータを変更するか、VIFのlocking-modeパラメータを明示的にunlockedに設定します。これは、信頼できる仮想マシンがあり、そのトラフィックを制限したくない場合に役立ちます。

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

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

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トラフィックフィルタリングのネットワーク設定を使用する

XenServerネットワークのdefault-locking-mode設定に基づいて、そのネットワークに接続する仮想マシン上のVIFのフィルタ規則を制御するには、以下の手順に従います。

  1. VIFのロックモードがnetwork_defaultに設定されていない場合は、次のコマンドを実行します:

    xe vif-param-set uuid=vif_uuid locking-mode=network_default
    
  2. VIFのロックモードがunlockedに設定されていない場合は、次のコマンドを実行します:

    xe network-param-set uuid=network-uuid default-locking-mode=unlocked