This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

VMware NSX-T Data Center 3.2 | 2021 年 12 月 16 日 | ビルド 19067070

各リリース ノートで、追加および更新された機能をご確認ください。

NSX-T Data Center 3.2.0 に関する重要な情報

VMware NSX チームでは、以前のバージョンから NSX-T Data Center 3.2.0 にアップグレードする際の問題が見つかったため、このリリースをダウンロード ページから削除し、NSX-T Data Center 3.2.0.1 に切り替えることにしました。

NSX-T Data Center 3.2.0 をダウンロードして展開したユーザーは引き続きサポートされますが、NSX-T Data Center 3.2.0.1 にアップグレードすることをお勧めします。

新機能

NSX-T Data Center 3.2.0 は、ネットワーク、セキュリティ、サービス、オンボーディングなど、NSX-T のすべての分野で多くの新機能を提供するメジャー リリースです。主な機能強化は次のとおりです。

  • スイッチに依存しない分散セキュリティ:vSphere ネットワークに展開されたワークロードにマイクロセグメンテーションを拡張する機能。
  • ゲートウェイ セキュリティ:強化された L7 アプリケーション ID、マルウェア検出とサンドボックス、URL フィルタリング、ユーザー ID ファイアウォール、TLS 検査(テクニカル プレビュー)、侵入検知/防止サービス(IDS/IPS)。
  • 強化された分散セキュリティ機能:マルウェアの侵入検知/防止、動作 IDS/IPS、強化されたアプリケーション ID(L7 ファイアウォール)。
  • NSX Advanced Load Balancer(旧称 Avi)との統合の強化:NSX-T UI から NSX ALB (Avi) をインストールして構成します。NSX for vSphere LB を NSX ALB (Avi) に移行します。
  • NSX for vSphere から NSX-T への移行:Migration Coordinator の大幅な機能強化により、サポートされる NSX for vSphere トポロジのカバレッジが拡張され、ターゲット NSX-T トポロジの柔軟性が強化されました。
  • Log4j の脆弱性に対する保護の強化:CVE-2021-44228 および CVE-2021-45046 の脆弱性を解決するための Apache Log4j バージョン 2.16 への更新。これらの脆弱性と VMware 製品が受ける影響の詳細については、VMSA-2021-0028 を参照してください。

これらの機能以外にも、さまざまな機能が追加されています。

レイヤー 2 ネットワーク

  • Windows 物理サーバでのデュアル NIC ボンディングのサポート - 物理サーバでデュアル物理 NIC (pNIC) ボンディングを使用した接続がサポートされるようになりました。これにより、アクティブ/アクティブまたはアクティブ/スタンバイのボンディングを構成できます。この機能は、VLAN およびオーバーレイ ネットワークでサポートされます。
  • NUMA 対応チーミング ポリシー - ESXi からの送信に使用される物理 NIC と同じ NUMA ノードでのトラフィックの処理がサポートされるようになりました。この機能により、複数の NUMA 間でチーミング ポリシーを利用した展開のパフォーマンスが向上します。
  • 拡張データパスの新機能 - 拡張データパス スイッチで、分散ファイアウォール (DFW)、分散ロード バランサ (DLB)、ポート ミラーリング機能がサポートされるようになりました。

レイヤー 3 ネットワーク

  • L3 EVPN ルート サーバ モードのサポート - ESXi で、VXLAN トラフィックをデータセンター ファブリック ルーターに直接送信し、データパスの Edge ノードをバイパスできるようになりました。この展開モデルでは、Edge ノードでホストされる Tier-0 SR(サービス ルーター)は、制御プレーンの処理でのみ必要になります(たとえば、接続されたプレフィックスを EVPN l2vpn アドレス ファミリを介してファブリックにアドバタイズする場合など)。ESXi で、ファブリック内の複数の物理ルーターに対する ECMP がサポートされるようになりました。BFD を使用して、ルーターの可用性をテストできます。
  • ESXi および KVM での 5-tuple ECMP - ECMP が有効な場合に、ESXi でホストされている分散ルーター(DR)で 5-tuple ハッシュ アルゴリズムがサポートされるようになりました。この機能では、IP アドレスの送信元、IP アドレスの宛先、IP プロトコル、レイヤー 4 ポートの送信元、レイヤー 4 ポートの宛先に基づいてハッシュが生成されます。これにより、使用可能なすべてのサービス ルーター(SR)でトラフィックをより適切に分散できます。
  • アクティブ/アクティブの Tier-0 ゲートウェイでのプロキシ ARP のサポート - 動的ルーティングを必要としないシンプルなトポロジで、アクティブ/アクティブ HA モードの Tier-0 ゲートウェイを使用できるようになりました。これにより、スループットが向上します。

マルチキャスト

  • Tier-0 SR でのマルチキャスト トラフィックに対するアクティブ/アクティブのサポート - 複数の Tier-0 SR(サービス ルーター)でマルチキャスト トラフィックの ECMP がサポートされるようになりました。これにより、マルチキャスト トラフィックのスループットが向上します。

Edge プラットフォーム

  • ベアメタル Edge での UEFI サポート - UEFI モードで実行されているサーバで、ベアメタル Edge ノードを展開できるようになりました。これにより、Edge ノードをより広範なサーバに展開できます。

分散ファイアウォール

  • 分散ファイアウォールで VDS スイッチの分散ポート グループに展開された仮想マシンをサポート - 以前のリリースでは、NSX は N-VDS スイッチポートにのみ分散セキュリティ機能を適用しました。このリリースでは、スイッチポートを N-VDS に変換することなく、分散ファイアウォール機能を VDS ベースの VLAN ネットワークで利用できます。
  • IP アドレスのグループでの動的タグ基準のサポート。
  • 物理サーバに対する分散ファイアウォールのサポート - Redhat Enterprise Linux 8.0 オペレーティング システム。
  • L7 ファイアウォールを使用するためのアプリケーション ID の追加。
  • 分散ファイアウォールのマルウェア防止(E-W ユースケース) - NSX 分散ファイアウォールに、高度な機械学習技術とサンドボックス機能を使用したゼロデイ マルウェアの侵入検知/防止機能が搭載されました。
  • IDFW の Active Directory 構成での選択的同期 - Identity Firewall の Active Directory 構成で、OU とユーザーの選択的な追加がサポートされるようになりました。
  • Identity Firewall の統計情報 - アクティブ ユーザーとアクティブなユーザー セッションに関する Identity Firewall の統計情報が含まれるように、セキュリティの概要 ダッシュボードが強化されました。
  • SMB プロトコルに対する Identity Firewall のサポート。

分散侵入検知/防止システム (D-IDPS)

  • VDS の分散ポート グループに展開された仮想マシンで分散 IDS/IPS がサポートされます。
  • 分散 IDS/IPS で動作ベースの侵入検知/防止をサポート - 分散 IDPS と Edge の両方で IDS シグネチャの新しいクラスを使用できるようになりました。これらのシグネチャは、マルウェア固有の動作を特定するのではなく、感染成功の兆候に関連する可能性のあるネットワーク動作を特定します。これには、ネットワーク内の Tor 通信の識別、大きいポート番号での自己署名 TLS 証明書の存在、ビーコン動作の検出などのより高度なステートフル検出が含まれます。このクラスのシグネチャは、重要度レベル「情報」によって識別されます。NSX NDR が有効になっている場合、これらのシグネチャによって生成されたアラートにさらに ML ベースの処理が適用され、特定の監視対象環境でアノマリの可能性が非常に高いケースが優先されます。
  • Trustwave と VMware シグネチャのキュレーションと組み合わせ - NSX IDS/IPS シグネチャ セットにより、VMware によって開発およびキュレーションされた新しい IDS ルールセットにアクセスできるようになりました。これにより、高いセキュリティ効果を実現し、誤検知の可能性を最小限に抑えることができます。このルールセットは、Trustwave や Emerging Threats などのサードパーティベンダーによって開発された検出と、VMware が開発したシグネチャのコーパスを組み合わせ、NSX IDS エンジン用に最適化されています。

ゲートウェイ ファイアウォール

  • ユーザー ID ベースのアクセス制御 - ゲートウェイ ファイアウォールに、次のユーザー ID ファイアウォール機能が追加されました。
    1. ユーザー認証システムとして Active Directory が使用されている環境では、NSX は Active Directory のログを利用します。
    2. それ以外の認証システムの場合、NSX は vRealize Log Insight ベースのログを利用して、ユーザー ID と IP アドレスのマッピングを識別できるようになりました。
  • 一連の L7 AppID の強化 - ゲートウェイ ファイアウォール機能が強化され、より多くの数のレイヤー 7 アプリケーションを識別できるようになりました。
  • 受信と送信の両方のトラフィックに対する TLS 検査(テクニカル プレビュー。本番環境では使用不可) - ネットワーク上で、暗号化されたトラフィックが増加しています。このリリースでは、TLS 検査機能と NSX ゲートウェイ ファイアウォールを利用して、暗号化されたトラフィックに Deep Packet Inspection と脅威侵入検知/防止サービスを実行できるようになりました。
  • URL フィルタリング(URL の分類とレピュテーションを含む) - このリリースでは、新しい URL フィルタ機能に基づいてインターネットへのトラフィックを制御できるようになりました。この機能を使用すると、URL カテゴリと URL のレピュテーションに基づいてインターネット アクセスを制御できます。分類とレピュテーション データを含む URL リポジトリが継続的に更新され、保護機能を更新します。
  • マルウェア分析とサンドボックスのサポート - NSX ゲートウェイ ファイアウォールのマルウェア検知で高度な機械学習技術とサンドボックス機能を使用できるようになりました。これにより、既知のマルウェアだけでなく、ゼロデイ マルウェアも検出できます。既知のマルウェアに関するデータは継続的に更新されます。(実際の本番環境に展開する前に、既知の問題 2888658 を参照してください。)
  • 侵入検知/防止(テクニカル プレビュー。本番環境での使用は不可) - NSX ゲートウェイ ファイアウォールに、侵入検知/防止機能 (IPS) がテクニカル プレビュー モードで追加されました。この機能セットを本番環境以外の展開で試すことができます。

新しい NSX Application Platform

NSX Application Platform - VMware NSX Application Platform は、NSX-T 3.2.0 で導入された新しいコンテナベースのソリューションです。高可用性、耐障害性、スケール アウト アーキテクチャを提供することで、いくつかのコア プラットフォーム サービスを提供します。これにより、次のような NSX の新機能が提供されます。

NSX Intelligence
NSX Metrics
NSX Network Detection and Response
NSX マルウェア防止

NSX Application Platform の展開プロセスが NSX ユーザー インターフェイスで完全に調整されます。このプロセスでは、サポートされている Kubernetes 環境が必要になります。インストールに必要なインフラストラクチャの前提条件と要件の詳細については、VMware NSX Application Platform の展開と管理ガイドを参照してください。

ネットワークの検出と応答

  • VMware Network Detection and Response は、IDPS、マルウェア、アノマリのイベントを侵入キャンペーンに関連付けて、ネットワーク上の脅威や悪意のあるアクティビティを特定するのに役立ちます。
  • イベントではなく脅威キャンペーンに関連付けることで、SOC オペレータは、アクションが必要な脅威のトリアージに集中できます。
  • Network Detection and Response は、分散 IDPS からの IDPS イベント、ゲートウェイからのマルウェア イベント(悪意のあるファイルのみ)、NSX Intelligence からのネットワーク アノマリ イベントを収集します。
    • NSX-T 3.2 では、NSX Network Detection and Response によってゲートウェイ IDPS(テクニカル プレビュー)のイベントが収集されません。
  • Network Detection and Response の機能はクラウドで実行され、次の 2 つのクラウド リージョンで使用できます。米国および EU。

詳細については、以下を参照してください。

VPN

  • VPN でサービス レベル アラームの強化 - IPsec サービス状態の詳細。
  • パケット トレースの追加のログ記録の詳細 - IPsec の SPI と交換情報を表示します。

ゲスト イントロスペクション

  • ゲスト イントロスペクションの機能強化 - ゲスト イントロスペクションは、ゲスト コンテキスト内で使用するための API セットをデータ プレーンに提供します。この機能強化により、適切な資格を持つユーザーにのみ、このアクセス権が付与されます。
  • GI での OS サポートの追加 - ゲスト イントロスペクションで CentOS 8.2、RHEL 8.2、SLES15 SP1、Ubuntu 20.04 がサポートされるようになりました。

フェデレーション

注:3.2.0 より前の NSX リリースでは、既存のローカル マネージャ サイトのオンボーディングがサポートされていますが、3.2.0 ではまだサポートされていません。このオンボーディング サポートは 3.2 の今後のポイント リリースで再導入される予定です。

  • ローカル マネージャ間の仮想マシン タグの複製のサポート - ディザスタ リカバリ (DR) で、複製された仮想マシンが DR の場所で再起動されます。セキュリティ ポリシーが NSX 仮想マシン タグに基づいている場合、リカバリ時にリモート ローカル マネージャで、これらの NSX タグが DR の場所に複製された仮想マシンに設定されている必要があります。NSX フェデレーション 3.2 では、ローカル マネージャ間の仮想マシン タグの複製がサポートされるようになりました。タグの複製ポリシーは、API を介してのみ構成できます。
  • フェデレーション通信の監視 - ロケーション マネージャのページに、グローバル マネージャとローカル マネージャ間のチャネルの遅延と使用状況が表示されるようになりました。これにより、フェデレーションのさまざまなコンポーネント間の健全性の可視性が向上します。
  • ファイアウォール ドラフト - グローバルマネージャでセキュリティ ポリシーのドラフトを使用できるようになりました。これには、自動ドラフトと手動ドラフトのサポートが含まれます。
  • グローバル マネージャ LDAP のサポート - グローバル マネージャで、ローカル マネージャでのサポートと同様に、ロールベースのアクセス制御 (RBAC) の LDAP ソースの構成がサポートされるようになりました。

コンテナのネットワークとセキュリティ

  • Antrea と NSX-T の統合 - NSX-T 分散ファイアウォールのユーザー インターフェイスから Antrea ネットワーク ポリシーを定義する機能が追加されました。ポリシーは、相互接続コントローラを使用して、Antrea 1.3.1-1.2.2 を実行している K8s クラスタに適用されます。また、インベントリ収集も追加されました。ポッド、ネームスペース、サービスなどの K8s オブジェクトが NSX-T インベントリに収集され、DFW ポリシーで選択できるようにタグ付けされます。Antrea Traceflow は、NSX-T Traceflow UI ページから制御できるようになりました。Antrea を使用してログ バンドルを K8s クラスタから収集できます。K8s Antrea クラスタ ノードで NSX-T データ プレーンを有効にするための必須要件はありません。
  • グループ化の機能強化 - Antrea コンテナ オブジェクトのサポートが追加されました。セグメント ポート タグの条件に Not In 演算子のサポートが追加されました。セグメントとセグメント ポートを含むグループ メンバーシップ基準の間で AND 演算子がサポートされるようになりました。

ロード バランシング

  • NSX を介した VMware NSX Advanced Load Balancer (Avi) のインストール - NSX-T Manager UI を使用して VMware NSX Advanced Load Balancer (Avi) Controller をインストールできるようになりました。これにより、すべての NSX コンポーネントを 1 つのペインでインストールできます。
  • NSX-T Manager UI からの VMware NSX Advanced Load Balancer (Avi) UI のクロス起動 - NSX-T Manager から VMware NSX ALB (Avi) UI を起動して、高度な機能を実行できます。
  • NSX 内での Advanced Load Balancer (Avi) ユーザー インターフェイスの表示 – NSX Manager 内から VMware NSX Advanced Load Balancer (Avi) を構成できます。
  • NSX for vSphere から VMware NSX Advanced Load Balancer (Avi) へのロード バランシングの移行 – Migration Coordinator で独自トポロジ モデルを使用するときに、ロード バランサを VMware NSX ALB (Avi) に移行します。
  • NSX-T ネイティブのロード バランサ - 今後、ロード バランシング機能の追加や拡張は行われません。NSX-T プラットフォームの機能拡張は、NSX-T ネイティブのロード バランサに拡張されません。
  • ロード バランシングの推奨事項
    • NSX-T でロード バランシングを使用している場合は、NSX-T ロード バランシング機能のスーパーセットを提供する VMware NSX Advanced Load Balancer (Avi) に移行することをお勧めします。
    • NSX Data Center Advanced、NSX Data Center Enterprise Plus、NSX Advanced、または NSX Enterprise を購入している場合は、VMware NSX Advanced Load Balancer (Avi) の Basic エディションを使用できます。このエディションには、NSX-T LB と同等の機能があります。
    • VMware NSX Advanced Load Balancer (Avi) Enterprise を購入して、エンタープライズ グレードのロード バランシング、GSLB、高度な分析、コンテナ Ingress、アプリケーション セキュリティ、WAF を利用することをお勧めします。

:NSX-T Data Center を使用する新しい展開では、ネイティブな NSX-T ロード バランサではなく、リリース v20.1.6 以降を使用する VMware NSX Advanced Load Balancer (Avi) を利用することをお勧めします。

詳細:

NSX Cloud

  • NSX Cloud での OS サポートの拡張 - NSX Cloud で、すでにサポートされている OS に加えて、次の OS がサポートされるようになりました。
    • Ubuntu 20.04
    • RHEL 8.next
  • PCG での高度なセキュリティ(レイヤー 7)機能の NSX Cloud サポート(テクニカル プレビュー、本番環境で使用不可) - NSX Cloud は、Azure と AWS の両方の PCG に一部の高度なセキュリティ(レイヤー 7)機能を提供します。これにより、パブリック クラウド内のワークロードでアプリケーション レイヤー セキュリティのメリットを活用できます。この機能セットを本番環境以外の展開で試すことができます。
  • 単一ユーザー VDI に対する IDFW の NSX Cloud サポート(テクニカル プレビュー、本番環境で使用不可) - NSX Cloud は、Identity Firewall により、VDI 展開にユーザーベースのセキュリティを提供します。接続されたユーザーにマッピングされたセキュリティプロファイルを仮想マシンに関連付けることができるため、セキュリティ管理を簡素化し、セキュリティを強化できます。この機能セットを本番環境以外の展開で試すことができます。

運用と監視

  • 物理/ベアメタル サーバで NSX をクリーンアップする del nsx コマンド - ESX サーバで引き続き NSX 削除機能がサポートされるだけでなく、CLI コマンドdel nsx を使用して、Linux OS を実行する物理/ベアメタル サーバから NSX を削除できます。物理/ベアメタル サーバの NSX VIB が古い状態で、そのホストから NSX をアンインストールできない場合は、CLI コマンド del nsx を使用します。ガイドに従ってホストから NSX を削除し、クリーンな状態に戻して NSX を再インストールできます。
  • NSX Manager ユーザー インターフェイスを使用したライブ トラフィック分析 - NSX Manager ユーザー インターフェイスでライブ トラフィック分析機能が利用できるようになりました。データセンター間のライブ トラフィック フローを簡単に分析できます。この機能により、トレースフローとパケット キャプチャを組み合わせて、統合的な方法で診断を行うことができます。ライブ パケットのトレースと送信元でのパケット キャプチャを一度に実行できます。ライブ トラフィック分析により、ネットワーク トラフィックの問題を正確に特定できます。また、特定のフローを分析してノイズを回避することができます。
  • 選択的なポート ミラーリング - ミラーリングがフローベースのフィルタ機能で強化されました。リソース要件も軽減されています。関連するフローに集中し、効果的なトラブルシューティングを行うことができます。
  • ファブリック MTU 構成のチェック - オーバーレイ ネットワークの MTU 構成を確認するため、NSX Manager ユーザー インターフェイスでオンデマンドまたは定期的な MTU チェックを実行できます。MTU の不一致が見つかると、アラートが発生します。
  • VLAN でバッキングされた論理ネットワークでのトレースフローのサポート - VLAN でバッキングされた論理ネットワークでトレースフローを実行できます。この機能は API 経由で使用します。
  • ログ機能の改善 - ログ機能が改善されました。重要なログ メッセージの消失を防ぎ、すぐに見つかるようにするため、頻繁に繰り返されるログ メッセージを検出し、抑制できるようになりました。
  • CLI ガイドの強化とコマンドの追加 - インスタンス セグメントなど、UI 構造(ポリシー)に対応する新しい CLI コマンドのセットが導入されました。これにより、CLI が使いやすくなりました。また、簡単に使用できるように CLI ガイドも刷新されました。
  • 容量制限 - 一部の容量制限について、キャパシティ ダッシュボードで NSX Manager の展開サイズが認識されるようになりました。NSX-T 3.2 にアップグレードした後、推奨容量を超過すると、アラームが生成される場合があります。追加容量が必要な場合は、中規模の NSX Manager から大規模の NSX Manager にアップグレードするか、使用率を下げてサポート範囲内で維持することをお勧めします。

監視

  • 時系列の監視 - NSX Application Platform で収集したメトリックを最大で 1 年間保存できるようになりました。時系列メトリックを使用すると、主要なパフォーマンス インジケータの傾向を監視できます。前後の分析を行い、トラブルシューティングに役立つ履歴コンテキストを取得できます。時系列メトリックは、Edge ノード、Tier-0 および Tier-1 ゲートウェイ、NSX Manager、NSX Application Platform とセキュリティ機能(TLS 検査、IDPS、ゲートウェイ ファイアウォールなど)で使用できます。これらの時系列メトリックは、NSX-T API を介して使用できます。これらのメトリックのサブセットは NSX Manager UI でも使用できます。
  • イベントとアラーム
    • 証明書 - CA バンドルの更新を推奨
    • 運用 - クラスタの停止、クラスタ使用不能、管理チャネルからマネージャ ノードへの接続が停止、管理チャネルからマネージャ ノードへの接続が長時間停止
    • フェデレーション - GM 間の遅延に関する警告、GM 間の同期に関する警告、GM 間の同期エラー、GM から LM への遅延に関する警告、GM から LM への同期に関する警告、GM から LM への同期エラー、構成のインポート中に LM をリストア、キュー占有率のしきい値を超過
    • トランスポート ノードの健全性 - トランスポート ノードのアップリンク停止
    • 分散ファイアウォール - DFW セッション数が多い、DFW vMotion の障害
    • Edge - Edge ノードと vSphere の設定変更、Edge ノードの設定の不一致、Edge 仮想マシンの vSphere 設定の不一致、Edge の vSphere の場所の不一致
    • Edge の健全性 - Edge データパス NIC スループットが高い、Edge データパス NIC スループットが非常に高い、障害ドメインの停止
    • VPN - IPsec サービスの停止
    • NAT - ゲートウェイの SNAT ポート使用率が高い
    • ロード バランシング - メモリ不足のためロード バランシング構成が認識されない
    • MTU チェック - トランスポート ゾーン内の MTU が一致しない、グローバル ルーター MTU が大きすぎる
    • NSX Application Platform の通信 - メッセージング オーバーフローで遅延を検出、メッセージング Raw フローで遅延を検出、TN フロー エクスポータの切断
    • NSX Application Platform の健全性 - プラットフォームの健全性を監視する 55 のアラーム

操作性とユーザー インターフェイス

  • ログインメッセージとバナーのカスタマイズ - NSX Manager からログイン メッセージを構成またはカスタマイズし、ログイン前にユーザーが受け入れる必須フィールドを指定できます。
  • 検索機能とフィルタ機能の強化 - NSX ユーザー インターフェイスの検索機能とフィルタ機能が強化されました。最初の画面に、使用可能な検索語句と最近検索された項目が表示されます。高度な検索が別のパネルで表示されます。ここで、検索のカスタマイズや構成を行うことができます。検索クエリにタグとアラームの情報が表示されるようになりました。
  • VPAT - 製品アクセシビリティのギャップを埋めるための修正。
  • NSX トポロジ - ゲートウェイに関連付けられた基盤となるファブリックを可視化します。この機能を使用すると、Edge クラスタとホスト スイッチの構成を可視化し、ホストおよび Edge 構成の詳細を収集できます。
  • UI でのオブジェクト セレクタの操作性の向上 - この機能により、同じカテゴリに属する複数のオブジェクトを選択できます。また、すべてのオブジェクトを選択することもできます。
  • セキュリティ概要の刷新 -セキュリティの概要 ページが刷新され、セキュリティ構成の全体像を把握できるようになりました。さまざまな機能で脅威と応答を確認したり、システムの既存の構成と容量を表示できます。
  • vCenter Server に統合された NSX-T UI - vCenter Server UI で NSX-T 用プラグインを使用して、NSX-T のインストールと構成ができるようになりました。この機能は、vCenter Server 7.0U3 以降でのみサポートされます。
  • 一般的なユースケースでの NSX-T の展開ウィザード - vCenter Server プラグインを使用して NSX-T をインストールすると、一般的なユースケースに基づいて NSX-T の機能を有効にすることができます。展開ウィザードを使用して、NSX-T の機能をすばやく有効にできます。このリリースでは、NSX のセキュリティ機能を有効にするウィザードと、NSX の仮想ネットワーク機能を有効にするウィザードの 2 つがサポートされています。

ポリシー

  • NSX Manager から NSX ポリシーへの昇格ツール - データパスの中断、既存のオブジェクトの削除/再作成を発生させずに、既存の構成を NSX Manager から NSX ポリシーに昇格できます。NSX Manager オブジェクトが NSX ポリシーに昇格されると、NSX Manager オブジェクトは Manager UI/API を介して読み取り専用に設定されます。このオブジェクトを操作するには、NSX ポリシー UI/API を使用します。

AAA とプラットフォームのセキュリティ

  • TLS 検査の証明書管理の機能強化(テクニカル プレビュー、本番環境で使用不可) - TLS 検査機能の導入により、証明書管理で認証バンドルの追加と変更がサポートされ、TLS 検査機能で使用される CA 証明書の生成が可能になりました。さらに、一般的な証明書管理 UI で、証明書のインポート/エクスポートを簡素化する変更を行うことができます。
  • LDAP 統合の高可用性とスケーリングの機能強化 - LDAP 構成で、ドメインごとに複数の LDAP サーバを構成できるようになりました。また、ドメインごとに異なる LDAP サーバに関連付けられた複数の証明書を「信頼」できるようになりました。

スケーリング

  • スケーリングの強化 - 最大規模の展開でサポートされるスケーリングが増えています。スケーリングの変更の詳細については、VMware 最大構成ツールを参照してください。

ライセンス

  • ライセンスの機能強化 - NSX-T で、ライセンス エディションに基づいて機能へのアクセスを制限できるようになりました。これにより、ユーザーのライセンス コンプライアンスを維持できます。新規ユーザーは、購入したエディションで使用可能な機能にのみアクセスできます。ライセンス エディションに含まれていない機能を使用している既存のユーザーは、オブジェクトの表示のみに制限されます。作成と編集は許可されません。
  • 新しいライセンス - 新しい VMware NSX ゲートウェイ ファイアウォールと NSX フェデレーション アドオンのサポートが追加されました。2018 年 6 月に導入された NSX Data Center ライセンス(Standard、Professional、Advanced、Enterprise Plus、Remote Office Branch Office)と以前の VMware NSX for vSphere ライセンス キーは引き続きサポートされます。NSX ライセンスの詳細については、VMware ナレッジベースの記事KB52462を参照してください。

NSX Data Center for vSphere から NSX-T Data Center への移行

  • VMware Integrated OpenStack の移行 - VIO 環境で NSX for vSphere から NSX-T への移行がサポートされるようになりました。オブジェクトの OpenStack 表現を壊すことなく、移行することができます。この機能では、ご使用の VMware Integrated OpenStack バージョンによる移行機能のサポートが必要です。
  • 独自トポロジの使用 - Migration Coordinator は、NSX for vSphere と NSX-T のユーザー定義トポロジ間での移行を行えるように、モデルを拡張しました。これにより、NSX-T トポロジをより柔軟に定義できるようになり、NSX for vSphere から NSX-T に移行できるトポロジの数も増加します。

    この機能は、リフト & シフトを可能にするための構成移行、またはインプレース移行を実行する完全なワークフローの一部としてのみ使用できます。

  • 固定トポロジでの OSPF の移行のサポート - Migration Coordinator は、BGP およびスタティックではなく、OSPF を使用する固定トポロジをサポートします。これにより、ESG とトップオブラック間で N/S 接続用に OSP が構成されている場合でも、BYOT ではなく、固定トポロジを使用できます。(ESG と DLR 間の OSPF は、すでにサポートされており、NSX-T 内部ルーティングに置き換えられています)。
  • Migration Coordinator のスケーリングの増加 - より大規模な環境に対応し、NSX for vSphere の最大規模に近づけるため、Migration Coordinator のスケーリングが増加しました。
  • ゲスト イントロスペクションの移行 - GI の NSX for vSphere から NSX-T への移行が Migration Coordinator に追加されました。この機能は、パートナー ベンダーも Migration Coordinator をサポートしている場合に使用できます。
  • IDFW/RDSH の移行 - Migration Coordinator で、ID ベースのファイアウォール構成がサポートされるようになりました。

テクニカル プレビュー機能

NSX-T Data Center 3.2 では、いくつかの機能がテクニカル プレビューとして提供されています。VMware では、本番環境でのテクニカル プレビュー機能の使用をサポートしていません。これらの機能に対して完全なテストは行われていません。一部の機能は想定どおり動作しない可能性があります。ただし、VMware では、これらのプレビューを現在の NSX-T の機能改善だけでなく、将来の機能強化の開発にも役立てています。

これらのテクニカル プレビュー機能の詳細については、『NSX-T Data Center 3.2 管理ガイド』で入手可能なドキュメントを参照してください。次のリストに、これらのテクニカル プレビュー機能の概要をまとめたリンクを示します。これらのトピックは、タイトルにテクニカル プレビューという文字が含まれています。

多様性に配慮した用語

VMware では、インクルージョンとダイバーシティを重視しています。お客様やパートナーとのやり取り、社内コミュニティにおいてこれらの原則を浸透させるため、全社的な取り組みを行い、当社の製品における不適切な表現を置き換える作業を進めています。現在、NSX-T Data Center UI、ドキュメント、API、CLI、およびログに含まれる不適切な用語の置き換えを行っています。たとえば、disabled という多様性の受け入れに適切ではない用語は deactivate という用語に変更しました。

互換性とシステム要件

互換性とシステム要件については、VMware 製品の相互運用性マトリックスNSX-T Data Center インストール ガイドを参照してください。

機能/API の廃止と動作の変更

NSX Manager API および NSX Advanced ユーザー インターフェイスの廃止のお知らせ

NSX-T には、論理ネットワークとセキュリティを構成する方法としてマネージャ モードとポリシー モードの 2 つがあります。マネージャ API には /api で始まる URI が含まれ、ポリシー API には /policy/api で始まる URI が含まれます。

VMware では、今後の NSX-T のメジャーまたはマイナー リリースで NSX-T Manager API と NSX Advanced UI のサポートを削除する予定です。このリリースは、このメッセージの日付(2021 年 12 月 16 日)から 1 年以降に一般公開する予定です。『NSX Data Center API ガイド』では、削除予定の NSX-T Manager API に「廃止」というマークが付いています。また、代替 API に関するガイダンスも記載されています。

NSX-T の新しい展開では、NSX ポリシー API と NSX ポリシー UI を利用することをお勧めします。現在 NSX Manager API と NSX Advanced UI を利用している環境の場合は、移行の際に NSX Manager のマネージャ オブジェクトからポリシー オブジェクトへの昇格ページとNSX Data Center API ガイドを参照してください。

N-VDS NSX-T ホスト スイッチ廃止のお知らせ

NSX-T 3.0.0 以降は、vSphere VDS スイッチ バージョン 7.0 以降で実行できます。これにより、vSphere とより緊密な連携が可能になります。NSX-T をユーザーの vSphere 環境に追加して、NSX-T を簡単に導入できます。

VMware では、今後の NSX-T リリースで ESXi ホスト上の NSX-T N-VDS 仮想スイッチのサポートを削除する予定です。このリリースは、このメッセージの発表日(2021 年 4 月 17 日)から 1 年以降に一般公開される予定です。KVM、NSX-T Edge ノード、ネイティブ パブリック クラウドの NSX エージェント、ベアメタル ワークロードでは、N-VDS は引き続きサポート対象の仮想スイッチになります。

NSX-T と vSphere の新しい展開では、VDS スイッチ バージョン 7.0 以降を使用して、この緊密な連携と展開を活用することを推奨します。また、ESXi ホストで N-VDS を使用する NSX-T の既存デプロイの場合、VMware は VDS で NSX-T を使用することを推奨します。VMware では、このプロセスを簡単に行う方法として CLI ベースのスイッチ移行ツールを提供しています(NSX-T 3.0.2 で最初に公開)。また、GUI ベースの Upgrade Readiness Tool を使用することもできます(NSX-T 3.1.1 で最初に公開)。これらのツールの詳細については、NSX のドキュメントを参照してください。

:NSX-T 3.2.0 では、N-VDS から VDS への移行ツールは使用できません。このリリースで N-VDS から VDS にワークロードを移行する場合は、ワークロードを手動で移行する必要があります。

N-VDS から VDS に移行する場合は、展開について次の点に注意してください。

  • N-VDS API と VDS API は異なります。仮想マシンのバッキング タイプや、N-VDS スイッチと VDS スイッチの vmKernel インターフェイスの API も異なります。環境内で VDS を使用するように移行する場合は、N-VDS API ではなく VDS API を呼び出す必要があります。このエコシステムの変更は、N-VDS を VDS に変換する前に行う必要があります。詳細については、ナレッジベースの記事KB79872を参照してください。:N-VDS API と VDS API に変更はありません。
  • VDS の設定は vCenter Server で行います。N-VDS は vCenter Server に依存しません。NSX-T で VDS がサポートされ、N-VDS は最終的に廃止されるため、NSX-T と vCenter Server の連携が強化されます。vSphere 環境の NSX を有効にするには、vCenter Server が必要になります。

OpenStack と KVM

3.x リリース シリーズは、KVM および非 VIO OpenStack ディストリビューションをサポートする最後のシリーズです。このディストリビューションには、RedHat OpenStack Platform、Canonical/Ubuntu OpenStack、SUSE OpenStack Cloud、Mirantis OpenStack、特定のベンダーに依存しないコミュニティ ベースの OpenStack などがありますが、これに限定されるものではありません。NSX で 非 VIO OpenStack を使用している場合は、代わりに環境で vRealize Automation または VMware Cloud Director を使用することをお勧めします。

NSX-T ロード バランシング API の廃止のお知らせ

NSX-T ロード バランサ API は「廃止」とマークされます。これは、次で始まる URI を含むすべての API に適用されます。 /policy/api/v1/infra/lb-

VMware では、今後の NSX-T リリースで NSX-T ロード バランサのサポートを削除する予定です。このリリースは、このメッセージの発表日(2021 年 12 月 16 日)から 1 年以降に一般公開する予定です。『NSX Data Center API ガイド』では、削除予定の NSX-T Manager API に「廃止」というマークが付いています。

NSX-T Data Center を使用する新しい展開では、リリース v20.1.6 以降を使用する VMware NSX Advanced Load Balancer (Avi) を利用することをお勧めします。

:API の廃止は、分散ロード バランサには適用されません。

アラーム

  • NSX Intelligence 通信アラームが NSX Application Platform 通信アラームに代わりました。
  • NSX Intelligence 健全性アラームが NSX Application Platform 健全性アラームに代わりました。
  • DNS - フォワーダ無効アラーム。
  • インフラストラクチャ サービス - Edge サービス停止状態アラームは、Edge サービス状態変更アラームの一部として扱われます。
  • トランスポート ノードの健全性 - N-VDS アップリンクの停止アラームは、トランスポート ノードのアップリンク停止アラームに代わりました。

ライブ トラフィック分析 API の廃止と変更

  • ライブ トラフィック分析 MP API は、NSX-T 3.2.0 で「廃止」とマークされています。
  • NSX-T 3.2.0 では、ライブ トラフィック分析から [パケット数] オプションが削除されました。トレースとパケット キャプチャは引き続きライブ トラフィック分析でサポートされます。
  • 次のフィールドとタイプが削除されました。
    • ポリシー API:フィールド - count_config、タイプ - PolicyCountObservation
    • MP API:フィールド - count_configcount_results、タイプ - CountActionConfigLiveTraceActionType(COUNT: サポートされていないアクション)、CountActionArgumentCountResultCountObservationBaseCountObservation

API の廃止と動作の変更

  • NSX で廃止された API の削除 - NSX-T 3.2.0 では、1 年以上前に次の API が廃止され削除されました。
    削除された API 代替
    GET api/v1/hpm/alarms 次のものに代わりました。 /api/v1/alarms
    POST /fabric/nodes POST /api/v1/transport-nodes
    POST /fabric/nodes/<node-id>?action=restart_inventory_sync POST /api/v1/transport-nodes/<node-id>?action=restart_inventory_sync
    POST /api/v1/fabric/discovered-nodes/<node-ext-id>?action=hostprep POST /api/v1/fabric/discovered-nodes/<node-ext-id>?action=create_transport_node
    GET /fabric/nodes GET /api/v1/transport-nodes
    GET /fabric/nodes/<node-id> GET /api/v1/transport-nodes/<node-id>
    POST /fabric/nodes/<node-id> POST /api/v1/transport-nodes/<node-id>
    PUT /fabric/nodes/<node-id> PUT /api/v1/transport-nodes/<node-id>
    DELETE /fabric/nodes/<node-id> DELETE /api/v1/transport-nodes/<node-id>
    GET /fabric/nodes/<node-id>/status GET /api/v1/transport-nodes/<node-id>/status
    GET /fabric/nodes/status GET /api/v1/transport-nodes/<node-id>/status
    GET /fabric/nodes/<node-id>/capabilities GET /api/v1/transport-nodes/<node-id>/capabilities
    POST /fabric/nodes/<node-id>?action=<enter/exit>_maintenance_mode NSX-T API の代替はありません。
    GET /fabric/nodes/<node-id>/state GET /api/v1/transport-nodes/<node-id>/state
    GET /fabric/nodes/<node-id>/modules GET /api/v1/transport-nodes/<node-id>/modules
    POST /fabric/nodes/<node-id>?action=upgrade_infra NSX-T API の代替はありません。
    GET /fabric/nodes/<node-id>/network/interfaces GET /api/v1/transport-nodes/<node-id>/interfaces
    GET /fabric/nodes/<node-id>/network/interfaces/<interface-id> GET /api/v1/transport-nodes/<node-id>/interfaces/<interface-id>
    GET /fabric/compute-collection-fabric-templates トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    POST /fabric/compute-collection-fabric-templates トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    DELETE /fabric/compute-collection-fabric-templates/<fabric-template-id> トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    PUT /fabric/compute-collection-fabric-templates/<fabric-template-id> トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    GET /fabric/compute-collection-fabric-templates/<fabric-template-id> トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    GET /fabric/compute-collection-transport-node-templates トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    POST /fabric/compute-collection-transport-node-templates トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    DELETE /fabric/compute-collection-transport-node-templates/<transport-node-template-id> トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    PUT /fabric/compute-collection-transport-node-templates/<transport-node-template-id> トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    GET /fabric/compute-collection-transport-node-templates/<transport-node-template-id> トランスポート ノード プロファイル (TNP) API とトランスポート ノード コレクション (TNC) API を使用したワークフローの処理方法が異なります。
    GET /api/v1/ipfix-obs-points/switch-global スイッチ IPFIX プロファイルに /api/v1/ipfix-profiles/<ipfix-profile-id> を使用し、IPFIX コレクタ プロファイルに /api/v1/ipfix-collector-profiles/<ipfix-collector-profile-id> を使用します。
    PUT /api/v1/ipfix-obs-points/switch-global スイッチ IPFIX プロファイルに /api/v1/ipfix-profiles/<ipfix-profile-id> を使用し、IPFIX コレクタ プロファイルに /api/v1/ipfix-collector-profiles/<ipfix-collector-profile-id> を使用します。
    GET /api/v1/ipfix-obs-points スイッチ IPFIX プロファイルに /api/v1/ipfix-profiles を使用し、IPFIX コレクタ プロファイルに /api/v1/ipfix-collector-profiles を使用します。
    GET /infra/ipfix-collector-profiles GET /policy/api/v1/infra/ipfix-l2-collector-profiles
    GET /infra/ipfix-collector-profiles/<ipfix-collector-profile-id> GET /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>
    PUT /infra/ipfix-collector-profiles/<ipfix-collector-profile-id> PUT /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>
    PATCH /infra/ipfix-collector-profiles/<ipfix-collector-profile-id> PATCH /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>
    DELETE /infra/ipfix-collector-profiles/<ipfix-collector-profile-id> DELETE /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>
    GET /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances GET /policy/api/v1/infra/ipfix-l2-profiles
    GET /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id> GET /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>
    PUT /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id> PUT /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>
    PATCH /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id> PATCH /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>
    DELETE /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id> DELETE /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>
    GET /api/v1/node/services/mgmt-plane-bus NSX-T での内部アーキテクチャの変更に伴う API の削除
    POST /api/v1/node/services/mgmt-plane-bus?action=restart|start|stop NSX-T での内部アーキテクチャの変更に伴う API の削除
    GET /api/v1/node/services/mgmt-plane-bus/status NSX-T での内部アーキテクチャの変更に伴う API の削除
    DELETE /api/v1/node/rabbitmq-management-port NSX-T での内部アーキテクチャの変更に伴う API の削除
    GET /api/v1/node/rabbitmq-management-port NSX-T での内部アーキテクチャの変更に伴う API の削除
    POST /api/v1/node/rabbitmq-management-port NSX-T での内部アーキテクチャの変更に伴う API の削除
    GET /api/v1/node/services/intelligence-upgrade-coordinator NSX Intelligence が NSX Application Platform でホストされるようになったため、NSX-T Manager から API が削除されました
    POST /api/v1/node/services/intelligence-upgrade-coordinator?action=start|stop|restart NSX Intelligence が NSX Application Platform でホストされるようになったため、NSX-T Manager から API が削除されました
    GET /api/v1/node/services/intelligence-upgrade-coordinator/status NSX Intelligence が NSX Application Platform でホストされるようになったため、NSX-T Manager から API が削除されました
    GET /api/v1/bridge-clusters これらの API は、ESXi でブリッジを構成する際に使用されていましたが、この機能は廃止され、削除されています。ブリッジは Edge クラスタでサポートされています。Edge ブリッジ プロファイルを使用してセグメントに構成できます。(Edge ブリッジのドキュメントを参照)
    POST /api/v1/bridge-clusters これらの API は、ESXi でブリッジを構成する際に使用されていましたが、この機能は廃止され、削除されています。ブリッジは Edge クラスタでサポートされています。Edge ブリッジ プロファイルを使用してセグメントに構成できます。(Edge ブリッジのドキュメントを参照)
  • NSX で廃止された API フィールドの削除 - NSX-T 3.2.0 では、1 年以上前に次の API フィールドが廃止され削除されました。(API 自体は削除されていません。ここに記載されているフィールドのみが削除されています。)
    • トランスポート ゾーン API フィールドの削除
      POST /api/v1/transport-zones
      {
           "display_name":"tz1",
           "host_switch_name":"test-host-switch-1", <<==== WILL BE REMOVED
           "host_switch_mode":  "STANDARD", <<==== WILL BE REMOVED
           "description":"Transport Zone 1",
           "transport_type":"OVERLAY"
      } 

    • Edge ノード仮想マシンのトランスポート ノード API フィールドの削除
      POST /api/v1/transport-nodes
      POST /api/v1/transport-node-profiles
      {
      "node_id": "92f893b0-1157-4926-9ce3-a1787100426c",
      "host_switch_spec": {
      "host_switches": [
      {
      ...
      ...
      "transport_zone_endpoints": [ <<<==== SHOULD BE USED INSTEAD
      {
      "transport_zone_id": "1b3a2f36-bfd1-443e-a0f6-4de01abc963e"
      }
      ],
      }
      ],
      "resource_type": "StandardHostSwitchSpec"
      },
      "transport_zone_endpoints": [], <<<<=== WILL BE REMOVED
      "node_deployment_info": {
      "deployment_type": "VIRTUAL_MACHINE",
      "deployment_config": {
      "vm_deployment_config": {
      "vc_id": "23eaf46e-d826-4ead-9aad-ed067574efb7",
      "compute_id": "domain-c7",
      "storage_id": "datastore-22",
      "management_network_id": "network-24",
      "hostname": "edge", <-- will be removed
      "data_network_ids": [
      "network-24"
      ],
      "search_domains": [ "vmware.com" ] <<<<=== WILL BE REMOVED (replacement in out block)
      "dns_servers": [ "10.172.40.1" ], <<<<=== WILL BE REMOVED
      "enable_ssh": true, <<<<=== WILL BE REMOVED
      "allow_ssh_root_login": true, <<<<=== WILL BE REMOVED
      "placement_type": "VsphereDeploymentConfig"
      },
      ...
      "node_settings": {
      "hostname": "edge", <<<<=== This should be used - REPLACEMENT
      "search_domains": ["eng.vmware.com" ], <<<<=== This should be used - REPLACEMENT
      "dns_servers": [ "10.195.12.31"], <<<<=== This should be used - REPLACEMENT
      "enable_ssh": true, <<<<=== This should be used - REPLACEMENT
      "allow_ssh_root_login": true <<<<=== This should be used - REPLACEMENT
      },
      "resource_type": "EdgeNode",
      "id": "90ec1776-f3e2-4bd0-ba1f-a1292cc58707",
      ...
      "display_name": "edge", <<<<=== WILL BE REMOVED (replacement in out block)
      "_create_user": "admin", <<<<=== WILL BE REMOVED
      "_create_time": 1594956232211, <<<<=== WILL BE REMOVED
      "_last_modified_user": "admin", <<<<=== WILL BE REMOVED
      "_last_modified_time": 1594956531314, <<<<=== WILL BE REMOVED
      "_system_owned": false, <<<<=== WILL BE REMOVED
      "_protection": "NOT_PROTECTED", <<<<=== WILL BE REMOVED
      "_revision": 2 <<<<=== WILL BE REMOVED
      },
      "failure_domain_id": "4fc1e3b0-1cd4-4339-86c8-f76baddbaafb",
      "resource_type": "TransportNode",
      "id": "90ec1776-f3e2-4bd0-ba1f-a1292cc58707",
      "display_name": "edge", <<<<=== This should be used - REPLACEMENT
      "_create_user": "admin", <<<<=== This should be used - REPLACEMENT
      "_create_time": 1594956232373, <<<<=== This should be used - REPLACEMENT
      "_last_modified_user": "admin", <<<<=== This should be used - REPLACEMENT
      "_last_modified_time": 1594956531551, <<<<=== This should be used - REPLACEMENT
      "_system_owned": false, <<<<=== This should be used - REPLACEMENT
      "_protection": "NOT_PROTECTED", <<<<=== This should be used - REPLACEMENT
      "_revision": 1 <<<<=== This should be used - REPLACEMENT
      }

本リリースのアップグレードに関する注意点

NSX-T Data Center コンポーネントのアップグレードについては、NSX-T Data Center アップグレード ガイドを参照してください。

NSX-T 3.2.0.1 にアップグレードする場合は、アップグレード プロセスを開始する前に、NSX アップグレード評価ツールを実行することを強くお勧めします。このツールは、アップグレード前に NSX Manager の健全性と準備状況を確認することで、アップグレードを確実に成功させるために設計されています。

API および CLI リソース

NSX-T Data Center の API または CLI を自動化に使用する場合には、developer.vmware.comを参照してください。

API ドキュメントは、API リファレンス タブから利用できます。CLI ドキュメントは、ドキュメント タブから利用できます。

使用可能な言語

NSX-T Data Center は英語、ドイツ語、フランス語、日本語、簡体字中国語、韓国語、繁体字中国語、スペイン語でご利用いただけます。NSX-T Data Center のローカライズではブラウザの言語設定が使用されるため、設定が目的の言語と一致することを確認してください。

ドキュメントの改訂履歴

改訂日 変更点
2021 年 12 月 16 日 1 初版。
2022 年 1 月 3 日 2 新機能」の「フェデレーション」セクションに注を追加しました。

既知の問題 2882574 を追加しました。

2022 年 1 月 5 日 3 本リリースのアップグレードに関する注意点」と「既知の問題」セクションに、既知の問題を追加しました。
2022 年 1 月 21 日 4 NSX-T Data Center 3.2.0 に関する重要な情報」セクションを追加しました。

本リリースのアップグレードに関する注意点」セクションに、NSX アップグレード評価ツールに関する情報を追加しました。

既知の問題 2890348 を追加しました。

2022 年 2 月 4 日 5 SMB プロトコルに対する Identity Firewall のサポート。
2022 年 2 月 15 日 6 新機能」で容量制限に関する箇条書きを追加しました。
2022 年 2 月 22 日 7 NSX Application Platform の展開要件を追加しました。
2022 年 4 月 29 日 8 既知の問題 2885820、2871440、および 2945515 を追加しました。

既知の問題 2685550、2566121、2848614 の重複エントリを削除しました。

2022 年 5 月 5 日 9 既知の問題に 2875563、2875667、2883505、2914934、2921704、2933905 を追加しました。

解決した問題

  • 解決した問題 2685550:ブリッジされたセグメントに適用すると、ファイアウォール ルールの認識状態が常に「処理中」になる

    ブリッジされたセグメントを含む NSGroup のメンバーにファイアウォール ルールを適用すると、認識状態が常に「処理中」になります。ブリッジされたセグメントに適用したファイアウォール ルールの認識状態を確認できません。

  • 解決した問題 2805986:NSX-T 管理対象 Edge 仮想マシンを展開できない

    ESX UI で NSX-T Edge の展開に失敗します。

  • 解決した問題 2643749:システムによって作成されたサイト固有リージョンのグループに、そのサイトに作成されたカスタム リージョンのグループをネストできない

    システムによって作成されたリージョンのグループ メンバーとして子グループを選択していると、同じ場所に作成されたサイト固有のカスタム リージョンのグループは表示されません。

  • 解決した問題 2638673:インベントリに仮想マシンの SRIOV vNIC がない

    SRIOV vNIC が [Add new SPAN] セッション ダイアログに表示されません。新しい SPAN セッションを追加するときに、SRIOV vNIC が表示されません。

  • 解決した問題 2622576:構成の重複による障害がユーザーに正しく伝播されない

    オンボーディングの進行中に「オンボーディングに失敗しました」というメッセージが表示されます。

  • 解決した問題 2587257:NSX-T Edge によって送信された PMTU パケットが、宛先での受信時に無視されることがある

    PMTU の検出に失敗すると、断片化と再構築、パケットのドロップが発生します。これにより、トラフィックのパフォーマンスが低下するか、トラフィックが停止します。

  • 解決した問題 2482580:vCenter Server から IDFW/IDS クラスタが削除されると、IDFW/IDS の構成が更新されない

    IDFW/IDS が有効になっているクラスタが vCenter Server から削除されると、NSX 管理プレーンに必要な更新が通知されません。このため、IDFW/IDS が有効になっているクラスタの正確な数が報告されません。これによる機能上の影響はありません。有効なクラスタの数のみが正しくありません。

  • 解決した問題 2610851:ネームスペース、コンピュート コレクション、L2VPN サービス グリッドのフィルタリングは、リソース タイプ フィルタのいくつかの組み合わせに対してデータを返さない場合がある

    いくつかのタイプに同時に複数のフィルタを適用した場合、基準に一致するデータが利用可能であっても結果が返されません。これは一般的なシナリオではなく、フィルタは次の属性の組み合わせグリッドでのみ失敗します。[ネームスペース] グリッドの場合、クラスタ名とポッド名のフィルタ。[ネットワーク トポロジ] ページの場合、リモート IP フィルタを適用した L2VPN サービス。[コンピュート コレクション] の場合、ComputeManager フィルタ。

  • 解決した問題 2730109:ループ バックが存在していても、Edge のパワーオン中に、Edge がルーターリンク IP アドレスを OSPF ルーター ID として使用して、ピアとの OSPF ネイバーシップを確立しようとする

    Edge を再ロードした後、OSPF ルーター ID 設定を受信するまで、OSPF はダウンリンク IP アドレス(上位の IP アドレス)をルーター ID として選択します。これは設定の優先順位が原因です。新しいルーター ID の OSPF HELLO を受信すると、古いルーター ID を持つネイバー エントリは最終的に古いエントリになります。ピアで Dead タイマーが期限切れになると、これらのエントリが期限切れになります。

  • 解決した問題 2631703:vIDM 統合でアプライアンスのバックアップ/リストアを実行すると、vIDM の構成が壊れる

    通常、環境がアップグレードまたはリストアされた後に、vIDM 統合が稼動しているアプライアンスをリストアしようとすると、統合が切断され、再設定が必要になります。

  • 解決した問題 2655539:CLI でホスト名を更新しているときに、グローバル マネージャ UI の [ロケーションマネージャ] ページでホスト名が更新されない

    古いホスト名が表示されます。

  • 解決した問題 2682480:NCP の健全性状態に対して誤ったアラームが発生することがある

    NCP システムが良好な状態でも NCP 健全性状態アラームが発生する場合があります。このため、NCP 健全性状態アラームが信頼できないことがあります。

  • 解決した問題 2550492:アップグレード中に「認証情報が正しくないか、指定されたアカウントがロックされています」というメッセージが一時的に表示され、システムが自動的に復旧する

    アップグレード中に一時的なエラー メッセージが表示されます。

  • 解決した問題 2521230:get bgp neighbor summary で表示された BFD の状態に、最新の BFD セッションの状態が正しく反映されないことがある

    BGP と BFD のセッションは個別に設定できます。get bgp neighbor summary を実行すると、BGP で BFD の状態も表示されます。BGP が停止している場合、BFD 通知は処理されず、最後に確認された状態が引き続き表示されます。このため、BFD の古い状態が表示される場合があります。

  • 解決した問題 2625009:中間ルーターまたは物理 NIC の MTU が SR 間ポートと同等か、それより低い場合、SR 間の iBGP セッションでフラッピングが継続的に発生する

    これは、フェデレーション トポロジのサイト間接続に影響を与える可能性があります。

  • 解決した問題 2662225:S-N トラフィック ストリームのフロー中にアクティブ Edge ノードが非アクティブ Edge ノードになると、トラフィック ロスが発生する

    現在の S->N ストリームは、マルチキャストのアクティブ ノードで実行されています。送信元への TOR の優先ルートは、マルチキャストのアクティブ Edge ノードのみを経由する必要があります。別の Edge を起動すると、マルチキャストのアクティブ ノードが引き継がれる場合があります(ランクの低い Edge がアクティブなマルチキャスト ノードです)。現在の S->N トラフィックでは、最大 4 分間の損失が発生します。これは、新しいストリームに影響を与えたり、現在のストリームを停止して再開する場合に影響を与えたりすることはありません。

  • 解決した問題 2587513:ブリッジ プロファイルの割り当てで複数の VLAN 範囲が構成されている場合、ポリシーがエラーを示す

    「無効な VLAN ID」エラー メッセージが表示されます。

  • 解決した問題 2606452:API でオンボーディングを試みるとブロックされる

    「Default transport zone not found at site」というエラー メッセージが表示され、API のオンボーディングに失敗します。

  • 解決した問題 2649240:個別の delete API で多くのエンティティを削除すると、削除に時間がかかる

    削除プロセスが完了するまでに、かなり時間がかかります。

  • 解決した問題 2649499:個々のルールを 1 つずつ作成すると、ファイアウォール ルールの作成に時間がかかる

    遅い API を使用すると、ルールの作成にさらに時間がかかります。

  • 解決した問題 2652418:多くのエンティティを削除すると、削除に時間がかかる

    削除が低速になります。

  • 解決した問題 2658687:トランザクションが失敗したときに、グローバル マネージャの切り替え API からエラーが報告されても、フェイルオーバーが行われる

    API は失敗しますが、グローバル マネージャの切り替えは完了します。

  • 解決した問題 2679614:ローカル マネージャで API 証明書が置き換えられると、グローバル マネージャの UI に「一般的なエラーが発生しました」というメッセージが表示される

    ローカル マネージャで API 証明書が置き換えられると、グローバル マネージャの UI に「一般的なエラーが発生しました」というメッセージが表示されます。

  • 解決した問題 2557287:バックアップ後に実行した TNP の更新がリストアされない

    リストアされたアプライアンスで、バックアップ後に行った TNP の更新が表示されません。

  • 解決した問題 2858893:クラスタベースの展開でサービス展開のクリーンアップが失敗する

    これによる機能上の影響はありません。未解決の ServiceDeployment またはインスタンスで ServiceDefinion を登録解除しようとすると、サービスのクリーンアップに失敗します。DB から手動または強制的にクリーンアップする必要があります。

  • 解決した問題 2692344:Avi 適用ポイントを削除すると、認識済みのオブジェクトがポリシーからすべて削除され、すべてのデフォルト オブジェクトの認識済みエンティティがポリシーから削除される。新しい適用ポイントを追加すると、Avi コントローラからのデフォルト オブジェクトの再同期が失敗する

    AVIConnectionInfo の適用ポイントを削除して再作成すると、システムのデフォルト オブジェクトを使用できなくなります。

既知の問題

  • 問題 2355113:Azure 高速ネットワーク インスタンスで、RedHat および CentOS を実行しているワークロード仮想マシンがサポートされない

    Azure で、RedHat または CentOS ベースの OS を使用し、ネットワークの高速化が有効になっているときに、NSX Agent をインストールすると、イーサネット インターフェイスが IP アドレスを取得しません。

    回避策:RedHat および CentOS ベースの OS で高速ネットワークを無効にします。

  • 問題 2283559:Edge で RIB に 65,000 以上のルート、FIB に 100,000 以上のルートがある場合、/routing-table および /forwarding-table 管理プレーン API がエラーを返す

    Edge で RIB に 65,000 以上のルート、FIB に 100,000 以上のルートがある場合、管理プレーンから Edge への要求に 10 秒以上かかり、この結果タイムアウトになります。これは読み取り専用 API であり、API/ユーザー インターフェイスを使用して、RIB の 65,000 以上のルートおよび FIB の 100,000 以上のルートをダウンロードする必要がある場合にのみ影響を受けます。

    回避策:RIB/FIB を取得するには、2 つのオプションがあります。これらの API では、ネットワーク プレフィックスまたはルートのタイプに基づくフィルタリング オプションをサポートしています。これらのオプションを使用して、目的とするルートをダウンロードします。RIB/FIB テーブル全体が必要な場合は CLI でサポートします。これによるタイムアウトはありません。

  • 問題 2693576:KVM RHEL 7.9 を RHEL 8.2 にアップグレードした後、トランスポート ノードに「NSX インストール失敗」と表示される

    RHEL 7.9 から 8.2 へのアップグレード後、依存関係 nsx-opsagent と nsx-cli が見つからず、ホストがインストール失敗としてマークされます。ユーザー インターフェイスからは障害を解決できません。「ホストにソフトウェアをインストールできませんでした。未解決の依存関係:[PyYAML, python-mako, python-netaddr, python3]」というメッセージが表示されます。

    回避策:ホスト OS のアップグレード後に NSX RHEL 8.2 vib を手動でインストールし、ユーザー インターフェイスから問題を解決します。

  • 問題 2628503:manager nsgroup を強制的に削除しても、DFW ルールが適用されたままになる

    回避策:DFW ルールで使用中の nsgroup を強制的に削除しないでください。代わりに、nsgroup を空にするか、DFW ルールを削除します。

  • 問題 2684574:Edge でデータベースとルートに 6,000 個以上のルートが存在すると、ポリシー API がタイムアウトする

    Edge に 6,000 個以上のルートが存在すると、OSPF データベースと OSPF ルートに対する次のポリシー API からエラーが返されます。/tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/routes /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/routes?format=csv /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/database /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/database?format=csv Edge でデータベースとルートに 6,000 個以上のルートが存在すると、ポリシー API がタイムアウトします。これは読み取り専用の API で、API/ユーザー インターフェイスを使用して OSPF ルートとデータベースの 6,000 個以上のルートをダウンロードする場合にのみ、この問題の影響を受けます。

    回避策:CLI コマンドを使用して、Edge から情報を取得します。

  • 問題 2663483:単一ノードの NSX Manager の APH-AR 証明書を置き換えると、その NSX Manager が NSX フェデレーション環境の残りの部分から切断される

    この問題は、NSX フェデレーションと単一ノードの NSX Manager クラスタでのみ発生します。単一ノードの NSX Manager の APH-AR 証明書を置き換えると、その NSX Manager が NSX フェデレーション環境の残りの部分から切断されます。

    回避策:単一ノードの NSX Manager クラスタの展開は、サポートされている展開オプションではありません。3 ノードの NSX Manager クラスタを使用してください。

  • 問題 2636771:リソースが複数のタグ ペアでタグ付けされ、そのタグと範囲が、タグと範囲にある値と一致する場合、検索はリソースを返すことがある

    これは、タグと範囲の条件を含む検索クエリに影響します。タグと範囲が任意のペアと一致する場合、フィルタは余分なデータを返すことがあります。

    回避策:なし。

  • 問題 2668717:vRA で作成され、Tier-1 を共有するセグメントに接続しているネットワーク間の E-W ルーティングで、トラフィックの損失が断続的に観測される場合がある

    vRA が複数のセグメントを作成し、共有 ESG に接続している場合、V2T はこのようなトポロジを共有 Tier-1 に変換し、NSX-T 側のすべてのセグメントに接続します。ホストの移行期間中に、Tier-1 を共有するセグメントに接続しているワークロード間で E-W トラフィックが断続的に失われる可能性があります。

    回避策:なし。

  • 問題 2490064:外部 LB がオンになっている VMware Identity Manager を無効にできない

    外部 LB を使用して NSX で VMware Identity Manager 統合を有効にした後、外部 LB をオフにして統合を無効にしようとすると、最初の設定が再表示され、ローカルの変更が上書きされます。

    回避策:vIDM を無効にする場合は、外部 LB のフラグをオフにせず、vIDM 統合のみをオフにします。これにより、データベースに設定が保存され、他のノードと同期されます。

  • 問題 2526769:マルチノード クラスタでリストアが失敗する

    マルチノード クラスタでリストアを開始すると、リストアが失敗し、アプライアンスの再展開が必要になります。

    回避策:新しい設定(1 ノード クラスタ)を展開し、リストアを開始します。

  • 問題 2534933:LDAP ベースの CDP(CRL 配布ポイント)を含む証明書が Tomcat/クラスタ証明書として適用できない

    LDAP CDP を含む CA 署名付き証明書をクラスタ/Tomcat 証明書として使用できません。

    回避策:2 つのオプションがあります。

    1. HTTP ベースの CDP を含む証明書を使用します。
    2. PUT https://<manager>/api/v1/global-configs/SecurityGlobalConfig API を使用して、CRL チェックを無効にします(PUT のペイロードで「crl_checking_enabled」が false になっていることを確認します)。
  • 問題 2566121:サーバが過負荷状態のときに、「一部のアプライアンス コンポーネントが正常に機能していません」という誤ったエラー メッセージが表示される

    NSX に対する API 呼び出しが多すぎると、UI/API に「サーバがオーバーロードです」ではなく、「一部のアプライアンス コンポーネントが正常に機能していません」というエラーが表示されます。

    回避策:なし。

  • 問題 2613113:オンボーディングの進行中にローカル マネージャのリストアが完了しても、グローバル マネージャで、ローカル マネージャの状態が IN_PROGRESS のままになっている

    グローバル マネージャの UI で、ローカル マネージャの状態が IN_PROGRESS と表示されます。リストアされたサイトの構成をインポートできません。

    回避策:グローバル マネージャ クラスタを一度に 1 ノードずつ再起動します。

  • 問題 2690457:MP クラスタで publish_fqdns が設定され、外部 DNS サーバが適切に構成されていないときに、MP を MP クラスタに参加させると、参加するノードで proton サービスが適切に再起動されないことがある

    参加するマネージャが機能せず、ユーザー インターフェイスが使用できません。

    回避策:すべてのマネージャ ノードの正引き DNS 参照エントリと逆引き DNS 参照エントリを使用して、外部 DNS サーバを設定します。

  • 問題 2574281: ポリシーで 500 個までの VPN セッションしか許可されない

    NSX では Large フォーム ファクタに対して Edge ごとに 512 個の VPN セッションをサポートしていますが、セキュリティ ポリシーの自動組み込みが原因で、500 個までの VPN セッションしか許可されません。Tier-0 で 501 個目の VPN セッションを設定すると、次のエラー メッセージが表示されます。{'httpStatus': 'BAD_REQUEST', 'error_code': 500230, 'module_name': 'Policy', 'error_message': 'GatewayPolicy path=[/infra/domains/default/gateway-policies/VPN_SYSTEM_GATEWAY_POLICY] has more than 1,000 allowed rules per Gateway path=[/infra/tier-0s/inc_1_tier_0_1].'}

    回避策:管理プレーンの API を使用して、追加の VPN セッションを作成します。

  • 問題 2658092:NSX Intelligence がローカル マネージャで構成されている場合、オンボーディングが失敗する

    オンボーディングがプリンシパル ID エラーで失敗し、プリンシパル ID ユーザーを使用してシステムをオンボーディングすることはできません。

    回避策:NSX Intelligence で使用されるのと同じプリンシパル ID 名を使用して一時的なプリンシパル ID ユーザーを作成します。

  • 問題 2639424:ホストベース展開の vLCM クラスタでホストの修正を行うと、95% まで進行して失敗する

    ホストの修正が 95% まで進行してスタックし、70 分のタイムアウト時間の後に失敗します。

    回避策:VMware のナレッジベースの記事 KB81447 を参照してください。

  • 問題 2636420:クラスタのバックアップ後に「NSX の削除」が実行されているときに、リストアを行うと、ホストが「NSX インストールをスキップ」状態になり、クラスタが「失敗」状態になる

    ホストに「NSX インストールをスキップ」状態が表示されます。

    回避策:バックアップ後の状態(未設定の状態)に戻すには、リストア後にクラスタで「NSX の削除」を再度実行する必要があります。

  • 問題 2558576:グローバル プロファイル定義でグローバル マネージャとローカル マネージャのバージョンが異なり、ローカル マネージャで予期しない動作が発生することがある

    グローバル マネージャで作成されたグローバル DNS、セッション、またはフラッド プロファイルを UI からローカル グループに適用することはできませんが、API では適用できます。このため、API ユーザーが誤ってプロファイル割り当てマップを作成し、ローカル マネージャでグローバル エンティティを変更する可能性があります。

    回避策:ユーザー インターフェイスを使用してシステムを構成します。

  • 問題 2491800:AR チャネル SSL 証明書の有効性が定期的に確認されないため、既存の接続に対して有効期限の切れた証明書または失効した証明書が使用される可能性がある

    この接続では期限切れの SSL または失効した SSL が使用されます。

    回避策:マネージャ ノードの APH を再起動して、再接続をトリガーします。

  • 問題 2561988:すべての IKE/IPSEC セッションが一時的に中断する

    しばらくの間、トラフィックが停止しているように見えます。

    回避策:ローカル エンドポイントを同時に変更するのではなく、段階的に変更します。

  • 問題 2584648:T0 / T1 ゲートウェイのプライマリの切り替えが North バウンド接続に影響する

    場所のフェイルオーバー時間で中断が数秒間発生し、場所のフェイルオーバーまたはフェイルバックのテストに影響することがある

    回避策:なし。

  • 問題 2636420:バックアップ後に remove nsx が呼び出されるクラスタにトランスポート ノード プロファイルが適用される

    ホストが準備済み状態ではありませんが、トランスポート ノード プロファイルがクラスタで適用されたままになります。

    回避策:バックアップ後の状態(未構成の状態)に戻すには、リストア後にクラスタで「NSX の削除」を再度実行します。

  • 問題 2687084:アップグレードまたは再起動後、検索 API がエラー コード 60508「インデックスを再作成しています。処理が完了するまでに時間がかかることがあります」を含む 400 エラーを返すことがある

    システムの規模によっては、インデックスの再作成が完了するまで検索 API と UI が使用できなくなります。

    回避策:なし。

  • 問題 2782010:ポリシー API で、allow_changing_vdr_mac_in_use が false でも、vdr_mac/vdr_mac_nested の変更が許可される

    allow_changing が false に設定されている場合でも、TN で VDR の MAC アドレスが更新されます。エラーはスローされません。

    回避策:フィールドを変更する予定がない場合は、VDR MAC を古い値に戻します。

  • 問題 2791490:フェデレーション:スタンバイ グローバル マネージャ (GM) を変更した後、オブジェクトをスタンバイ GM に同期できない

    アクティブ GM からの更新で、スタンバイ GM のロケーション マネージャでアクティブ GM を確認できません。

    回避策:スタンバイ GM の ユーザー インターフェイスで強制同期を要求します。

  • 問題 2799371:L2 VPN と IPsec セッションが実行中でも、L2 VPN の IPsec アラームがクリアされない

    不要な未解決アラームが表示される点を除き、これによる機能上の影響はありません。

    回避策:アラームを手動で解決します。

  • 問題 2838613:ESX 7.0.3 より前のバージョンの場合、クラスタにセキュリティをインストールした後にバージョン 6.5 から上位バージョンにアップグレードされた VDS で、NSX セキュリティ機能が有効にならない

    バージョン 6.5 から新しいバージョン(6.6 以降)にアップグレードされた VDS に接続している仮想マシンで、vSphere DVPortgroups の NSX セキュリティ機能がサポートされていても、NSX セキュリティ機能が有効になりません。

    回避策:仮想マシンでセキュリティを有効にするには、VDS をアップグレードした後にホストを再起動して、仮想マシンをパワーオンします。

  • 問題 2839782:CRL エンティティが大きいため、NSX-T 2.4.1 から 2.5.1 にアップグレードできない。また、Corfu が 2.4.1 でサイズ制限を課すため、アップグレード中に Corfu で CRL エンティティが作成されない

    アップグレードできません。

    回避策:証明書を別の CA によって署名された証明書に置き換えます。

  • 問題 2851991:Active Directory グループを含むポリシー グループに空の送信元グループがネストされていると、IDFW が失敗する

    Active Directory グループを含むポリシー グループに空の送信元グループがネストされていると、IDFW が失敗します。

    回避策:空の子グループを削除します。

  • 問題 2852419:複数の範囲値を持つリンクローカル以外の IPv4/v6 ネクストホップでスタティック ルートが構成されていると、エラー メッセージが表示される

    複数の範囲値を持つリンク ローカル以外のネクスト ホップ IP アドレスを使用するスタティック ルート API は拒否されます。

    回避策:複数の範囲値ではなく、複数のネクスト ホップを作成し、各ネクスト ホップに異なる IP アドレスを設定します。

  • 問題 2853889:EVPN テナント構成を作成すると(vlan-vni マッピングを使用)、子セグメントが作成されるが、その認識状態が「失敗」状態になり、約 5 分後に自動的にリカバリされる

    EVPN テナント構成が認識されるまでに 5 分ほどかかります。

    回避策:なし。5 分間待機します。

  • 問題 2854139:Edge の Tier-0 SR に複数の BGP ネイバーがあり、これらの BGP ネイバーが Tier-0 SR に ECMP プレフィックスを送信しているトポロジで、RIB への BGP ルートの追加/削除が継続的に行われる

    継続的に追加または削除されるプレフィックスのトラフィックがドロップされます。

    回避策:スタティック ルートのネクストホップと同じサブネットにある BGP プレフィックスをフィルタする受信ルートマップを追加します。

  • 問題 2864250:トランスポート ノードの作成時にカスタム NIOC プロファイルを使用すると、トランスポート ノードの認識でエラーが発生する

    トランスポート ノードを使用する準備ができていません。

    回避策:デフォルトの NIOC プロファイルを使用してトランスポート ノードを作成し、カスタム NIOC プロファイルを適用して更新します。

  • 問題 2866682:Microsoft Azure で、SUSE Linux Enterprise Server (SLES) 12 SP4 ワークロード仮想マシンでネットワークの高速化が有効になっているときに、NSX Agent をインストールすると、イーサネット インターフェイスが IP アドレスを取得しない

    仮想マシン エージェントが起動せず、仮想マシンが管理対象外になります。

    回避策:高速ネットワークを無効にします。

  • 問題 2867243:有効なメンバーのないポリシー グループまたは NSGroup に対する有効なメンバーシップ API が、API 応答で results および result_count フィールドを返さない

    これによる機能上の影響はありません。

    回避策:なし。

  • 問題 2868235:同じ VDS に複数の物理 NIC が接続されている場合、可視化機能により、クイック スタートの [ネットワークとセキュリティ] ダイアログに重複する VDS が表示される

    可視化機能により、重複する VDS が表示されます。可視化グラフにフォーカスがある場合、[ホスト スイッチのカスタマイズ] セクションを見つけたり、スクロールするのが難しい場合があります。

    回避策:スクロールに問題がある場合は、Tab キーを押すか、マウス ポインタを表示領域外に移動し、スイッチ構成のカスタマイズ セクションまでスクロールします。

  • 問題 2870085:すべてのルールのログを有効または無効にするセキュリティ ポリシー レベルのログが機能しない

    セキュリティ ポリシーで logging_enabled を変更しても、すべてのルールのログを変更することはできません。

    回避策:ルールごとにログを有効または無効にします。

  • 問題 2870529:Active Directory ドメインを追加するときに、大文字と小文字が一致しない NetBIOS 名が使用されると、Identify Firewall (IDFW) のランタイム情報を取得できない

    IDFW の現在のランタイム情報/状態をすぐに取得することはできません。現在アクティブなログインを特定できません。

    回避策:問題のドメインの NetBIOS 名を修正します。変更が適用されると、以降のすべての IDFW イベントが正しく報告されます。

  • 問題 2870645:/policy/api/v1/infra/realized-state/realized-entities API の応答で publish_status が「成功」になっていても(認識の成功を意味する)、publish_status_error_details にエラーの詳細が表示される

    これによる機能上の影響はありません。

    回避策:なし。

  • 問題 2871585:バージョン 7.0.3 より前の DVS では、vSphere dvPortgroups の NSX セキュリティ機能を有効にした後、DVS からのホストの削除と DVS の削除が許可される

    DVS からのホストの削除または DVS の削除で発生するトランスポート ノードまたはクラスタ構成の問題を解決する必要がある場合があります。

    回避策:なし。

  • 問題 2874236:アップグレード後、HA ペアに Public Cloud Gateway (PCG) を 1 つだけ再展開すると、古い HA AMI/VHD ビルドが再利用される

    これは、アップグレード後に PCG を初めて再展開したときにのみ発生します。

    回避策:API を使用して、アップグレード後に適切な AMI または VHD を提供します。

  • 問題 2875385:新しいノードがクラスタに参加するときに、ローカル ユーザー(admin、audit、guestuser1、guestuser2)の名前が別の名前に変更されている場合、これらのローカル ユーザーでログインできないことがある

    ローカル ユーザーではログインできません。

    回避策:回避策は 2 つあります。

    • 回避策 1:ユーザー名を任意の名前に変更してから、目的の名前に戻します。
    • 回避策 2:ユーザー名を変更できない場合は、NSX Manager を再起動します。
  • 問題 2848614:MP クラスタに publish_fqdns が設定され、参加するノードに対して外部 DNS サーバに正引き参照または逆引き参照エントリがないか、DNS エントリがない場合に、MP を MP クラスタを参加させると、参加するノードに正引きアラームまたは逆引きアラームが生成されない

    DNS サーバに正引き/逆引き参照エントリがないか、参加するノードの DNS エントリがない場合でも、参加するノードに対して正引き/逆引きアラームが生成されません。

    回避策:正引きと逆引きの DNS エントリを使用して、すべてのマネージャ ノードの外部 DNS サーバを構成します。

  • 問題 2719682:Avi Controller の計算フィールドがポリシーのインテントに同期されないため、Avi UI と NSX-T UI に表示されるデータが一致しない

    NSX-T UI で、Avi Controller の計算フィールドが空白になります。

    回避策:アプリケーション スイッチャを使用して、Avi UI からのデータを確認します。

  • 問題 2747735:リストア後、ネットワークの互換性の問題が原因で VIP の接続が切断される

    バックアップのリストア中に、AddNodeToCluster 手順の前に VIP を更新できます。

    [回避策がある場合はそれを入力。ない場合は「なし」と入力] 通常、リストアは AddNodeToCluster 手順で一時停止し、マネージャ ノードを追加するかどうかユーザーに確認します。手順 a. [システム/アプライアンス UI] ページから新しい IP アドレスを使用できるように、VIP を削除または更新します。手順 b. VIP が修正されたら、リストアされた 1 ノード クラスタにノードを追加します。

  • 問題 2816781:物理サーバは、単一 VTEP をサポートしているため、ロード バランシング ベースのチーミング ポリシーを使用して構成できない

    ロード バランシング ベースのチーミング ポリシーを使用して物理サーバを構成することはできません。

    回避策:チーミング ポリシーをフェイルオーバー ベースのチーミング ポリシーに変更するか、単一の VTEP を持つ任意のポリシーに変更します。

  • 問題 2856109:Avi Controller のバージョンが 21.1.2 の場合、2,000 個目のプールメンバーを追加するとエラーが発生する

    Avi Controller 21.1.2 で許可されるプール メンバー数は 2,000 個ではなく、1,999 個です。

    回避策:Avi Controller のバージョンを 20.1.7 または 21.1.3 にします。

  • 問題 2862418:正確なパケット数を追跡するように LTA を構成すると、ライブ トラフィック分析 (LTA) で最初のパケットが失われることがある

    最初のパケット トレースを確認できません。

    回避策:なし。

  • 問題 2864929:NSX-T Data Center で、NSX for vSphere から Avi ロード バランサに移行すると、プール メンバー数が多くなる

    プール メンバーの数が多くなります。健全性モニターでは、これらのプール メンバーが「停止」としてマークされますが、トラフィックは到達不能なプール メンバーに送信されません。

    回避策:なし。

  • 問題 2865273:NSX for vSphere から NSX-T Data Center に移行する前に、ポート 22、443、8443、123 をブロックする DFW ルールが存在する場合、Advanced Load Balancer (Avi) 検索エンジンが Avi Controller に接続できない

    Avi 検索エンジンが Avi Controller に接続できません。

    回避策:SE 仮想マシンのポート 22、443、8443、123 を許可する DFW ルールを明示的に追加するか、SE 仮想マシンを DFW ルールから除外します。

  • 問題 2866885:イベント ログ スクラッパー (ELS) では、Active Directory ドメインで構成された NetBIOS 名が Active Directory サーバと一致する必要がある

    ELS によってユーザー ログインが検出されない

    回避策:Active Directory サーバと一致するように NetBIOS 名を変更します。

  • 問題 2868944:NSX for vSphere から NSX-T Data Center に 1,000 個を超える DFW ルールを移行すると、UI のフィードバックが表示されないが、1,000 個以下のルールを含む複数のセクションに分割分される

    ユーザー インターフェイスのフィードバックが表示されません。

    回避策:ログを確認してください。

  • 問題 2878030:ローカル マネージャ サイトの変更によるオーケストレータ ノードのアップグレードで通知が表示されない

    UC のアップグレード後にオーケストレータ ノードを変更し、アクション ボタン(事前チェック、開始など)をクリックして UI ワークフローを続行すると、アップグレード UI に進行状況が表示されません。この問題は、サイト マネージャを使用してグローバル マネージャの UI からローカル マネージャのアップグレード UI にアクセスした場合にのみ発生します。

    回避策:このサイトのローカル マネージャに移動してアップグレードを続行し、予期される通知を確認します。

  • 問題 2878325:Manager のインベントリ キャパシティ ダッシュボード ビューで、[IP セットに基づくグループ] 属性の数に、ポリシーのユーザー インターフェイスから作成された IP アドレスのあるグループが含まれない

    IP アドレスを含むポリシー グループがある場合、Manager のインベントリ キャパシティ ダッシュボード ビューで [IP セットに基づくグループ] に正しい数が表示されません。

    回避策:なし。

  • 問題 2879133:マルウェア防止機能が機能するまでに 15 分かかる場合がある

    マルウェア防止機能を初めて構成したときに、この機能の初期化が完了するまでに 15 分かかることがあります。この初期化が完了するまでマルウェアの分析は実行されませんが、初期化の発生を示す通知は表示されません。

    回避策:15 分間待機します。

  • 問題 2879734:2 つの異なる IPsec ローカル エンドポイントで同じ自己署名証明書が使用されていると、構成が失敗する

    エラーが解決されるまで、失敗した IPsec セッションは確立されません。

    回避策:ローカル エンドポイントごとに一意の自己署名証明書を使用します。

  • 問題 2879979:IPsec ピアにアクセスできないために、Dead Peer Detection が発生した後、IKE サービスが新しい IPsec ルート ベースのセッションを開始しないことがある

    特定の IPsec ルート ベースのセッションが停止する可能性があります。

    回避策:IPsec セッションで有効または無効にすると、問題を解決できます。

  • 問題 2881281:複数の仮想サーバを同時に構成すると失敗する場合がある

    仮想サーバへのクライアント接続がタイムアウトになることがあります。

    回避策:次の API を実行して、論理ルーター ワークフローを再トリガします。

    https://{ip}/api/v1/logical-routers/<id>? action=reprocess

  • 問題 2881471:展開状態が「失敗」から「成功」に変わっても、サービス展開の状態が更新されない

    発生したアラームが解決されず、サービス展開の状態が「停止」のままになることがあります。

    回避策:サービス展開状態の API を使用して、状態を確認します。

    API:https://{{nsx-mgr-ip}}/api/v1/serviceinsertion/services/{{service-id}}/service-deployments/{{service-deployment-id}}/status

  • 問題 2882070:マネージャ API のリストに、グローバル グループの NSGroup メンバーと基準が表示されない

    これによる機能上の影響はありません。

    回避策:ローカル マネージャでポリシー API を使用してグローバル グループ定義を表示します。

  • 問題 2882769:NSX-T 3.2 にアップグレードした後、NSService オブジェクトと NSServiceGroup オブジェクトのタグが引き継がれない

    NSService と NSServiceGroup のタグを使用しているワークフローがないため、これによる NSX の機能上の影響はありません。これらのオブジェクトのタグに依存するワークフローのある外部スクリプトには影響が生じる可能性があります。

    回避策:NSX-T 3.2 にアップグレードした後、エンティティを更新し、不足しているタグを NSService と NSServiceGroup に追加します。

  • 問題 2884939:NSX for vSphere から NSX-T ALB に多くの仮想サービスを移行すると、NSX のレート制限(1 秒あたり 100 要求)に達し、すべての API がしばらくブロックされる

    構成の移行後、しばらくの間、NSX-T ポリシー API で次のエラーが発生します。クライアント「admin」が 1 秒あたり 100 の要求レートを上回っています(エラー コード:102)

    回避策:クライアント API のレート制限を 1 秒あたり 200 要求に更新します。

  • 問題 2792485:vCenter Server に、インストールされたマネージャの FQDN ではなく、NSX Manager の IP アドレスが表示される

    vCenter Server の統合 NSX-T UI に、インストールされているマネージャの FQDN ではなく、NSX Manager の IP アドレスが表示されます。

    回避策:なし。

  • 問題 2884518:NSX アプライアンスを NSX-T 3.2 にアップグレードした後、ネットワーク トポロジー UI で、セグメントに接続された仮想マシンの数が正確でない

    ネットワーク トポロジーで、セグメントに接続されている仮想マシンの数が間違っています。ただし、仮想マシンのノードを展開すると、セグメントに関連付けられている仮想マシンの実際の数が表示されます。

    回避策:

    1. エンジニアリング モードで NSX アプライアンスにログインします。
    2. 次のコマンドを実行します。curl -XDELETE http://localhost:9200/topology_manager
  • 問題 2874995:未使用の場合でも LCore の優先順位が高いままになり、一部の仮想マシンで使用できない場合がある

    通常遅延の仮想マシンのパフォーマンスが低下します。

    回避策:2 つのオプションがあります。

    • システムを再起動します。
    • 優先順位の高い LCore を削除してから再作成します。その後、デフォルトで通常の優先順位の LCore に戻ります。
  • 問題 2772500:ENS でネストされたオーバーレイを有効にすると、PSOD が発生する可能性がある

    PSOD が発生する可能性があります。

    回避策:ENS を無効にします。

  • 問題 2832622:編集または変更後に IPv6 ND プロファイルが有効にならない

    ネットワークが引き続き古い NDRA プロファイルを参照します。

    回避策:ccp を再起動して、IPv6 ND プロファイルを更新します。

  • 問題 2840599:MP 正規化 API で INVALID_ARGUMENT エラーが発生する

    ユーザー インターフェイスの操作性が良くありません。

    回避策:なし。

  • 問題 2844756:セグメントの削除がエラーで失敗する

    セグメントを削除できません。

    回避策:セグメントに接続しているポートを強制的に削除します。

    1. 次の API を使用して、そのセグメントに接続されている論理ポートのリストを取得します。たとえば、PolicySegment01 の場合は、次のようになります。

      GET : https://<NSX MANAGER IP>/policy/api/v1/infra/segments/PolicySegment01/ports

    2. 上記の呼び出しで返されたリストにある論理ポートごとに、次の呼び出しを行います。

      DELETE : https://<NSX MANAGER IP>/api/v1/logical-ports/<LOGICAL PORT UUID>?detach=true

    接続されているポートがすべて削除されると、セグメントを削除できます。

  • 問題 2866751:シャドウ グループに対する統合された有効なメンバーシップ API の応答で、静的 IP が表示されない

    これにより、機能上またはデータパスへの影響はありません。シャドウ グループに対する統合された有効なメンバーシップの GET API で、静的 IP が表示されません。これは、シャドウ グループ(参照グループ)にのみ該当します。

    回避策:元のサイトで、シャドウ グループの統合された有効なメンバーシップを確認します。

  • 問題 2869356:IPSet メンバーのある NSGroup の [概要] タブをクリックすると、管理プレーンにエラーが表示される

    ユーザー エクスペリエンスが低下します。

    回避策:なし。

  • 問題 2872658:サイト登録後、UI に次のエラーが表示されます。「インポートできません。次の機能はサポートされていません:IDS」

    これによる機能上の影響はありません。NSX-T 3.2 では、構成のインポートがサポートされていません。

    回避策:ローカル マネージャから IDS 構成を削除し、登録を再試行します。

  • 問題 2877628:6.6 より前のバージョンの ESX ホスト スイッチ VDS にセキュリティ機能をインストールしようとすると、不明なエラー メッセージが表示される

    このエラー メッセージは、ユーザー インターフェイスと API で表示されます。

    回避策:ESX で 6.6 以降の VDS バージョンを使用して、NSX セキュリティをインストールします。

  • 問題 2877776:get controllers の出力に、controller-info.xml ファイルと比べてマスター以外の古いコントローラに関する情報が表示されることがある

    この CLI 出力は混乱を招きます。

    回避策:この TN で nsx-proxy を再起動します。

  • 問題 2879119:仮想ルーターを追加すると、対応するカーネル ネットワーク インターフェイスが起動しない

    VRF のルーティングが失敗します。VRF を介して接続された仮想マシンに対して接続が確立されていません。

    回避策:dataplane サービスを再起動します。

  • 問題 2881168:LogicalPort GET API の出力が、前の形式 (fc00::1) と比べると、拡張形式 (fc00:0:0:0:0:0:0:1) になる

    NSX-T 3.2 の LogicalPort GET API の出力は、NSX-T 3.0 の形式 (fc00::1) と比べると、拡張形式 (fc00:0:0:0:0:0:0:1) になります。

    回避策:なし。

  • 問題 2882822:NSX for vSphere から NSX-T への構成の移行で、Edge ファイアウォール ルール/LB プール メンバーで使用されるセキュリティ グループに一時 IPSet が追加されない

    移行中、NSX-T で仮想マシン/VIF が検出され、静的/動的メンバーシップを介して適用可能な SG の一部になるまで、ギャップが生じることがあります。これにより、移行が終了するまで、トラフィックがドロップまたは許可される可能性があります。これは、North/South のカットオーバー(NSX-T ゲートウェイを通過する N/S トラフィック)間の Edge ファイアウォール ルールとは異なります。

    回避策:送信元/宛先に Edge FW で使用されるすべてのセキュリティ グループが含まれる仮の DFW ルールを追加します。また、移行前に Edge ファイアウォール ルールの送信元と宛先を IPSet に移動する方法もあります。

  • 問題 2884070:NSX-T Edge アップリンクとピアリング ルーターの間で MTU 設定が一致しないと、OSPF ネイバーシップが Exstart 状態で停止する。NSX for vSphere から NSX-T への移行で MTU は自動的に移行されないため、この不一致が North/South Edge のカットオーバーでデータ プレーンに影響を及ぼす可能性がある

    OSPF 隣接関係が Exstart 状態で停止します。

    回避策:Edge のカットオーバー前に、OSPF ネイバー インターフェイスで一致する MTU を手動で構成します。

  • 問題 2884416:ロード バランサの状態をタイムリーに更新できない

    ロード バランサの状態が正しくありません。

    回避策:ロード バランサの統計情報の収集を停止します。

  • 問題 2885009:アップグレード後、グローバル マネージャに追加のデフォルト スイッチング プロファイルが追加される

    これによる機能上の影響はありません。

    回避策:プレフィックス nsx-default で始まるデフォルトのスイッチング プロファイルの使用は想定されていません。

  • 問題 2885248:InterVtep シナリオで、(Edge 仮想マシンと ESX ホストの VLAN に関係なく)EdgeVnic が NSX ポートグループに接続されている場合、Edge VTEP に送信されるパケットが ESX によってドロップされるため、ESX 上のワークロード仮想マシンと Edge 間の North-South トラフィックが停止する

    回避策:セグメントをインターフェイスから切断し、再接続して、Edge TN を更新します。

  • 問題 2885330:Active Directory グループの有効なメンバーが表示されない

    Active Directory グループの有効なメンバーが表示されません。これにより、データパスに影響が及ぶことはありません。

    回避策:なし。

  • 問題 2885552:OpenLDAP を使用する LDAP ID ソースを作成し、複数の LDAP サーバが定義されている場合、最初のサーバのみが使用される

    最初の LDAP サーバが使用できなくなると、構成済みの残りの OpenLDAP サーバを試行する代わりに、認証に失敗します。

    回避策:OpenLDAP サーバの前にロード バランサを配置し、ロード バランサの仮想 IP を使用して NSX を構成できる場合は、高可用性を実現できます。

  • 問題 2886210:リストア中に vCenter Server が停止すると、[バックアップ/リストア] ダイアログが表示され、vCenter Server が起動して実行されていることを確認するように指示されるが、vCenter Server の IP アドレスが表示されない

    vCenter Server 接続のリストア中に vCenter Server の IP アドレスが表示されません。

    回避策:次のリストア手順に進む前に、登録されているすべての vCenter Server が実行されていることを確認します。

  • 問題 2886971:グローバル マネージャで作成されたグループが削除後にクリーンアップされない。これは、そのグループがローカル マネージャ サイトのリファレンス グループの場合にのみ発生する

    機能上の影響はありませんが、削除したグループと同じポリシーパスで別のグループを作成することはできません。

    回避策:なし。

  • 問題 2887037:マネージャからポリシー オブジェクトへの昇格後、NAT ルールを更新または削除できない

    この問題は、昇格がトリガされる前に、マネージャで PI(プリンシパル ID)ユーザーによって NAT ルールが作成された場合に発生します。PI ユーザーが作成した NAT ルールは、マネージャからポリシー オブジェクトへの昇格後に更新または削除できません。

    回避策:マネージャからポリシー オブジェクトへの昇格の前に、admin などの保護されていないユーザーを使用して、同じ構成の NAT ルールを作成できます。

  • 問題 2888207:vIDM が有効な場合、ローカル ユーザーの認証情報をリセットできない

    vIDM が有効になっている間、ローカル ユーザーのパスワードを変更できません。

    回避策:vIDM 構成を一時的に無効にして、その間にローカル認証情報をリセットし、統合を再度有効にする必要があります。

  • 問題 2889748:再展開に失敗すると Edge ノードの削除に失敗する。削除すると、システムに古いインテントが残り、ユーザー インターフェイスに表示される

    Edge 仮想マシンは削除されますが、古い Edge インテントと内部オブジェクトがシステムに残ります。削除操作は内部で再試行されます。Edge 仮想マシンが削除され、インテントにのみ古いエントリが含まれるため、これによる機能上の影響はありません。

    回避策:なし。

  • 問題 2875962:クラウド ネイティブ セットアップのアップグレード ワークフローが NSX-T 3.1 と NSX-T 3.2 で異なる

    通常のワークフローに従うと、すべての CSM データが消去されます。

    回避策:アップグレードを行うには、VMware のサポートが必要です。VMware のサポートにお問い合わせください。

  • 問題 2888658:マルウェア検出とサンドボックス機能が有効になっている場合、NSX-T ゲートウェイ ファイアウォールで確認される 1 秒あたりの接続数とスループットの点で、パフォーマンスに重大な影響が発生する

    マルウェア検出の対象となるトラフィックで大幅な遅延が発生し、接続が失敗する可能性があります。ゲートウェイでマルウェア検出が有効になっていると、L7FW トラフィックにも影響し、遅延と接続障害が発生します。

    回避策:トラフィックの小さなサブセクションにのみ一致する IDS ルールを作成して、マルウェア検出の対象となるトラフィックの量を制限します。

  • 問題 2882574:NSX-T 3.2.0 リリースで「ブラウンフィールド構成オンボーディング」機能が完全にサポートされていないため、この API がブロックされる

    「ブラウンフィールド構成オンボーディング」機能を使用することはできません。

    回避策:なし。

  • 問題 2890348:NSX-T 3.2 にアップグレードするときに、デフォルトの VNI プールの名前を変更すると、一貫性のない VNI プールが生成される

    VNI の割り当てとそれに関連する操作が失敗することがあります。

    回避策:NSX-T 3.2 にアップグレードする前に、API PUT https://{{url}}/api/v1/pools/vni-pools/<vni-pool-id> を使用して、デフォルトの VNI プールの名前を DefaultVniPool に変更します。

  • 問題 2885820:0.0.0.0 で始まる IP 範囲の一部の IP アドレスが変換されない

    0.0.0.0 で始まる IP 範囲の NSGroup(0.0.0.0-255.255.255.0 など)に変換の問題があります(0.0.0.0/1 サブネットがありません)。

    IP 範囲が 1.0.0.0-255.255.255.0 の NSGroup は影響を受けません。

    回避策:0.0.0.0 で始まる IP 範囲のグループを構成する場合は、グループ構成に 0.0.0.0/1 を手動で追加します。

  • 問題 2871440:vMotion で、ダウンしている NSX Manager に接続しているホストに、vSphere dvPortGroups の NSX セキュリティで保護されたワークロードを移動すると、セキュリティ設定が失われる

    vSphere dvPortGroups の NSX セキュリティ機能付きでインストールされたクラスタの場合、ダウンした NSX Manager に接続しているホストに vMotion で移動した仮想マシンには、DFW とセキュリティ ルールが適用されません。これらのセキュリティ設定は、NSX Manager への接続が再度確立されるときに再適用されます。

    回避策:NSX Manager がダウンしている場合は、影響を受けるホストへの vMotion を回避します。他の NSX Manager ノードが機能している場合は、vMotion で、良好な NSX Manager に接続している別のホストに仮想マシンを移動します。

  • 問題 2945515:Azure での NSX Tools のアップグレードが Redhat Linux 仮想マシンで失敗する場合がある

    デフォルトでは、NSX Tools は /opt ディレクトリにインストールされます。ただし、NSX Tools のインストール中に、デフォルトのパスがインストール スクリプトの --chroot-path オプションで上書きされる場合があります。

    NSX Tools がインストールされているパーティションのディスク容量が不足していると、NSX Tools のアップグレードに失敗する可能性があります。

    回避策:なし。

  • 問題 2875563:IN_PROGRESS LTA セッションを削除すると、PCAP ファイルがリークする可能性がある

    LTA セッションの状態が「IN_PROGRESS」のときに、PCAP アクションで LTA が削除されると、PCAP ファイルがリークします。これにより、ESXi の /tmp パーティションがいっぱいになる可能性があります。

    回避策:/tmp パーティションをクリアすると、問題が解決する場合があります。

  • 問題 2875667:NSX /tmp パーティションがいっぱいになると、LTA PCAP ファイルのダウンロードでエラーが発生する

    /tmp パーティションがいっぱいのため、LTA PCAP ファイルをダウンロードできません。

    回避策:/tmp パーティションをクリアすると、問題が解決する場合があります。

  • 問題 2883505:NSX V2T 移行中に ESXi ホストで PSOD が発生する

    V2T 移行中に、複数の ESXi ホストで PSOD (パープル スクリーン) が発生します。これにより、データパス障害が発生する可能性があります。

    回避策:なし。

  • 問題 2914934:NSX-V を NSX-T に移行すると、dvPortGroup の DFW ルールが失われる

    NSX-V を NSX-T に移行した後、引き続き vSphere dvPortGroup に接続しているワークロードで DFW 構成が失われます。

    回避策:NSX-V から NSX-T に移行した後、同じ DFW 構成を持つ VLAN セグメントが構成されます。dvPortGroups ではなく、VLAN セグメントを使用します。

    もう 1 つの回避策として、NSX-V をアンインストールしてから、NSX-T をセキュリティ専用モードでインストールする方法もあります。これにより、既存の dvPortGroup でワークロードを使用できるようになります。

  • 問題 2921704:L7 ロード バランサで ip-hash ロード バランシング アルゴリズムを使用すると、nginx プロセスのデッドロックが原因で Edge サービスの CPU 使用量が急増することがある

    ロード バランサの背後にあるバックエンド サーバに接続できません。

    回避策:問題を修正するには、L4 エンジンに切り替えます。引き続き L7 ロード バランサを使用する場合は、ロード バランシング アルゴリズムを ip-hash ではなく round-robin に変更します。

  • 問題 2933905:NSX-T Manager を置き換えると、トランスポート ノードとコントローラの接続が失われる

    マネージャ クラスタでノードを追加または削除すると、一部のトランスポート ノードでコントローラとの接続が失われる可能性があります。

    回避策:管理クラスタでマネージャの追加または削除が行われた場合は、影響を受けたトランスポート ノードで nsx プロキシ サービスを再起動します。これにより、controller-info.xml が更新され、コントローラ接続が確立されます。

check-circle-line exclamation-circle-line close-line
Scroll to top icon