VMware NSX for vSphere 6.4.0 | 2018 年 1 月 16 日リリース | ビルド 7564187 このドキュメントの改訂履歴を参照してください。

リリース ノートの概要

本リリース ノートには、次のトピックが含まれています。

• NSX 6.4.0 の新機能
• バージョン、システム要件、およびインストール
• 廃止および提供を中止する機能
• アップグレードに関する注意事項
• FIPS コンプライアンス
• 改訂履歴
• 解決した問題
• 既知の問題

NSX 6.4.0 の新機能

NSX for vSphere 6.4.0 では、保守容易性が向上し、ユーザーから報告された複数のバグが修正されています。詳細については、解決した問題を参照してください。

NSX for vSphere 6.4.0 の変更点は次のとおりです。

セキュリティ サービス：

• Identity Firewall：Identity Firewall (IDFW) では、リモート デスクトップとアプリケーション サーバ (RDSH) で、1 つの IP アドレスを共有するユーザー セッションがサポートされるようになりました。また、新しい「fast-path」アーキテクチャにより、IDFW ルールの処理速度が向上しています。Active Directory との連携により、同期対象を選択することが可能になるため、Active Directory の更新時間を短縮できます。

• 分散ファイアウォール：分散ファイアウォール (DFW) により、フロー制御とマイクロセグメンテーションのプランニングで、L7 アプリケーション ベースのコンテキストを使用できるようになりました。Application Rule Manager (ARM) では、管理可能な統合マイクロセグメンテーション戦略向けに、セキュリティ グループとセキュリティ ポリシーを推奨できるようになりました。

• 分散ファイアウォール ルールが、分散ファイアウォール セクション レベルのステートレス ルールとして作成できるようになりました。

• 分散ファイアウォールで、ハイパーバイザー上の仮想マシンの IP アドレス認識がサポートされます。これにより、分散ファイアウォール ルールの送信元、宛先、または適用先フィールドで使用される securitygroup/cluster/resourcepool/host に、特定の仮想マシンの IP アドレスが含まれているかどうか検証できるようになりました。

• 仮想マシンの IP アドレス検出メカニズム：仮想マシン名ベースのセキュリティ ポリシーや、その他の vCenter Server ベースの属性を厳密に適用するには、NSX が仮想マシンの IP アドレスを認識する必要があります。NSX 6.2 では DHCP スヌーピングまたは ARP スヌーピングを使用した、仮想マシンの IP アドレスを検出するオプションが導入されています。NSX 6.4.0 では、ARP で検出される IP アドレスの最大数が 128 に変更されました。この値は 1 ～ 128 に設定できます。  これらの新しい検出メカニズムにより、VMware Tools がインストールされていない仮想マシンでも、IP アドレスベースのセキュリティ ルールを適用できるようになりました。

• ゲスト イントロスペクション： vCenter Server 6.5 以降では、ゲスト イントロスペクション (GI) 仮想マシンの名前が「ゲスト イントロスペクション (XX.XX.XX.XX)」になります。XX.XX.XX.XX　は、ゲスト イントロスペクション マシンが配置されるホストの IPv4 アドレスです。これは、ゲスト イントロスペクションの初期デプロイで発生します。

NSX ユーザー インターフェイス：

• vSphere Client (HTML5) のサポート：VMware NSX UI Plug-in for vSphere Client (HTML5)　が導入されました。サポートされる機能の一覧については、vSphere Client での VMware NSX for vSphere ユーザー インターフェイス プラグイン機能を参照してください。
• vSphere Web Client (Flash)　と HTML5 の互換性：HTML5 で作成された NSX の機能（ダッシュボードなど）は、vSphere Client と vSphere Web Client の両方で使用できます。vSphere Client にすぐに移行できないユーザーでもシームレスに操作できます。
• ナビゲーション メニューの向上：グループ オブジェクト、タグ、除外リスト、システム設定などの主な機能に、以前よりも少ない手順で容易にアクセスできるようになりました。

操作とトラブルシューティング：

• アップグレード コーディネータは、NSX のアップグレードのプランニングと実行を簡素化するための単一のポータルを提供します。  アップグレード コーディネータでは、すべての NSX コンポーネントの完全なシステムビューが表示されます。現在のバージョンとアップグレードするバージョン、アップグレードの進行状況、ワンクリックまたはカスタムアップグレード プラン、アップグレードの前または後のチェックなどを確認できます。
• 数多くの新しいコンポーネントのほか、 HTML5 ダッシュボードが新たに強化されました。ダッシュボードは、デフォルトでトップ　ページに表示されます。  システムが定義する既存のウィジェットをカスタマイズしたり、API を使用して独自のカスタム ウィジェットを作成できます。
• 新しい [システムのスケール] ダッシュボードには、システム拡張に関する情報や、サポート対象の拡張パラメータの上限が表示されます。  上限に近づいたとき、あるいは上限を超えたときに表示される警告やアラートも設定できます。
• ゲスト イントロスペクションの信頼性の向上とトラブルシューティングの強化  ESX Agent Manager ステータス通知、アップグレード プロセス、サービス仮想マシンのカスタム名、メモリの追加などにより、ゲスト イントロスペクションの信頼性が向上し、トラブルシューティングが強化されます。
• 論理スイッチ、論理ルーター、Edge 分散ファイアウォールのセントラル CLI により、分散されたネットワーク機能へのアクセスを集中管理し、トラブルシューティングの時間を短縮できます。
• 新しい [サポート バンドル] タブでは、ユーザー インターフェイスからワンクリックでサポート バンドルを収集できます。NSX Manager、ホスト、Edge、コントローラなどの NSX コンポーネントのサポート バンドル データを収集できます。サポート バンドルをまとめてダウンロードし、リモート サーバにバンドルを直接アップロードできます。データ収集の全体的なステータスや各コンポーネントのステータスを確認できます。
• 新しい [パケット キャプチャ] タブでは、ユーザー インターフェイスからパケットを収集できます。良好な状態でないホストがある場合、このホストのパケット ダンプを取得し、管理者がこのパケット情報を使用してデバッグを行うことができます。
• セカンダリ サイトの [管理] タブで Controller Disconnected Operation (CDO) モードを有効にすると、一時的な接続問題を回避できます。サイトが複数ある環境で CDO モードを有効にすると、プライマリ サイトが切断されても、データ プレーンの接続に影響はありません。 
• 複数の Syslog のサポート。最大で 5 台の Syslog サーバがサポートされます。
• API の強化。JSON フォーマットのサポートが追加されました。  NSX ではデータ フォーマットに JSON または XML を選択できます。  後方互換性を維持するため、デフォルトでは XML が使用されます。
• NSX Edge システム イベント メッセージの一部に、Edge ID または 仮想マシン ID パラメータが追加されました。たとえば、イベント コード 30100、30014、30031 などです。
  これらのメッセージ パラメータは、古いシステム イベントでは使用されません。古いシステムイベントのイベント メッセージでは、Edge ID または 仮想マシン ID のパラメータは {0} または {1} で表示されます。

• NSX API を使用して、ハイパーバイザーのステータスを確認できます。ハイパーバイザー トンネルの健全性を監視することで、問題のトラブルシューティングを迅速に行うことができます。API 応答には、物理 NIC のステータス、トンネルのステータス、ハイパーバイザーから制御プレーンへの接続のステータス、ハイパーバイザーから管理プレーンへの接続のステータスが含まれます。

NSX Edge の機能拡張：

• Edge ロード バランサの健全性チェックが強化されました。DNS、LDAP、SQL の 3 つの健全性チェック モニターが新たに追加されました。
• 宛先 IP アドレスのプリフィックス長の LE/GE に基づいて、再分配のルートをフィルタリングできるようになりました。
• GRE トンネル経由の BGP とスタティック ルートがサポートされます。
• NAT64 で、IPv6 から IPv4 に変換できます。
• Edge ルーティング サービスのフェイルオーバー時間が短縮されます。
• ルーティング イベントにより、NSX Manager でシステム イベントが生成されるようになりました。
• L3 VPN のパフォーマンスと弾力性が向上しました。

 

バージョン、システム要件、およびインストール

注：

• 次の表は、推奨される VMware ソフトウェアのバージョンです。ここで推奨されるバージョンは一般的なものであり、環境に固有の推奨に優先するものではありません。

• これは、本ドキュメントが公開された時点で最新の情報です。

• NSX とその他の VMware 製品を併用する場合にサポートされる最小バージョンについては、VMware 製品の相互運用性マトリクスを参照してください。VMware はテスト結果に基づいて、サポートされる最小バージョンを定めています。

製品またはコンポーネント	バージョン
NSX for vSphere	新たに導入する場合には、最新の NSX リリースをお勧めします。 既存の環境をアップグレードする場合は、アップグレード プランを策定する前に、NSX リリース ノートを参照して、特定の問題に関する情報を確認してください。あるいは、VMware テクニカル サポートの担当者に詳細をお問い合わせください。
vSphere	vSphere 6.0： サポート対象： vSphere 6.0 Update 2、6.0 Update 3 推奨：  vSphere 6.0 Update 3。vSphere 6.0 Update 3 を使用することで、vCenter Server の再起動後に ESXi ホストの VTEP が重複するという問題が解決されます。詳細については、VMware のナレッジベースの記事 KB2144605 を参照してください。 vSphere 6.5： サポート対象： vSphere 6.5a、6.5 Update 1 推奨： vSphere 6.5 Update 1。vSphere 6.5 Update 1 により、メモリ不足で ESX Agent Manager が機能しないという問題が解決されます。詳細については、VMware のナレッジベースの記事 KB2135378 を参照してください。  注：vSphere 5.5 は NSX 6.4.0 に対応していません。
ゲスト イントロスペクション (Windows)	VMware Tools のすべてのバージョンがサポートされます。一部のゲスト イントロスペクション ベースの機能には、VMware Tools の最新バージョンが必要です。 VMware Tools に含まれるオプションの Thin Agent Network Introspection Driver コンポーネントを有効にするには VMware Tools 10.0.9 および 10.0.12 を使用します。 NSX または vCloud Networking and Security 環境の VMware Tools をアップグレードした後に仮想マシンの動作が遅くなる問題を解決するには、VMware Tools 10.0.8 以降にアップグレードする必要があります。詳細については、VMware のナレッジベースの記事 KB2144236 を参照してください。 Windows 10 には VMware Tools 10.1.0 以降を使用します。 Windows Server 2016 には VMware Tools 10.1.10 以降を使用します。
ゲスト イントロスペクション (Linux)	NSX の本バージョンは、次の Linux のバージョンをサポートします。 RHEL 7 GA（64 ビット） SLES 12 GA（64 ビット） Ubuntu 14.04 LTS（64 ビット）

システム要件とインストール

NSX のインストールの前提条件については、『NSX インストール ガイド』の「NSX のシステム要件」のセクションを参照してください。

インストール手順については、『NSX インストール ガイド』または『Cross-vCenter NSX インストール ガイド』を参照してください。

廃止および提供を中止する機能

販売およびサポートの終了に関するご注意

ただちにアップグレードが必要な NSX およびその他の VMware 製品については、VMware Lifecycle Product Matrix（英語）を参照してください。

• NSX for vSphere 6.1.x は、2017 年 1 月 15 日に提供終了日 (EOA) およびジェネラル サポートの終了日 (EOGS) を迎えました。（VMware ナレッジベースの記事 KB2144769 を参照してください）

• vCNS Edge のサポートを終了：NSX 6.3.x 以降にアップグレードする前に、NSX Edge にアップグレードする必要があります。

• NSX for vSphere 6.2.x のジェネラル サポートの終了日 (EOGS) は 2018 年 8 月 20 日です。

API の削除と動作の変更

NSX 6.4.0 で非推奨となった項目
次の項目の使用が非推奨となりました。今後のリリースで削除される可能性があります。

• GET /api/4.0/edges/edgeID/status の systemStatus パラメータの使用は推奨されません。
• GET /api/2.0/services/policy/serviceprovider/firewall/ の使用は推奨されません。GET /api/2.0/services/policy/serviceprovider/firewall/info を使用してください。
• 分散ファイアウォールのグローバル設定セクションでの TCP Strict の設定は非推奨となりました。NSX 6.4.0 以降では、TCP Strict はセクション レベルで定義されます。注：NSX 6.4.0 以降にアップグレードした場合、TCP Strict のグローバル設定は、既存のレイヤー 3 セクションの TCP Strict の設定に使用されます。レイヤー 2 セクションとレイヤー 3 リダイレクト セクションの設定では、TCP Strict は false になります。詳細については、『NSX API ガイド』の「分散ファイアウォール設定の操作」を参照してください。

NSX 6.4.0 での動作変更
NSX 6.4.0 では、POST /api/2.0/vdn/controller でコントローラを作成するときに、<name> パラメータの使用が必須となりました。

NSX 6.4.0 では、エラー処理が次のように変更されます。

• 以前のリリースでは、POST /api/2.0/vdn/controller は、コントローラの作成ジョブが作成されたことを示す「201 Created」を返しました。 しかし、コントローラの作成に失敗している可能性がありました。NSX 6.4.0 以降では、応答が「202 Accepted」になります。
• 以前のリリースでは、移行モードまたはスタンドアローン モードで許可されていない API 要求を送信した場合、応答ステータスは「400 Bad Request」でした。 NSX 6.4.0 以降では、応答が「403 Forbidden」となります。

CLI の削除と動作の変更

NSX Controller ノードで、サポートされていないコマンドを使用しないでください。
NSX Controller ノードで NTP と DNS を設定する場合に、ドキュメントに記載されていないコマンドが使用できてしまう場合があります。ただし、これらのコマンドはサポートされていないため、NSX Controller ノードでは使用しないでください。『NSX CLI ガイド』に記載されているコマンドのみを使用してください。

アップグレードに関する注意事項

• アップグレードに関する全般的な注意事項
• NSX コンポーネントのアップグレードに関する注意事項
• FIPS のアップグレードに関する注意事項

注：インストールとアップグレードに影響する既知の問題については、「インストールとアップグレードに関する既知の問題」セクションを参照してください。

アップグレードに関する注意事項

• NSX をアップグレードするには、ホスト クラスタのアップグレード（ホストの VIB のアップグレード）を含む、完全な NSX アップグレードを実行する必要があります。手順については、『NSX アップグレード ガイド』の「ホスト クラスタのアップグレード」セクションを参照してください。

• VUM を使用したホスト クラスタの NSX VIB のアップグレードはサポートされていせん。ホスト クラスタの NSX VIB をアップグレードするには、アップグレード コーディネータ、ホストの準備、または関連する REST API を使用してください。

• システム要件：NSX のインストールとアップグレードのシステム要件については、NSX ドキュメントの「NSX のシステム要件」セクションを参照してください。

• NSX のアップグレード パス：VMware NSX のアップグレードの詳細については、VMware 製品の相互運用性マトリクスを参照してください。

• Cross-vCenter NSX のアップグレードについては、NSX アップグレード ガイドを参照してください。

• ダウングレードはサポートされない:

  • アップグレードの前に、必ず NSX Manager をバックアップしてください。

  • NSX を正常にアップグレードしたあとは、ダウングレードすることはできません。

• NSX 6.4.x へのアップデートが成功したことを確認するには、ナレッジベースの記事 KB2134525 を参照してください。

• vCloud Networking and Security から NSX 6.4.x へのアップグレードはサポートされません。まず、サポート対象の 6.2.x リリースにアップグレードする必要があります。

• 相互運用性：アップグレードを行う前に、関連する VMware 製品をVMware 製品の相互運用性マトリックスで確認してください。
  • NSX 6.4 へのアップグレード：NSX 6.4 には、vSphere 5.5 との互換性がありません。
  • vSphere 6.5a 以降へのアップグレード：vSphere 6.0 から vSphere 6.5a 以降にアップグレードする場合は、最初に NSX 6.3.0 以降にアップグレードする必要があります。NSX 6.2.x には、vSphere 6.5 との互換性がありません。『NSX アップグレード ガイド』の「NSX 環境での vSphere のアップグレード」を参照してください。
• パートナー サービスとの互換性：サイト内で、ゲスト イントロスペクションまたはネットワーク イントロスペクション用に VMware のパートナー サービスを使用している場合、アップグレード前にVMware 互換性ガイドを参照して、アップグレードする NSX のバージョンとベンダーのサービスに互換性があることを確認してください。
• Networking and Security プラグイン：NSX Manager をアップグレードした後は、vSphere Web Client からログアウトし、再度ログインする必要があります。NSX プラグインが正しく表示されない場合には、ブラウザのキャッシュと履歴を消去してください。Networking and Security プラグインが vSphere Web Client に表示されない場合には、NSX アップグレード ガイドの説明に従って、vSphere Web Client サーバをリセットしてください。
• ステートレス環境：ステートレス ホスト環境では、NSX アップグレード プロセスで、新しい VIB がホスト イメージ プロファイルに事前追加されます。ステートレス ホストで NSX のアップグレードを行う場合は、次の手順を実行してください。

  NSX 6.2.0 より前のバージョンでは、NSX Manager 上に 1 つの URL があり、そこから特定バージョンの ESX ホストの VIB を見つけることができました。つまり、管理者は NSX バージョンに関係なく、1 つの URL を知っておくだけで済みました。NSX 6.2.0 以降では、新しい NSX VIB を異なる URL で利用できます。正しい VIB を見つけるには、以下の手順を実行する必要があります。

  1. 新しい VIB URL を https://<nsxmanager>/bin/vdn/nwfabric.properties から見つけます。
  2. 必要な ESX ホスト バージョンの VIB を、対応する URL から取得します。
  3. 取得した VIB をホスト イメージ プロファイルに追加します。
      

NSX コンポーネントのアップグレードに関する注意事項

NSX Manager のアップグレード

• 重要：NSX 6.2.0、6.2.1 または 6.2.2 から NSX 6.3.5 以降にアップグレードする場合は、アップグレードを開始する前に、既知の問題への回避策を実行しておく必要があります。詳細については、VMware のナレッジベースの記事 KB000051624 を参照してください。

• NSX のバックアップに SFTP を使用する場合は、hmac-sha1 はサポートされていないため、NSX 6.3.0 以降にアップグレードした後で hmac-sha2-256 に変更してください。サポートされるセキュリティ アルゴリズムについては、VMware のナレッジベースの記事 KB2149282 を参照してください。

コントローラのアップグレード

• NSX 6.3.3 にアップグレードするには、NSX Controller クラスタに 3 台のコントローラ ノードが必要です。コントローラが 3 台未満の場合は、アップグレードを開始する前にコントローラを追加する必要があります。詳細については、NSX Controller クラスタのデプロイを参照してください。

• NSX 6.3.3 では、NSX Controller の基盤となるオペレーティング システムが変わりました。NSX 6.3.2 以前から NSX 6.3.3 以降にアップデートする場合、インプレース アップグレードは実行されません。既存のコントローラが 1 度に 1 つずつ削除され、同じ IP アドレスを使用して新しい Photon OS ベースのコントローラが展開されます。

  コントローラを削除すると、関連する DRS の非アフィニティ ルールも削除されます。vCenter Server で新しい非アフィニティ ルールを作成して、新しいコントローラ仮想マシンが同じホストに配置されないようにする必要があります。

  コントローラのアップグレードの詳細については、NSX Controller クラスタのアップグレードを参照してください。

ホスト クラスタのアップグレード

• NSX 6.3.2 以前のバージョンから NSX 6.3.3 以降にアップグレードすると NSX VIB 名が変更されます。
  ESXi 6.0 以降に NSX 6.3.3 以降をインストールすると、esx-vxlan と esx-vsip VIB が esx-nsxv に変更されます。

• アップグレードおよびアンインストールでホストの再起動が不要：vSphere 6.0 以降で、NSX 6.2.x から NSX 6.3.x 以降にアップグレードする場合、以降の NSX VIB の変更でホストの再起動が不要になります。代わりに、VIB 変更を完了するには、ホストをメンテナンス モードにする必要があります。これは、NSX ホスト クラスタのアップグレードと ESXi のアップグレードの両方に影響します。詳細については、『NSX アップグレード ガイド』を参照してください。

NSX Edge のアップグレード

• NSX Edge アプライアンスをアップグレードする前に NSX 用ホスト クラスタを準備する必要がある：NSX 6.3.0 以降では、NSX Manager と Edge 間で、VIX チャネルを経由した管理プレーン通信はサポートされません。メッセージ バス チャネル経由のみがサポートされます。NSX 6.2.x 以前から NSX 6.3.0 以降にアップグレードする場合、NSX Edge アプライアンスのデプロイ先のホスト クラスタが準備されていることと、メッセージング インフラストラクチャのステータスが正常であることを確認する必要があります。NSX 用ホスト クラスタが準備されていない場合、NSX Edge アプライアンスのアップグレードに失敗します。詳細については、『NSX アップグレード ガイド』の NSX Edge のアップグレードを参照してください。

• Edge Services Gateway (ESG) のアップグレード：
  NSX 6.2.5 以降、リソース予約は NSX Edge のアップグレード時に実行されるようになりました。十分なリソースのないクラスタで vSphere HA が有効になっている場合、vSphere HA の制約に違反するためアップグレードに失敗することがあります。

  そのようなアップグレードの失敗を回避するには、ESG をアップグレードする前に次の手順を実行します。

  インストール時またはアップグレード時に値を明示的に設定していない場合は、次のリソース予約が NSX Manager で使用されます。

  NSX Edge フォーム ファクタ	CPU 予約	メモリの予約
  Compact	1000 MHz	512 MB
  Large	2000 MHz	1024 MB
  Quad Large	4000 MHz	2048 MB
  X-Large	6000 MHz	8192 MB

  1. インストール環境が vSphere HA 向けのベスト プラクティスに従っていることを常に確認します。ナレッジベースの記事 KB1002080 を参照してください。

  2. NSX チューニング設定 API を使用します。
     PUT https://<nsxmanager>/api/4.0/edgePublish/tuningConfiguration
     edgeVCpuReservationPercentage と edgeMemoryReservationPercentage の値が、フォーム ファクタで使用可能なリソースを超えていないことを確認します（デフォルト値は上の表を参照）。

• vSphere HA が有効で Edge を展開している環境では、vSphere の [仮想マシンの起動] オプションを無効にする：vSphere HA が有効で Edge が展開されているクラスタでは、NSX Edge の 6.2.4 以前のバージョンを 6.2.5 以降にアップグレードした後、vSphere の [仮想マシンの起動] オプションを無効にする必要があります。それには、vSphere Web Client を開き、NSX Edge 仮想マシンが常駐する ESXi ホストを見つけ、[管理] > [設定] の順にクリックし、[仮想マシン] で [仮想マシンの起動/シャットダウン] を選択して、[編集] をクリックします。次に、仮想マシンが手動モードにあることを確認します。[自動起動/シャットダウン] リストに追加されていないことを確認してください。

• NSX 6.2.5 以降にアップグレードする前に、ロード バランサの暗号化リストがコロン区切りであることを確認します。暗号化リストにコンマなど別の区切り文字が使用されている場合は、https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles への PUT 呼び出しを実行し、<clientssl> </clientssl> および <serverssl> </serverssl> の各 <ciphers> </ciphers> リストをコロン区切りのリストに置換します。たとえば、要求本文の関連セグメントは次のようになります。すべてのアプリケーション プロファイルに対して次の手順を繰り返します。

  <applicationProfile>
    <name>https-profile</name>
    <insertXForwardedFor>false</insertXForwardedFor>
    <sslPassthrough>false</sslPassthrough>
    <template>HTTPS</template>
    <serverSslEnabled>true</serverSslEnabled>
    <clientSsl>
      <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
      <clientAuth>ignore</clientAuth>
      <serviceCertificate>certificate-4</serviceCertificate>
    </clientSsl>
    <serverSsl>
      <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
      <serviceCertificate>certificate-4</serviceCertificate>
    </serverSsl>
    ...
  </applicationProfile>

• vRealize Operations Manager (vROPs) 6.2.0 より前のバージョンでロード バランシングされたクライアントに正しい暗号バージョンを設定する：vROPs 6.2.0 より前のバージョンの vROPs プール メンバーは TLS バージョン 1.0 を使用しています。このため、NSX のロード バランサの設定で監視の拡張機能を編集し、"ssl-version=10" と明示的に指定する必要があります。手順については、『NSX 管理ガイド』の「サービス モニターの作成」を参照してください。

  {
                                "expected" : null,
                                "extension" : "ssl-version=10",
                                "send" : null,
                                "maxRetries" : 2,
                "name" : "sm_vrops",
                "url" : "/suite-api/api/deployment/node/status",
                "timeout" : 5,
                "type" : "https",
                "receive" : null,
                "interval" : 60,
                "method" : "GET"
  }

ゲスト イントロスペクションのアップグレード

• ゲスト イントロスペクション仮想マシンで、マシンの XML ファイルに追加ホストの識別情報が含まれるようになりました。ゲスト イントロスペクション仮想マシンにログインするときに、/opt/vmware/etc/vami/ovfEnv.xml ファイルにホスト識別情報が含まれている必要があります。

FIPS のアップグレードに関する注意事項

NSX 6.3.0 より前のバージョンから NSX 6.3.0 以降のバージョンにアップグレードする場合は、アップグレードが完了するまで FIPS モードを有効にしないでください。アップグレードが完了する前に FIPS モードを有効にすると、アップグレード済みのコンポーネントとアップグレードされていないコンポーネント間の通信が中断されます。詳細については、『NSX アップグレード ガイド』の「FIPS モードと NSX アップグレードの理解」を参照してください。

• OS X Yosemite および OS X El Capitan でサポートされる暗号：OS X 10.11 (EL Capitan) で SSL VPN クライアントを使用している場合は、AES128-GCM-SHA256、ECDHE-RSA-AES128-GCM-SHA256、ECDHE-RSA-AES256-GCM-SHA38、AES256-SHA、および AES128-SHA 暗号を使用して接続することができ、OS X 10.10 (Yosemite) を使用している場合は AES256-SHA および AES128-SHA 暗号のみを使用して接続することができます。

• NSX 6.3.x へのアップグレードが完了するまでは FIPS を有効にしないでください。詳細については、『NSX アップグレード ガイド』の「FIPS モードと NSX アップグレードの理解」を参照してください。

• FIPS モードを有効にする前に、パートナーのソリューションが FIPS モードの認定を受けていることを確認してください。『VMware 互換性ガイド』と、関連するパートナーのドキュメントを参照してください。

FIPS コンプライアンス

NSX 6.4 を正しく設定すると、すべてのセキュリティ関連の暗号化に、FIPS 140-2 認証を受けている暗号モジュールが使用されます。

注：

• コントローラと VPN のクラスタリング：NSX Controller は、IPsec VPN を使用してコントローラ クラスタに接続します。IPsec VPN では、VMware Linux カーネル暗号モジュール（VMware Photon OS 1.0 環境）を使用しています。このモジュールは現在 CMVP 認証を申請中です。
• Edge IPsec VPN：NSX Edge IPsec VPN では、VMware Linux カーネル暗号モジュール（VMware NSX OS 4.4 環境）を使用しています。このモジュールは現在 CMVP 認証を申請中です。

ドキュメントの改訂履歴

2018 年 1 月 16 日：初版。 
2018 年 1 月 17 日：第 2 版。解決した問題に 1461421、1499978、1628679、1634215、1716464、1753621、1777792、1787680、1792548、1801685 および 1849043 を追加しました。
2018 年 1 月 22 日：第 3 版。既知の問題 2036024 について記載しました。
2018 年 1 月 24 日：第 4 版。アップグレードに関する注意事項。
2018 年 2 月 1 日：第 5 版。FIPS コンプライアンス情報の更新。
2018 年 2 月 22 日：第 6 版。解決した問題に 1773240、1839953、1920574、1954964、および 1965589 を追加しました。既知の問題に 2013820、2016689、2017806 および 2026069 を追加しました。
2018 年 3 月 2 日：第 7 版。「新機能」セクションを更新しました。
2018 年 4 月 6 日：第 8 版。既知の問題 2014400 について記載しました。既知の問題 2029693 および 2003453 を追加しました。動作の変更と非推奨項目を更新しました。
2018 年 4 月 27 日：第 9 版。動作の変更と非推奨項目を更新しました。
2018 年 5 月 7 日：第 10 版。既知の問題 1772473 および 1954628 を追加しました。既知の問題に 1993691、2005900 および 2007991 を追加しました。
2018 年 9 月 14 日：第 11 版。既知の問題 2006576 を追加しました。
2018 年 10 月 5 日：第 12 版。既知の問題 2164138 を追加しました。

解決した問題

解決した問題には、次のトピックが含まれます。

• 解決した一般的な問題
• 論理ネットワークと NSX Edge に関する解決した問題
• NSX Manager に関する解決した問題
• セキュリティ サービスに関する解決した問題

解決した一般的な問題

• 解決した問題 1783528：毎週金曜日の夜と土曜日の朝に NSX Manager の CPU の使用率が急増する

  NSX は、完全同期を行うために、毎週金曜日の夜に LDAP をポーリングします。NSX では、特定の Active Directory 組織単位またはコンテナを設定するオプションがないため、指定されたドメインに関連するすべてのオブジェクトを取得します。

• 解決した問題 1801685：6.2.x から 6.3.0 へのアップグレード後にホストへ接続できなくなり、ESXi でフィルタが表示されなくなる
  NSX 6.2.x から 6.3.0 へアップグレードし、クラスタ VIB を 6.3.0 へアップグレードすると、インストール ステータスが「成功」と表示され、ファイアウォールが有効と表示されている場合でも、[通信チャネルの健全性] を確認すると NSX Manager からファイアウォール エージェントへの接続および NSX Manager から制御プレーン エージェントへの接続がダウンしていると表示されます。そのため、ファイアウォール ルールの発行およびセキュリティ ポリシーの発行に失敗し、VXLAN 設定がホストに送信されなくなります。
• 解決した問題 1780998：ドキュメントには NSX Manager が 1,000,000 個の監査ログ エントリを維持すると記載されているが、100,000 個しか保存されない

  監査ログに保存されるのは、100,000 個のログ エントリのみです。

• 解決した問題 1874735：クラスタにアラームがあると「アップグレードを利用可能」リンクが表示されない

  リンクが表示されない場合は、新しいサービスの仕様を ESX Agent Manager にプッシュできないため、サービスをアップグレードすることはできません。

• 解決した問題 1893299：ブロック デバイス、キャラクタ デバイスなど、通常のファイル以外のファイルに ODS スキャンを実行すると、システムがクラッシュまたはハングする場合がある

  ODS は、通常のファイルとシンボリック リンクのみをスキャンします。ブロック デバイスやキャラクタ デバイスなど、通常以外のファイルに直接アクセスすることはできません。これらのファイルがシンボリック リンクのリンク先になっている場合にはアクセスできます。これらのファイルにアクセスすると、システムのクラッシュやハングなど、予期しないアクションが発生する場合があります。

• 解決した問題 1897878：ユニバーサル サービス仮想マシン　(USVM) のメモリ　(CPU の場合あり) の使用率が高くなると、同じホスト上の仮想マシンの運用に問題が発生する

  メモリの使用率が高くなると、仮想マシンが応答不能になり、ログインできなくなります。

• 解決した問題 1882345：CPU の使用率が高くなると、100% に達した状態が続く

  IP アドレスの検出方法として ARP スヌーピングが有効になっており、vNIC ごとに異なる IP アドレスを持つ仮想マシンがある場合、CPU の使用率が増加し続けて 100% に達し、パフォーマンスが大幅に低下します。 

• 解決した問題 1920343：プライベート キーなしでサーバ証明書が作成される

  証明書のコンテンツにプライベート キーのデータが含まれていても、そのプライベート キーが無視されます。 

• 解決した問題 1926060：[ファイアウォール] > [送信元の指定] または [宛先の指定] の順に移動して、[送信元の無効化] または [宛先の無効化] チェックボックス以外の部分をクリックしても、このチェックボックスが選択される 

  オブジェクトを [使用可能なオブジェクト] リストから [選択したオブジェクト] リストに移動すると、[送信元の無効化] チェックボックスが選択されます。 

• 解決した問題 1965589：NSX 6.4.0 より前のリリースで生成された分散ファイアウォールのドラフトを NSX 6.4.0 で発行できない

  NSX 6.4 より前のリリースで作成されたドラフトには、ステートレス フラグ属性のついたレイヤー 2 セクションがありません。NSX　6.4 では、レイヤー 2 セクションのステートレス フラグが true に設定されていることが前提となるため、属性のないドラフトのロードや発行に失敗します。属性がないとデフォルト値（false など）が使用されるため、設定の検証でエラーとなり、発行に失敗します。

論理ネットワークと NSX Edge に関する解決した問題

• 解決した問題：コントローラ ログにブリッジの「Fail to add/delete a mac record MacRecord for non-existing bridge instance.」というエラーが大量に記録される

  シャーディングが変更されたとき、ブリッジによるコントローラへの参加の送信に失敗します。この問題は NSX 6.4.0 で修正されました。

• 解決した問題 2014400：Edge のファイアウォール機能を無効にすると、スタンバイ NSX Edge が IPv6 トラフィックへの応答を開始する

  NSX Edge で IPv6 が有効な場合、フェイルオーバーがトリガされると、上流のデバイスがスタンバイ Edge の MAC アドレスで更新されるため、North - South トラフィックが誤った Edge へ転送されてしまうことがあります。この問題は NSX 6.4.0 で修正されました。
  
   

• 解決した問題 1783065：IPv4 および IPv6 アドレスが共存する場合、TCP と一緒に UDP ポートのロード バランサを設定することができない
  UDP は ipv4-ipv4、ipv6-ipv6（フロントエンド - バックエンド）のみをサポートします。NSX Manager では、IPv6 のリンク ローカル アドレスさえも読み取られ、グループ オブジェクトの IP アドレスとしてプッシュされてしまい、ロード バランサ設定で使用する IP プロトコルを選択することができないというバグがあります。

  次はこの問題が発生するロード バランサ設定の例です。
  ロード バランサ設定で、「vCloud_Connector」プールはグループ オブジェクト (vm-2681) でプール メンバーとして設定されています。このオブジェクトには IPv4 と IPv6 のアドレスが両方とも含まれているため、これはロード バランサの L4 エンジンでサポートされません。

   

  {
                "algorithm" : {
          ...
      },
                "members" : [
          {
              ...  ,
              ...
          }
                ],
                "applicationRules" : [],
                "name" : "vCloud_Connector",
                "transparent" : {
                   "enable" : false
                }
          }
  
    {
                "value" : [
                   "fe80::250:56ff:feb0:d6c9",
                   "10.204.252.220"
                ],
                "id" : "vm-2681"
              }

   

• 解決した問題 1764258：サブインターフェイスが設定された NSX Edge で高可用性によるフェイルオーバーまたは強制同期が実行されると、トラフィックが最大 8 分間ブラックホール状態になる
  サブインターフェイスを介して、高可用性によるフェイルオーバーをトリガするか、強制同期を開始した場合、最大 8 分間ブラックホール状態が発生し、トラフィックが失われます。

   

• 解決した問題 1850773：ロード バランサの設定で複数のポートが使用されていると、NSX Edge の NAT の設定が無効であるとレポートされる
  この問題は、ロード バランサ仮想サーバに 2 つ以上のポートを設定するたびに発生します。この設定を修正しない限り、影響を受ける NSX Edge では NAT を管理できなくなります。

   

• 解決した問題 1733282：NSX Edge がデバイスのスタティック ルートをサポートしない
  NSX Edge は、ネクスト ホップのアドレスが NULL に設定されたスタティック ルートをサポートしていません。

   

• 解決した問題 1711013：スタンバイ仮想マシンの再起動後、アクティブ/スタンバイ NSX Edge 間の FIB の同期に約 15 分かかる
  スタンバイ NSX Edge がパワーオフになっている場合、アクティブ モードとスタンバイ モード間の TCP セッションが閉じられません。アクティブ Edge は、キープアライブ (KA) 障害（15 分）後に、スタンバイ Edge がダウンしていると判断します。15 分後に、スタンバイ Edge との新しいソケット接続が確立されると、FIB がアクティブ/スタンバイ Edge の間で同期されます。

   

• 解決した問題 1781438：ESG または分散論理ルーターの NSX Edge アプライアンスで、BGP パス属性 MULTI_EXIT_DISC を複数回受信すると、ルーティング サービスがエラー メッセージを送信しない
  BGP パス属性 MULTI_EXIT_DISC を複数回受信しても、Edge ルーターまたは分散論理ルーターがエラー メッセージを送信しません。RFC 4271 [Sec 5] により、特定の UPDATE メッセージのパス属性フィールドに同じ属性（同じタイプの属性）を複数回使用することはできません。

   

• 解決した問題 1860583：DNS にアクセスできない場合、FQDN を使用してリモートの syslogger を設定すると問題が発生する
  NSX Edge でリモートの syslogger が FQDN を使用して設定されていて、DNS にアクセスできない場合、ルーティング機能に影響する可能性があります。この問題は必ず発生するとは限りません。

   

• 解決した問題 1242207：実行時にルーター ID を変更しても OSPF トポロジに反映されない

  OSPF を無効にせずにルーター ID を変更すると、新しい外部 LSA (Link-State Advertisements) が新しいルーター ID で再生成されないため、OSPF 外部ルートが消失します。

• 解決した問題 1767135：ロード バランサの証明書とアプリケーション プロファイルにアクセスしようとするとエラーが発生する
  セキュリティ管理者の権限と Edge スコープが設定されているユーザーは、ロード バランサの証明書とアプリケーション プロファイルにアクセスできません。vSphere Web Client にエラー メッセージが表示されます。
• 解決した問題 1844546：分散論理ルーターの高可用性インターフェイスで、ユーザーが割り当てた IP アドレスを使用しても機能しない

  分散論理ルーターの高可用性インターフェイスで、ユーザーが割り当てた特定の IP アドレスを　1 つ入力した場合、その　IP アドレスは使用されません。また、複数の IP アドレスを入力すると、内部サーバ エラーが発生します。

• 解決した問題 1874782：メッセージ バスとの接続で問題が発生し、NSX Edge が管理不能になる

  NSX Edge でメッセージ バスとの接続に問題が発生すると、NSX Manager が NSX Edge の設定を変更したり、NSX Edge から情報を取得できなくなります。

• 解決した問題 1461421：NSX Edge の「show ip bgp neighbor」コマンドの出力で、以前接続を確立したカウントが維持される

  「show ip bgp neighbor」コマンドは、任意のピアに対して BGP ステート マシンが Established に遷移した回数を表示します。MD5 認証で使用されるパスワードを変更すると、ピア接続が破棄されて再作成されるため、カウンタがクリアされます。この問題は、Edge 分散論理ルーター (DLR) では発生しません。

• 解決した問題 1499978：Edge の Syslog メッセージがリモートの Syslog サーバに到達しない
  デプロイの直後は、Edge の Syslog サーバは設定済みのリモート Syslog サーバのホスト名を解決できません。
• 解決した問題 1916360：100 個を超えるルートを設定すると、ディスクがいっぱいになり、HA によるフェイルオーバーが失敗する場合がある

  100 個を超えるルートを設定すると、スタンバイ Edge の vmtools デーモンが 30 秒ごとに 2 つの警告ログ メッセージを送信します。ログは /var/log/vmware-vmsvc.log ファイルに保存されますが、ログ ファイルのサイズが大きくなり、ログ パーティションがいっぱいになる場合があります。このログ ファイルにはログのローテーションは設定されていません。この状態が発生すると、HA によるフェイルオーバーが失敗する場合があります。

• 解決した問題 1634215：OSPF CLI コマンド出力に、ルーティングが無効になっているかどうかが示されない

  OSPF が無効になっている場合でも、ルーティングの CLI コマンドの出力に「OSPF が無効」であることを示すメッセージが表示されません。出力は空白です。

• 解決した問題 1716464：NSX ロード バランサがセキュリティ タグで新規にタグ付けされた仮想マシンにルーティングしない
  2 台の仮想マシンを指定タグで展開し、ロード バランサがそのタグにルーティングするように設定すると、ロード バランサはこれらの 2 台の仮想マシンに正常にルーティングします。しかし、そのタグで 3 台目の仮想マシンを展開すると、ロード バランサは最初の 2 台の仮想マシンにのみルーティングします。
• 解決した問題 1935204：分散論理ルーターで ARP の解決に 1 秒～ 1.5 秒かかる

  ARP 抑制に失敗すると、ローカルの分散論理ルーターによるリモート ホストの仮想マシンの ARP 解決に 1 秒～ 1.5 秒かかります。 

• 解決した問題 1777792：「ANY」として設定されたピア エンドポイントによって IPsec 接続が失敗する
  NSX Edge の IPsec 設定がリモートのピア エンドポイントを「ANY」に設定すると、Edge は IPsec の「サーバ」として動作し、リモート ピアが接続の開始するまで待機します。ただし、イニシエータが PSK+XAUTH を使用して認証の要求を送信すると、Edge には次のエラー メッセージ「initial Main Mode message received on XXX.XXX.XX.XX:500 but no connection has been authorized with policy=PSK+XAUTH」が表示され、IPsec を確立することができません。
• 解決した問題 1881348：BGP のローカル　AS 番号　（Autonomous System Number) の設定で、AS_TRANS (ASN 23456) に問題がある

  BGP のローカル　AS 番号に、AS_TRANS (ASN 23456) を設定すると、ESG/分散論理ルーターで問題が発生し、 
  AS 番号を有効な番号に戻しても、BGP ネイバーが機能しません。

• 解決した問題 1792548：NSX Controller で次のメッセージが表示され、スタックする場合がある：Waiting to join cluster
  NSX Controller で次のメッセージが表示され、スタックする場合がある：Waiting to join cluster（CLI コマンド：show control-cluster status）。この問題は、NSX Controller の起動中に NSX Controller の eth0 インターフェイスと breth0 インターフェイスに同じ IP アドレスが設定されることが原因で発生します。NSX Controller で次の CLI コマンドを使用すると、インターフェイスの IP アドレスを確認できます。show network interface
• 解決した問題 1983497：ブリッジ フェイルオーバーとブリッジの設定変更が同時に発生すると、パープル スクリーンが表示される

  ブリッジ フェイルオーバーとブリッジの設定変更が同時に実行されると、デッドロックが発生し、パープル スクリーンが表示される場合があります。デットロックは頻繁に発生するわけではありません。 

• 解決した問題 1849042/1849043：NSX Edge アプライアンスでパスワードの有効期限が設定されている場合、管理者アカウントがロックされる
  NSX Edge アプライアンスで管理者ユーザーのパスワードに有効期間が設定されている場合、パスワードが期限切れになってから 7 日間は、ユーザーがアプライアンスにログインするときにパスワードの変更が要求されます。パスワードを変更しないと、アカウントがロックされます。また、CLI のプロンプトを使用してログイン時にパスワードを変更する場合、作成したパスワードの強度は、ユーザー インターフェイスや REST に適用されているパスワードの強度ポリシーを満たさない場合があります。
• 解決した問題 1982690：アクティブな L2 ブリッジ制御仮想マシンが稼動する ESXi ホストでは、NSX Controller がワークロード仮想マシンの MAC アドレス　エントリを保存しない

  アクティブなブリッジ制御仮想マシンが稼動しているハイパーバイザーでは、すべてのワークロード仮想マシンのトラフィックがドロップする場合があります。 

• 解決した問題 1753621：プライベート ローカル AS を含む Edge が EBGP ピアへのルートを送信すると、送信された BGP ルーティング更新からすべてのプライベート AS パスが削除される

  NSX for vSphere には現在、AS パスにプライベート AS パスのみが含まれている場合に、フル AS パスが eBGP ネイバーと共有されないようにする制限があります。これは通常の動作ですが、管理者がプライベート AS パスを外部 BGP ネイバーと共有したい場合には問題となります。この修正により、外部 BGP ピアとプライベート AS パスを共有できるように動作を変更できます。この機能はデフォルトで、プライベート ASN を削除します。これは NSX for vSphere の以前のバージョンに合わせた動作です。

• 解決した問題 1954964：スプリット ブレインの後、スタンバイ ESG で高可用性 (HA) エンジンのステータスが正しく更新されない

  特定の状況下では、スプリット ブレインのリカバリ後、スタンバイ ESG 構成エンジンのステータスが正しく更新されない場合があります。これにより整合性のない状態となり、トラフィックのドロップが断続的に発生する可能性があります。

• 解決した問題 1920574：Edge のサブ インターフェイスを設定できない

  NSX for vSphere 6.3.2/6.3.3 で Edge にサブインターフェイスを作成することに失敗します。IP アドレスを持つサブ インターフェイスを発行できません。

• 解決した問題 1772473：SSL VPN クライアントが IP アドレス プールから IP アドレスを取得できない

  IP アドレスが IP アドレス プールから割り当てられないため、クライアントがプライベート ネットワークに接続できません。IP アドレス プールの IP アドレスは、クライアントが自動的に再接続する際に割り当てられます。

  SSL VPN クライアントがサーバに自動で再接続するとき、IP アドレス プールから IP アドレスが割り当てられないため、クライアントはプライベート ネットワークに接続できません。また、IP アドレス プールからクライアントに割り当てられた以前の IP アドレスは消去されません。

NSX Manager に関する解決した問題

• 解決した問題 1804116：分散論理ルーターが、NSX Manager との通信を失ったホスト上で不整合状態になる
  分散分散論理ルーターがパワーオンの状態または NSX VIB のアップグレード/インストールの失敗またはホスト通信の問題が原因で、NSX Manager との通信を失ったホスト上に再デプロイされると、分散論理ルーターは不整合の状態になり、Force-Sync を使用した連続自動リカバリの操作に失敗します。
• 解決した問題 1786515：「Security Administrator」権限を持つユーザーが、vSphere Web Client ユーザー インターフェイスでロード バランサの設定を編集することができない
  特定の NSX Edge の「Security Administrator」権限を持つユーザーが、vSphere Web Client のユーザー インターフェイスを使用して、この Edge のロード バランサのグローバル設定を編集することができません。次のようなエラー メッセージが表示されます。「ユーザーはオブジェクト Global および機能 si.service にアクセスする権限がありません。このユーザーのオブジェクト アクセス スコープおよび機能の権限を確認してください。」
• 解決した問題 1801325：NSX Manager で CPU またはディスクの使用率が高くなると、「重大」レベルのシステム イベントとログが生成される
  NSX Manager で、ディスクの使用率が高い、ジョブ データのチャーン率が高い、またはジョブ キュー サイズが大きいと、次の問題が 1 つ以上発生することがあります。
  • vSphere Web Client で「重大」レベルのシステム イベントが発生する
  • /common パーティションで NSX Manager のディスク使用率が高くなる
  • CPU の使用率が長期間または定期的に高くなる
  • NSX Manager のパフォーマンスが低下する

  回避策：VMware サポートにお問い合わせください。詳細については、VMware のナレッジベースの記事 KB2147907 を参照してください。

• 解決した問題 1902723：NSX Edge のファイル バンドルが、発行後に毎回 /common/tmp ディレクトリから削除されず、/common ディレクトリがいっぱいになる

  NSX Edge のファイル バンドル（sslvpn-plus 設定）が /common/tmp から削除されないため、/common ディレクトリがいっぱいになり、NSX Manager が使用可能な容量が不足します。

• 解決した問題 1954628：/common ディスクがいっぱいになるとリストア処理に失敗する

  /common ディスクがいっぱいになっている NSX Manager でバックアップをリストアすると、リストアに失敗する場合があります。このエラーは、アプライアンスのサマリ ページに表示されます。NSX Manager が整合性のない状態となり、復旧できません。

セキュリティ サービスに関する解決した問題

• 解決した問題 2029693：分散ファイアウォールのスケーリング環境（65K 以上のルール）で、分散ファイアウォール ルールの発行に時間がかかる場合がある

  ファイアウォール ルールは、発行から 10～15 分後に有効になります。この問題は NSX 6.4.0 で修正されました。

• 解決した問題 1662020：分散ファイアウォールのユーザー インターフェイスの [全般] および [パートナー セキュリティ サービス] セクションに、「前回の発行操作はホスト <ホストの番号> で失敗しました」という内容のエラー メッセージが表示され、発行操作に失敗する場合がある

  任意のファイアウォール ルールを変更した後、ユーザー インターフェイスに「前回の発行操作はホスト <ホストの番号> で失敗しました」というエラー メッセージが表示されます。ユーザー インターフェイスに表示されるホストは、正しいバージョンのファイアウォール ルールを使用していない可能性があり、そのためにセキュリティ上の不備や、ネットワークの中断が発生します。

  この問題は、通常次の状況で発生します。

  • NSX を最新のバージョンにアップグレードした後
  • ホストをクラスタの外部に移動した後で、再びクラスタに戻した場合
  • クラスタ内のホストを別のクラスタに移動した場合
• 解決した問題 1496273：ユーザー インターフェイスで、本来 Edge に適用できない、受信/送信の NSX ファイアウォール ルールを作成できる
  Web クライアントでは、1 つ以上の NSX Edge に適用される NSX ファイアウォール ルールの作成が誤って許可されてしまいます。これは、ルール内に「受信」または「送信」方向に移動するトラフィックがあり、PacketType が IPV4 または IPV6 の場合に発生します。NSX は、このようなルールを NSX Edge に適用できないため、ユーザー インターフェイスからこのようなルールを作成できないようにすべきです。
• 解決した問題 1854661：Cross-vCenter Server 環境で NSX Manager の切り替えを行うと、フィルタリングされたファイアウォール ルールにインデックス値が表示されない
  ルールのフィルタ条件を NSX Manager に適用し、別の NSX Manager に切り替えると、フィルタリングされたルールのルール インデックスが「0」になり、ルールの実際の位置が表示されません。
• 解決した問題 2000749：特定のファイアウォール設定を行うと、分散ファイアウォールが発行状態のままになる

  セキュリティ グループに除外メンバー、対象メンバーまたは「共通部分を含む動的メンバーシップ (AND)」の一部として 0.0.0.0/0 の IP セットが含まれていると、分散ファイアウォールが「発行」状態のままになります。

• 解決した問題 1628679：ID ベースのファイアウォールを使用すると、削除されたユーザーの仮想マシンが Security Group の一部であり続ける

  Active Directory サーバで、ユーザーをグループから削除しても、ユーザーがログインしている仮想マシンはセキュリティ グループにそのまま所属し続けます。これにより、ハイパーバイザーの仮想マシン vNIC でファイアウォール ポリシーが保持され、サービスへの完全なアクセス権限がユーザーに付与されます。

• 解決した問題 1787680：NSX Manager が移行モードにある場合、ユニバーサル ファイアウォール セクションの削除に失敗する
  移行モードで NSX Manager のユーザー インターフェイスからユニバーサル ファイアウォール セクションを削除し、発行しようとすると、発行に失敗し、その結果 NSX Manager をスタンドアロン モードに設定できなくなります。
• 解決した問題 1773240：セキュリティ管理者ロールでサービス挿入/リダイレクション ルールを編集または発行できない

  セキュリティ管理者のロール/権限を持つユーザーがサービス挿入ルールの作成/変更/発行を行うと、操作が失敗します。

• 解決した問題 1845174：システム ポリシーを割り当てると、ユーザー インターフェイスからすべてのセキュリティ グループが表示されなくなる

  システム ポリシーを割り当てると、ユーザー インターフェイスからすべてのセキュリティ グループが表示されなくなります。

• 解決した問題 1839953：ゲスト仮想マシンで、サブ インターフェイスの IP アドレスの ARP 抑制に失敗する

  ゲスト仮想マシンで、サブ インターフェイスの ARP 抑制を初めて行う場合、通常（1 秒）よりも若干時間がかかります。

既知の問題

既知の問題には次の項目が含まれます。

• 一般的な既知の問題
• インストールとアップグレードに関する既知の問題
• NSX Manager に関する既知の問題
• 論理ネットワークと NSX Edge に関する既知の問題
• セキュリティ サービスに関する既知の問題
• 監視サービスに関する既知の問題

一般的な既知の問題

• 問題 1931236：ユーザー インターフェイスのタブにシステム テキストが表示される

  ユーザー インターフェイスのタブにシステム テキストが表示されます。たとえば、「システムのスケール」ではなく、「Dashboard.System.Scale.Title」が表示されます。

  回避策：ブラウザの Cookie を削除して、ブラウザを更新します。あるいは、vSphere Client からログアウトして再度ログインします。

• vSphere Web Client で、Flex コンポーネントを開いて HTML の画面に重ねると、画面が表示されなくなる

  メニューやダイアログなどの Flex コンポーネントを開き、HTML 画面に重ねると、画面が一時的に非表示になります。
  (参照：http://pubs.vmware.com/Release_Notes/en/developer/webclient/60/vwcsdk_600_releasenotes.html#issues)

  回避策：なし。 

• 問題 1944031：DNS 監視機能の健全性チェックで、他のポートではなく、デフォルトのポート 53 が使用される

  バックエンド サーバへの健全性チェックを実行するときに、サービス監視機能がプール メンバーの監視ポートを使用してしまいます。設定された監視ポートに関係なく、DNS の監視は、デフォルトのポート 53 を使用します。バックエンド DNS サーバの待機ポートを 53 以外の値に変更すると、DNS の監視でエラーが発生します。

• 問題 1874863：ローカル認証サーバで SSL VPN サービスを無効にして有効にすると、変更後のパスワードで認証されない

  ローカル認証を使用するときに、SSL VPN サービスを無効にして再度有効にすると、変更後のパスワードでログインできません。

  詳細については、VMware ナレッジベースの記事 KB2151236 を参照してください。

• 問題 1702339：脆弱性スキャナが Quagga bgp_dump_routes の脆弱性 (CVE-2016-4049) をレポートすることがある

  NSX for vSphere で、脆弱性スキャナが Quagga bgp_dump_routes の脆弱性 (CVE-2016-4049) をレポートすることがあります。NSX for vSphere は Quagga を使用しますが、この脆弱性の原因となる BGP 機能は使用していません。この脆弱性アラートは、無視しても問題ありません。

  回避策： 問題による製品への影響はないので、パッチを適用する必要はありません。

• 問題 1926467：Chrome バージョン 59.0.3071.115 で NSX Manager アプライアンスを開くとカーソルが表示されない

  Chrome バージョン 59.0.3071.115 で NSX Manager アプライアンスを開くと、ユーザー名とパスワードの入力でカーソルが表示されません。カーソルは表示されませんが、認証情報は入力できます。 

  回避策： Chrome ブラウザを 61.0.3163.100 または 64.0.3253.0 以降にアップグレードします。 

• 問題 2015520：ブリッジ名が 40 文字を超えると、ブリッジの設定に失敗する

  ブリッジ名が 40 文字を超えると、ブリッジの設定に失敗します。

  回避策：ブリッジを設定するときに、ブリッジ名を 40 文字以下にします。

• 問題 1934704：ブリッジ名で ASCII 以外の文字を使用できない

  分散論理ルーターでブリッジ名に ASCII 以外の文字を設定すると、ホストにブリッジ設定が表示されず、ブリッジ データ パスが機能しません。

  回避策：ブリッジ名に ASCII 文字を使用します。

• 問題 1529178：共通名を含まないサーバ証明書をアップロードすると、「内部サーバ エラー」のメッセージが返される

  共通名を含まないサーバ証明書をアップロードすると、「内部サーバ エラー」のメッセージが表示されます。

• 問題 2013820：異なる IP アドレス フィルタ ポリシーを使用している別のプールと、グループ オブジェクト プール メンバーを共有できない

  異なる IP アドレス フィルタ ポリシーを使用している別のプールと、グループ オブジェクト プール メンバーを共有できません。

  回避策：

  1. グループ オブジェクト プール メンバーをプール間で共有する必要がある場合は、すべてのプールで同じ IP アドレス フィルタ ポリシーを使用する必要があります。
  2. 異なる IP アドレス フィルタ ポリシーを使用している別のプールと共有する場合は、グループ オブジェクトの IP アドレスをプール メンバーとして直接使用します。
• 問題 2016689：RDSH ユーザーに対する　SMB アプリケーション　ルールがサポートされない

  SMB アプリケーションをブロック/許可する RDSH ファイアウォール ルールを作成しても、ルールが開始されません。

  回避策：なし。

• 問題 2007991: 分散ファイアウォールで、RDP 4.0、5.0、5.1、5.2、6.0 を使用するリモート デスクトップ サーバまたはクライアントが L7 プロトコルとして分類されない

  ユーザー環境で、RDP 4.0、5.0、5.1、5.2、6.0 のサーバまたはクライアントを使用している場合、APP_RDP を使用するレイヤー 7 分散ファイアウォール ルールで、RDP トラフィックがサービスとして分類または識別されません。分散ファイアウォール ルールで RDP トラフィックをブロックするように設定していても、トラフィックがブロックされない場合があります。

  回避策：レイヤー 4 RDP サービスを使用して、RDP トラフィックRDP トラフィックが一致可能なレイヤー 4 ルールを作成します。

• 問題 1993691: レプリケーション ノードの設定を解除せずにホストを削除すると、NSX Manager に古いエントリが残る

  ハードウェア VTEP のレプリケーション ノードとして機能しているホストを親クラスタから削除する際、クラスタから削除する前にレプリケーション ノードでないことを確認する必要があります。これを確認しないと、NSX Manager データベースのステータスがレプリケーション ノードのままになり、この状態でレプリケーション ノードを操作すると、エラーが発生します。

  回避策：詳細については、ナレッジベースの記事 KB52418 を参照してください。

• 問題 2164138: NSX のクラスタを準備しているときに、ixgbe ドライバを実行している物理 NIC のホストで ixgbe ドライバが再ロードされる

  Receive Side Scaling (RSS) オプションを有効にして VXLAN のスループットを向上させるため、ixgbe ドライバが再ロードされます。ixgbe ドライバが再ロードされると、ixgbe ドライバを使用している vmnic が数秒間停止し、再起動します。まれに、ixgbe ドライバの再ロードが失敗し、ESXi ホストを再起動するまで ixgbe ドライバを使用する vmnic が停止状態になることがあります。

  回避策：詳細については、VMware のナレッジベースの記事 KB52980 を参照してください。

インストールとアップグレードに関する既知の問題

アップグレードの前に、このドキュメントの前半の「アップグレードに関する注意事項」を参照してください。

• 問題 2036024：データベースのデイスク使用率が原因で、NSX Manager のアップグレードが「アップロードされたファイルの検証」でスタックする

  アップグレード ログ ファイル「vsm-upgrade.log」には、次のメッセージが含まれます。"Database disk usage is at 75%, but it should be less than 70%"（データベースのディスク使用率が 75% に達しています。使用率は 70% 未満でなければなりません）vsm-upgrade.log は NSX Manager サポート バンドルで確認できます。[Networking and Security] > [サポート バンドル] の順に移動し、NSX Manager ログを含めることを選択します。

  回避策：VMware サポートにお問い合わせください。

• 問題 2033438：NSX 6.4.0 にアップグレードし、TLS 1.0 のみを有効にすると、vSphere Web Client に「使用可能な NSX Manager はありません」と表示される

  NSX 6.4.0 へのアップグレードでは、TLS の設定が維持されます。TLS 1.0 のみを有効にする場合、vSphere Web Client に NSX プラグインが表示されますが、NSX Manager は表示されません。データパスに影響はありませんが、NSX Manager の設定を変更することはできません。

  回避策：https://nsx-mgr-ip/ で NSX アプライアンスの管理 Web ユーザー インターフェイスにログインして、TLS 1.1 と TLS 1.2 を有効にします。これにより、NSX Manager アプライアンスが再起動されます。

• 問題 2006028：アップグレード中に vCenter Server システムが再起動すると、ホストのアップグレードに失敗する場合がある

  ホストのアップグレード中に関連する vCenter Server システムが再起動すると、ホストのアップグレードに失敗し、ホストがメンテナンス モードになる場合があります。[解決] をクリックしても、ホストがメンテナンス モードから切り替わりません。クラスタのステータスは「準備ができていません」になります。

  回避策：ホストのメンテナンス モードを手動で終了します。クラスタで [準備ができていません] をクリックして、[すべて解決] をクリックします。

• 問題 1959940：ovftool を使用して NSX Manager OVF をデプロイすると、次のエラーが発生する。「ネット マッピングに無効な OVF 名 (VSMgmt) が指定されています」

  NSX 6.4.0 以降では、アプライアンス OVF のネット マッピングで VSMgmt は使用できなくなりました。有効な名前は「Management Network」になります。

  回避策： 「Management Network」を使用します。たとえば、--net:VSMgmt='VM Network' ではなく、--net:'Management Network=VM Network' を使用します。

• 問題 2001988：NSX ホスト クラスタのアップグレードで各クラスタをアップグレードしているときに、[ホストの準備] タブでクラスタ全体のインストール状況を確認すると、「準備ができていません」と「インストール中」が交互に表示される

  NSX のアップグレードで、NSX が準備したクラスタの「アップグレードを利用可能」をクリックすると、ホストのアップグレードを開始します。DRS FULL AUTOMATIC が設定されたクラスタの場合、ホストのアップグレードがバックグラウンドで問題なく実行されているにも関わらず、インストール状況として「インストール中」と「準備ができていません」が交互に表示されます。

  回避策：これはユーザー インターフェイスの問題で、無視しても問題ありません。ホスト クラスタのアップグレードが完了するまでお待ちください。

• 問題 1859572: vCenter Server バージョン 6.0.0 で管理されている ESXi ホストから NSX バージョン 6.3.x の NSX VIB をアンインストールすると、ホストがメンテナンス モードのままになる
  クラスタで NSX 6.3.x の NSX VIB をアンインストールする場合、vSphere ESX Agent Manager (EAM) サービスがホストをメンテナンス モードに切り替え、VIB をアンインストールし、ホストのメンテナンス モードを解除します。ただし、ホストを vCenter Server 6.0.0 で管理している場合、VIB のアンインストール後にホストがメンテナンス モードのままになります。VIB をアンインストールする EAM サービスは、ホストをメンテナンス モードに切り替えることはできますが、メンテナンス モードの解除に失敗します。

  回避策：ホストのメンテナンス モードを手動で解除します。vCenter Server バージョン 6.5a 以降でホストを管理している場合、この問題は発生しません。

• 問題 1797929：ホスト クラスタのアップグレード後に、メッセージ バス チャネルが停止する
  ホスト クラスタ アップグレードの後、vCenter Server 6.0（およびそれ以前）ではイベント「reconnect」が生成されず、その結果 NSX Manager はホスト上でメッセージング インフラストラクチャをセットアップしませんでした。vCenter Server 6.5 で、この問題は修正されました。

  回避策：次のようにメッセージング インフラストラクチャを再同期します。
  POST https://<ip>:/api/2.0/nwfabric/configure?action=synchronize

  <nwFabricFeatureConfig>
          <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
          <resourceConfig>
              <resourceId>host-15</resourceId>
          </resourceConfig>
      </nwFabricFeatureConfig>

• 問題 1263858: SSL VPN がアップグレード通知をリモート クライアントに送信しない
  SSL VPN ゲートウェイはアップグレード通知をユーザーに送信しません。管理者は、SSL VPN ゲートウェイ（サーバ）が更新されたことと、リモート ユーザーが自分のクライアントを更新しなければならないことを、リモート ユーザーに手動で通知する必要があります。

  回避策： ユーザーは旧バージョンのクライアントをアンインストールして、最新バージョンを手動でインストールする必要があります。

• 問題 1979457：アップグレードまたは後方互換性モードで、ゲスト イントロスペクション サービス仮想マシンが削除されると、ゲスト イントロスペクション クラスタがアップグレードされるまで、ゲスト イントロスペクション経由で Identity Firewall が機能しない

  Identity Firewall が機能せず、Identity Firewall に関連するログが表示されないクラスタがアップグレードされない限り、Identity Firewall による保護が中断したままになる 

  回避策： すべてのホストで最新バージョンのゲスト イントロスペクション サービス仮想マシンが実行されるように、クラスタをアップグレードします。

  または

  Identity Firewall が機能するようにログ スクレーパを有効にします。

• 問題 2016824：ゲスト イントロスペクション (GI) のインストールまたはアップグレード後に、NSX コンテキスト エンジンを起動できない

  ホストの準備が完了する前にゲスト イントロスペクションをインストールまたはアップグレードすると、この問題が発生します。コンテキスト エンジンが起動しないと、RDSH 仮想マシンの Identity Firewall が機能しません。

  回避策：詳細については、VMware のナレッジベースの記事 KB51973 を参照してください。

• 問題 2027916：アップグレード コーディネータで、アップグレードに失敗したコントローラが正常にアップグレードされたと表示される場合がある

  3 台のノード コントローラから構成されるクラスタで、3 台目のコントローラのアップグレードに失敗して、コントローラが削除されていても、コントローラ クラスタ全体のアップグレードが成功とマークされる場合があります。

  回避策： 他のコンポーネント（ホスト、Edge など）をアップグレードする前に、[インストールとアップグレード] > [管理] タブの順に移動して、すべてのコントローラが「アップグレード済み」と表示されていることを確認します。

NSX Manager に関する既知の問題

• 問題 1991125：NSX Manager を 6.4.0 にアップグレードした後、6.3.x のアプリケーション ルール マネージャ セッションで作成したグループ オブジェクトがダッシュボードに表示されない

  NSX Manager を 6.4.0 にアップグレードした後、6.3.x のアプリケーション ルール マネージャ セッションで作成したグループ オブジェクトがダッシュボードに表示されません。

  回避策：NSX Manager を 6.4.0 にアップグレードした後でも、6.3.x のアプリケーション ルール マネージャ セッションで作成したグループ オブジェクトは使用可能です。[グループ オブジェクト] セクションの各ページで、グループ オブジェクトを使用できます。

• 問題 1892999：ユニバーサル セキュリティ タグに関連する仮想マシンがない場合でも、独自の選択基準を変更できない

  ユニバーサル セキュリティ タグが設定されている仮想マシンを削除しても、仮想マシンを表す内部オブジェクトにはユニバーサル セキュリティ タグが残ります。このため、ユニバーサル選択基準の変更に失敗し、ユニバーサル セキュリティ エラーが仮想マシンに関連付けられていることを通知するエラーが返されます。

  回避策： すべてのユニバーサル セキュリティ タグを削除して、ユニバーサル選択基準を変更します。

論理ネットワークと NSX Edge に関する既知の問題

• 問題 1983902：スケーリングを行った環境で、NSX Manager の再起動後すぐに netcpad が vsfwd に接続しない

  これにより、データパスに影響が及ぶことはありません。操作を行わなくても 13 分後にシステムがリカバリします。

  回避策： なし。

• 問題 1747978：NSX Edge 高可用性のフェイルオーバー後に、OSPF 隣接関係が MD5 認証で削除される
  NSX for vSphere 6.2.4 環境で、NSX Edge が高可用性構成となっており、OSPF グレースフル リスタートが設定され、認証に MD5 が使用される場合、OSPF は正常に起動できません。隣接関係は、Dead タイマーが OSPF ネイバー ノード上で終了した後にのみ発生します。

  回避策：なし。

• 問題 1525003：誤ったパスフレーズを使用して NSX Manager のバックアップをリストアしようとすると、クリティカルなルート フォルダにアクセスできないため、警告なしで操作に失敗する
  

  回避策： なし。

• 問題 1995142：ホストを vCenter Server インベントリから削除したあと、レプリケーション クラスタから削除されない

  ユーザーがレプリケーション クラスタにホストを追加し、該当のホストをクラスタから削除する前に、vCenter Server インベントリから先に削除すると、ホストがクラスタに残ったままになります。

  回避策：ホストを削除するときは、必ずレプリケーション クラスタから先に削除します。

• 問題 2005973：いくつかの GRE トンネルを削除し、管理プレーンから Edge ノードの強制同期を行うと、ルーティング デーモン MSR がすべてのルーティング設定を失う

  この問題は、GRE トンネル経由で BGP セッションを使用している Edge で発生することがあります。GRE トンネルを削除し、管理プレーンから Edge の強制同期を行うと、すべてのルーティング設定が失われます。

  回避策：Edge ノードを再起動してください。

• 問題 2015368：ファイアウォールのログの収集でメモリ不足が発生することがある

  大規模な構成で Edge ファイアウォールを有効にし、一部またはすべてのルールでファイアウォールのログの収集を有効にすると、まれに Edge でメモリ不足 (Out-Of-Memory) が発生します。この問題は、特に、ログの収集ルールに影響する大量のトラフィックによって発生します。メモリ不足が発生すると、Edge 仮想マシンが自動的に再起動します。

  回避策：デバッグを行う場合にのみファイアウォールのログの収集を有効にし、それ以外の場合は無効にします。この問題を回避するには、すべてのファイアウォールのログの収集を無効にします。

• 問題 2005900: 8-way iBGP/マルチホップ BGP ECMP の大規模なトポロジで、すべての GRE トンネルがフラップすると、CPU 使用率が 100% になり、Edge でルーティング デーモン MSR がスタックする

  この問題は、ESG で iBGP またはマルチホップ BGP が設定され、多くの GRE トンネルにまたがって複数のネイバーが確立されている大規模なトポロジで発生する可能性があります。複数の GRE トンネルがフラップすると、CPU 使用率が 100% になり、MSR がスタックする場合があります。

  回避策：Edge ノードを再起動してください。

セキュリティ サービスに関する既知の問題

• 問題 1948648：RDSH Identity Firewall ルールを使用しているログイン ユーザーに Active Directory グループ メンバーシップの変更がすぐに反映されない

  RDSH Identity Firewall ルールが作成されます。Active Directory ユーザーが RDS デスクトップにログインし、ファイアウォール ルールが有効になります。Active Directory 管理者が Active Directory ユーザーのグループ メンバーシップを変更し、NSX Manager で差分同期が実行されます。このとき、ログイン ユーザーに Active Directory グループ メンバーの変更がすぐに表示されず、ユーザーのファイアウォール ルールに変更が反映されません。これは、Active Directory の制限が原因で発生しています。

  回避策：Active Directory のグループ メンバーシップの変更を反映するには、ユーザーがログオフして再度ログインしなければなりません。 

• 問題 2017806：セキュリティ ポリシーの RDSH ファイアウォール セクションで、セキュリティ グループにメンバーを追加するときに表示されるエラー メッセージが明瞭でない

  セキュリティ ポリシーの RDSH ファイアウォール セクションでセキュリティ グループが使用されている場合、グループに追加できるのはディレクトリ グループのメンバーだけです。ディレクトリ グループ以外のメンバーを追加すると、次のエラーが表示されます。
  "Security group is being used by service composer, Firewall and cannot be modified"（Service Composer とファイアウォールによってセキュリティ グループが使用されているため、変更できません）
  
  このエラー メッセージは「セキュリティ グループがセキュリティ ポリシーの RDSH ファイアウォール セクションで使用されているため、セキュリティ グループを変更できない」という意味ではありません。

  回避策：なし。

• 問題 2026069：NSX Edge IPsec VPN サービスで暗号化アルゴリズムに 3DES 暗号を使用していると、アップグレード後に IPsec サイトへの IPsec トンネルが切断される場合がある

  NSX Edge IPsec VPN サービスの暗号化アルゴリズムに 3DES を使用することは、セキュリティ上の理由からお勧めしません。ただし相互運用性の理由により、バージョン 6.4 までの NSX リリースでは、この暗号を使用することができます。セキュリティの推奨に基づいて、この暗号のサポートは NSX for vSphere の次のリリースから削除される予定です。そのため、暗号化アルゴリズムに 3DES を使用している場合は使用を中止し、IPsec サービスで使用できる安全な暗号に切り替える必要があります。この暗号化アルゴリズムの切り替えは、IKE SA (phase1) だけでなく、IPsec サイトの IPsec SA (phase2) ネゴシエーションにも適用されます。

  NSX Edge IPsec サービスで 3DES 暗号化アルゴリズムを使用している場合、サポートが終了しているリリースにアップグレードすると、推奨される別の暗号に置き換わります。このため、NSX Edge で使用される暗号化アルゴリズムに合わせて設定またはリモート ピアを変更しない限り、3DES を使用していた IPsec サイトに接続できなくなります。

  回避策： IPsec サイトの設定で、暗号化アルゴリズムを 3DES からサポート対象の AES (AES/AES256/AES-GCM) に変更します。たとえば、暗号化アルゴリズムが 3DES に設定されている IPsec サイトの設定で、3DES を AES に変更します。これに合わせて、ピア エンドポイントで IPsec の設定を更新します。

• 問題 1648578：新しい NetX ホストベースのサービス インスタンスの作成時に、NSX でクラスタ/ネットワーク/ストレージの追加が強制される
  vSphere Web Client からファイアウォール、IDS、IPS などの NetX ホストベース サービス用に新しいサービス インスタンスを作成する際に、クラスタ/ネットワーク/ストレージの追加が不要な場合でも強制されます。

  回避策：新しいサービス インスタンスの作成時に、クラスタ/ネットワーク/ストレージに関する情報を追加し、フィールドに入力します。これにより、サービス インスタンスの作成が許可され、操作を続行できるようになります。

• 問題 2018077：カスタム L7 ALG サービスを含むルールに宛先ポートとプロトコルが指定されていないと、ファイアウォール ルールの発行に失敗する

  宛先ポートとプロトコルを指定せずに、L7 ALG APP (APP_FTP、APP_TFTP、APP_DCERPC、APP_ORACLE) を選択して L7 サービスを作成し、このサービスをファイアウォール ルールで使用すると、ファイアウォール ルールの発行に失敗します。

  回避策：次の ALG サービスにカスタム L7 サービスを作成するときに、宛先ポートとプロトコル (TCP/UDP) に適切な値を設定します。

  • APP_FTP：ポート 21、プロトコル：TCP
  • APP_TFTP：ポート 69、プロトコル：UDP
  • APP_DCERPC：ポート 135、プロトコル：TCP
  • APP_ORACLE：ポート 1521、プロトコル：TCP
• 問題 1980551：NSX Manager がデフォルトで TLSv1 をサポートしない

  TLSv1 を使用して NSX Manager に接続すると、接続に失敗します。 

  回避策： TLS の新しいバージョン（TLSv1.1 または TLSv1.2）を使用します。 

  TLSv1.0 の使用は推奨していません。このバージョンは今後のリリースで削除される予定ですが、NSX Manager で有効にすることは可能です。手順については、『NSX for vSphere API ガイド』「セキュリティ設定の操作」を参照してください。セキュリティ設定を変更すると、NSX Manager が再起動します。 

• 問題 2006576: 同じサービスがデプロイされているクラスタ間で、サービス挿入が有効になっているゲスト仮想マシンを移動すると、保存された状態（サービス挿入フィルタに一致するトラフィックの接続情報）が失われる

  vMotion のターゲット クラスタが元のクラスタと同じでない場合、NetX（サービス挿入）ルールが設定されているゲスト仮想マシンで、これらの NetX ルールが一時的に使用できなくなります。

  回避策： クラスタ内でサービス挿入フィルタが設定されているゲスト仮想マシンの vMotion を制限します。

監視サービスに関する既知の問題

• 問題 1466790：NSX トレースフロー ツールを使用してブリッジ ネットワーク上の仮想マシンを選択することができない
  NSX トレースフロー ツールを使用して、論理スイッチに接続されていない仮想マシンを選択することはできません。つまり、L2 ブリッジ ネットワーク上の仮想マシンの場合、トレースフロー検査の送信元アドレスまたは宛先アドレスとして仮想マシン名を選択することはできません。

  回避策： L2 ブリッジ ネットワークに接続された仮想マシンの場合、インターフェイスの IP アドレスまたは MAC アドレスを使用すれば、トレースフロー検査の宛先として指定できます。L2 ブリッジ ネットワークに接続された仮想マシンを送信元として選択することはできません。詳細については、ナレッジベースの記事 KB2129191 を参照してください。