3行まとめ
このテーマをもう少し広げて見るなら、VCF 9.1でNVMe Memory Tieringを有効化する前に確認する：esxcli memtier、DRAM:NVMe比率、VM制約の実務ポイント と VCF 9.1のArista/AMD連携を導入前に確認する：EVPN/VXLAN、MI350、AI基盤設計の実務ポイント も合わせて確認してください。EDP Standardと同じく、VCF 9.1の性能改善を導入前チェックとして読む流れを補完できるため。
EDP Standardを前提に、クラスタ設計、NSX構成、VMテンプレート、監視基準を先にそろえます。
TNP変更やmaintenance modeを伴う作業として扱い、対象クラスタと戻し方を明確にします。
VMXNET3、NSXバージョン、物理NIC、NUMA、NetQueue、測定項目を切替前に確認します。
EDP Standardは単なる高速化機能ではなく、導入前の設計と運用確認まで含めて判断します。
BroadcomのVMware Cloud Foundation Blogは2026年6月9日、VCF環境のネットワーク性能を扱うEnhanced Data Path、つまりEDPの解説を公開しました。読むべき中心は「速くなるらしい」ではなく、VCF 9.xの新規導入でEDP Standardを前提に設計し、既存環境では切替を明示的な作業として扱う点です。
導入前に見るべき実務ポイントは、VMのvNICがVMXNET3か、NSXの採用バージョンとEDP関連修正を説明できるか、NSX Transport Node Profileを変更した場合にどのクラスタやホストがmaintenance modeへ入るかです。性能の話に見えて、実際には設計、棚卸し、変更作業の話まで含みます。
この記事は2026年6月11日 JST時点で確認した公式情報に基づく非提携の確認メモです。Broadcom Inc.およびVMware by Broadcomとは関係なく、製品導入、契約変更、投資判断を勧めるものではありません。
まず分けるべき3つの環境
EDP Standardの読み方は、環境によって変わります。新規のVCF 9.xでは既定値として見る話です。VCF 5.2.xでは任意に評価する話です。VCF 5.2.xからVCF 9.xへ移行する環境では、アップグレードだけで勝手に切り替わると読まないことが大切です。
この違いを曖昧にすると、性能改善の話と移行作業の話が混ざります。特に既存クラスタでは、TNPの変更、ホストの順次メンテナンス、切替前後の測定までを一つの変更作業として扱う必要があります。
判断の軸
新規導入なら「EDP Standardを前提に設計レビューをする」。既存環境なら「切替対象、作業時間、戻し方、測定方法を決めてから評価する」。この2つを分けるだけで、公式ブログの読み方はかなり実務に近づきます。
この記事で扱わないこと
この記事では、NSX CLIの詳細手順、個別NICの互換性断定、EDP Dedicatedの深い設計、サポートケースの代替は扱いません。そこまで踏み込む場合は、Broadcom TechDocs、互換性情報、契約中のサポート窓口で確認してください。
範囲外にする理由
EDPはネットワーク性能に関わる機能ですが、実際の成否はワークロード、VMのvNIC、物理NIC、ドライバ、NSXバージョン、ホスト容量、運用手順に左右されます。一般記事で特定環境の正解を断定するより、導入前に見る順番を固定する方が読者に役立ちます。
EDP Standardをニュースではなく導入前チェックとして読む
- 1Daily VCFのNew表示
注目度の高い更新として扱い、確認対象に入れます。
- 2公式ブログ
VCF 9.xの既定値、VCF 5.2.xでの任意利用、性能例を確認します。
- 3TechDocs
EDP StandardとDedicatedの位置づけ、host switch network performanceの前提を確認します。
- 4リリースノート
推奨ベースラインとEDP関連修正を分けて読みます。
- 5社内検証
throughput、packet rate、latency、CPU utilizationを自社条件で測り直します。
公式の性能例は判断材料であり、自社環境の保証値として扱わないことが重要です。
VMware Cloud Foundation BlogのEDP記事は、データセンターファブリックが100Gbpsから400Gbpsへ進む中で、ハイパーバイザのネットワーク処理がボトルネックになり得るという問題意識から始まっています。従来のパケット処理では、ヘッダ解析、ポリシー確認、ルーティング、セキュリティ処理が直列に積み重なり、高いパケットレートではCPU消費と遅延が増えます。
EDP Standardは、この処理をすべて毎回同じように通すのではなく、フローの初回処理後にFlow Cacheを使って後続パケットを速く処理する考え方です。公式ブログでは、Thread Load Balancer、Mbuf Framework、NetQueue、NUMA、VMXNET3などの要素も合わせて説明されています。
2026年6月9日の公式ブログで確認できること
公式ブログで確認できる大きな点は、EDP StandardがVCF 9.xの新規導入における既定の仮想スイッチモードとして説明されていることです。さらに、VCF 5.2.xではEDP Standardをオプションとして利用できるとされ、推奨ベースラインとしてvSphere 8.0 Update 3iとNSX 4.2.3.2が挙げられています。
ここで重要なのは、VCF 9.xの新規導入と既存環境の移行を同じ表現で扱わないことです。公式ブログは、VCF 5.2からVCF 9へ移る場合、アクティブなネットワーク状態は保持され、既存クラスタは明示的に移行しない限り現在のスタックに残ると説明しています。
根拠
Broadcom TechDocsのEnhanced Data Pathページでも、EDPはthroughput、packet rate、latency、CPU utilizationの面で高い性能を提供するpacket forwarding stackとして説明されています。また、新規VCF 9デプロイでは仮想スイッチがEDP Standard modeで動作する、と整理されています。
Daily VCFのNew表示は需要シグナルとして扱う
Daily VCFでも、EDP記事はNew表示の公式記事として拾われています。これは読者が今確認したいテーマを示す材料になりますが、仕様や性能値の根拠にはしません。記事の根拠は、公式ブログ、Broadcom TechDocs、NSXリリースノートに置きます。
需要シグナルとして見るなら、問いは「EDPはどれくらい速いのか」だけではありません。「新規VCF 9.xでは何を前提に設計すべきか」「既存VCF 5.2.xではどのタイミングで切り替えるべきか」「VMXNET3でないVMが残っている場合にどう扱うか」まで広がります。
注意点
SNSやアグリゲータで話題になったからといって、性能値をそのまま自社環境へ持ち込むのは危険です。EDPはネットワーク経路全体に関わるため、読者側の確認は、VM、ホスト、NSX、物理NIC、監視基準まで広がります。
VCF 9.x記事群の中での位置づけ
直近のBroadcom Watch Japanでは、VCF 9.1のVPC Network Spanや、VCF 5.2.xから9.1への移行計画を扱ってきました。今回のEDPは、同じネットワーク領域でも、VPCの可視範囲やTGWの話ではなく、ホスト側のデータパス、CPU消費、パケット処理効率の話です。
Private CloudやAI推論の文脈では、アプリをどこに置くかだけでなく、東西トラフィック、NSX Edge、分散ファイアウォール、観測ログの負荷が効いてきます。EDP Standardは、そうした基盤性能の確認項目として読むのが自然です。
関連する既存テーマ
VPC Network Spanは「どのクラスタにネットワークを見せるか」。EDP Standardは「そのクラスタ内でパケットをどう効率よく処理するか」。この2つは近いようで、導入前チェックの場所が違います。
新規VCF 9.x導入でEDP Standardを前提にする理由
同じEDPでも、既定値、任意切替、アップグレード、Dedicatedでは確認すべき前提が異なります。
新規VCF 9.xでEDP Standardが既定になるなら、導入後に性能確認で慌てるのではなく、設計段階で前提として扱うべきです。クラスタ設計、NSX構成、VMテンプレート、物理NIC、監視ベースラインが後から分断されると、EDPの効果が見えにくくなります。
一方で、既存VCF 5.2.xでは「オプションとして使える」と「本番に入れてよい」は同じではありません。vSphere 8.0 Update 3iとNSX 4.2.3.2という推奨ベースラインは、検討の入口です。自社の採用パッチ、既知問題、ドライバ、運用制約を合わせて確認する必要があります。
新規VCF 9.xでは既定値として見る
VCF 9.xの新規導入でEDP Standardを前提にするということは、単にネットワークが速くなると期待することではありません。VMテンプレートがVMXNET3を使うか、NSX Edgeの配置に余裕があるか、ホストのNUMAと物理NICの位置関係を無視していないか、観測ログを有効にした時の負荷をどの指標で見るかまで含みます。
導入設計書には、EDPの有効化状態だけでなく、切替前後に見る測定項目も残したいところです。throughput、packet rate、latency、CPU utilization、pNIC使用率、vNICエラー、NSX EdgeのCPU、分散ファイアウォールやIPFIXなどの観測機能の負荷を同じ条件で見ると、あとから説明しやすくなります。
確認項目
新規環境では、まずVMテンプレート、NSX Transport Node Profile、ホストNIC、ドライバ、ファームウェア、監視ダッシュボードを同じタイミングで確認します。EDPだけを個別機能として見ない方が、問題が起きた時に切り分けやすくなります。
既存VCF 5.2.xでは任意利用として評価する
公式ブログは、VCF 5.2.x環境でEDP Standardを使う場合の推奨ベースラインとしてvSphere 8.0 Update 3iとNSX 4.2.3.2を示しています。この情報は有用ですが、それだけで本番投入を決める材料には足りません。
既存環境では、長く使っているVMテンプレート、古いvNIC、ホストごとの物理NIC差、NSX EdgeとワークロードVMの同居、運用時間帯、DRSの余力が残っています。EDPを評価するなら、まず対象クラスタを絞り、既存VMのvNIC比率を棚卸しし、切替作業中にホストを退避できるかを見ます。
条件
推奨ベースラインは「ここから確認を始める数字」です。自社環境のパッチポリシーやサポート条件が違う場合は、NSX 4.2.4以降のリリースノート、既知問題、Broadcomサポート情報も合わせて確認してください。
アップグレードでは自動切替と書かない
VCF 5.2からVCF 9.xへ上げる場合、既存クラスタが自動でEDP Standardへ切り替わると読んでしまうと、作業計画を間違えます。公式ブログは、移行時にアクティブなネットワーク状態が保持されると説明しています。つまり、アップグレードとEDP切替は、近いけれど別の判断です。
この点は、VCF 5.2.xから9.1へのアップグレード全体を扱った既存記事ともつながります。アップグレードの順序、NSX、vCenter、ESXi、VCF Management Servicesの確認が終わっていない状態で、EDP切替だけを急ぐべきではありません。
注意点
切替を別作業にするなら、作業前後の性能測定、戻し方、ホスト退避、変更申請、アプリ担当への連絡が必要です。EDPは性能機能であると同時に、運用上はクラスタ変更作業として扱うのが安全です。
VMXNET3、NUMA、NetQueueで先に棚卸しすること
VMXNET3に寄せるほど評価しやすくなりますが、最終判断は対象VMと実ワークロードの測定結果で行います。
EDP Standardの導入前チェックで最初に見るべきなのは、VMがVMXNET3を使っているかです。公式ブログは、EDP Standardの高度なソフトウェア改善はVMXNET3に最適化されており、E1000のようなエミュレート型アダプタは動作しても性能改善を得られないと説明しています。
この一文は、既存環境では重い意味を持ちます。古いテンプレート、移行してきたVM、例外的なOS、検証用VMにE1000が残っていると、EDPの効果を測定しても結果がばらつきます。
VMXNET3でないVMは期待値を分ける
VMXNET3へ寄せるかどうかは、OSサポート、VMware Tools、アプリ停止、変更手順に関わります。EDPを評価する前に、対象VMのvNIC種別を一覧化し、性能測定の対象を分けるべきです。
すべてのVMを一度に変える必要はありません。まずは通信量が多いVM、NSX Edgeに近い経路、分散ファイアウォールやIPFIXの影響を受ける通信、AI/データ処理系の東西トラフィックを優先して確認します。
根拠
VMXNET3がEDPの恩恵を受ける前提なら、E1000を含む測定結果を「EDPが効かなかった」と結論づけるのは早すぎます。vNICの棚卸しは、性能検証の前処理です。
NUMAとCPU消費を容量計画につなげる
公式ブログでは、1518-byte framesの例として、標準スタックの34GbpsからEDP Standardの64Gbpsへ向上し、最大負荷に必要なホストコア数が最大28から16へ下がったと説明されています。さらに、分散ファイアウォールやVDS IPFIXログのような観測機能がある場合でも、低下をas low as 18.4%に抑える例が示されています。
ただし、これは公式ブログが示す条件下の例です。自社の本番環境で同じ値が出るという意味ではありません。見るべきなのは、同じワークロード、同じ監視設定、同じホスト配置で、CPU消費、遅延、パケットドロップ、アプリ側SLOがどう変わるかです。
評価基準
性能値を見る時は、Gbpsだけに寄せない方がよいです。CPU ready、ESXiホストのpNIC使用率、NSX EdgeのCPU、vNICリセット、BGP/BFDの安定性、監視ログの落ち方を合わせて見ると、運用判断に近いデータになります。
NetQueueや物理NICの条件を後回しにしない
公式ブログは、NetQueue OptimizationやShared NetQueue RSSにも触れています。物理NIC側で受信キューを分類し、複数VMがRSS処理エンジンを共有することで、高スループットとコア効率のバランスを取る考え方です。
ここは、ソフトウェア設定だけでは完結しません。物理NIC、ドライバ、ファームウェア、キュー数、RSS、NUMA配置、ホストのPCIe構成が絡みます。導入前の棚卸しにネットワークチームとサーバーチームを入れないと、EDPの話がNSX担当だけに閉じてしまいます。
確認項目
PoCでは、対象ホストのNIC型番、ドライバ、ファームウェア、pNICとNUMA nodeの関係、VMの配置、NSX Edgeの配置を記録します。公式互換性とBroadcomのサポート情報を確認し、記事やブログだけで対応可否を断定しないことが大切です。
TNPとVCP remediationで既存クラスタを切り替える時の実務ポイント
- 1現状棚卸し
対象クラスタ、VM、NSX、物理NIC、監視基準を確認します。
- 2TNPで設定確認
NSX Transport Node Profileのdatapath switch modeを確認します。
- 3対象クラスタを絞る
一括変更にせず、影響範囲と優先順位を決めます。
- 4VCP remediation
vSphere Configuration Profilesが有効な場合のremediationを作業計画に入れます。
- 5maintenance mode
DRS、vMotion、退避先容量、NSX Edge配置、作業時間帯を確認します。
- 6通信と性能を再測定
throughput、packet rate、latency、CPU utilization、アプリのSLOを切替前後で比較します。
既存クラスタの切替は小さな設定変更ではなく、退避、変更、再測定までを含む運用作業として扱います。
既存クラスタでEDP Standardを有効化する場合、公式ブログはNSX Transport Node Profile、つまりTNPでdatapath switch modeを変更できると説明しています。また、vSphere Configuration Profilesが有効な場合、VCFはホストを順次maintenance modeへ入れながらremediationを進めるとされています。
この説明から分かるのは、EDP切替が「小さなチェックボックス変更」では終わらないことです。ホストがmaintenance modeへ入るなら、DRS、vMotion、残りホスト容量、NSX Edgeの配置、アプリの冗長性、作業時間帯を確認する必要があります。
TNPで切り替える対象を決める
TNPは、複数のtransport nodeに設定を適用するためのテンプレートです。EDP設定を変更する前に、そのTNPがどのクラスタ、どのホスト、どのtransport zone、どのNSX Edgeに影響するかを確認します。
特に、管理ドメインとワークロードドメイン、汎用アプリクラスタと高トラフィッククラスタ、Edgeが同居するクラスタを分けて見る必要があります。対象範囲を曖昧にしたままTNPを変えると、意図しないホストまでremediation対象になるおそれがあります。
条件
まず小さな対象で検証し、成功条件を満たしてから広げるのが基本です。TNPの変更履歴、差分、対象クラスタ、戻し手順を変更申請に含めておくと、切替後の説明がしやすくなります。
VCP remediationの影響を作業計画に入れる
vSphere Configuration Profilesを使っている環境では、ホストが順次maintenance modeへ入り、remediationが進むと説明されています。maintenance modeへ入れるということは、そのホスト上のVMを退避できるだけのクラスタ余力が必要です。
NSX Edgeが動いている場合は、Edge VMやネットワークサービスの配置も確認します。DRSが動けば十分、という読み方は危険です。DRSが退避先を見つけられない場合、作業は止まるか、想定外の負荷状態になります。
注意点
EDP切替は、ネットワーク性能の改善作業でありながら、作業中はクラスタ容量と可用性を使います。ピーク時間を避けるだけでなく、残りホストでアプリSLOを守れるか、NSX Edgeの冗長性が保てるかを先に確認します。
切替前後の基準値を同じ条件で取る
EDP Standardを導入した後に「速くなった」「変わらない」と言うには、切替前の基準値が必要です。throughputだけでなく、packet rate、latency、CPU utilization、pNIC、vNIC、NSX Edge、分散ファイアウォール、IPFIX、アプリ応答時間を同じ条件で見ます。
測定条件が変わると、EDPの効果なのか、VM配置や通信量の変化なのか判断できません。可能なら、代表的な通信パターンを2つか3つに絞り、切替前後で同じ時間帯、同じ監視設定、同じアプリ負荷で比べます。
評価基準
成功条件は「公式ブログの数値に近いこと」ではありません。自社のボトルネックが減り、運用上の副作用が許容範囲に収まり、戻し方を使わずに済むことです。数値が改善しても、作業手順が再現できないなら本番展開には早いです。
NSXバージョンとEDP関連修正をどう読むか
最新修正の存在は確認材料であり、常に最新へ上げるという結論とは分けて扱います。
EDP Standardを検討する時は、公式ブログの推奨ベースラインと、NSXリリースノートの修正項目を分けて読みます。公式ブログはVCF 5.2.x向けの推奨ベースラインとしてvSphere 8.0 Update 3iとNSX 4.2.3.2を示しています。一方、NSX 4.2.4リリースノートにはEDPやEnhanced Dataplaneに関わる修正が含まれます。
これは、NSX 4.2.4へ必ず上げるべきだと断定する話ではありません。自社のパッチポリシー、互換性、既知問題、サポート条件を見て、採用する修正レベルを決めるための確認項目です。
推奨ベースラインと最新修正を分ける
推奨ベースラインは、EDP Standardを評価する入口として有用です。しかし、リリースノートの修正項目は、運用中に起き得る問題や、過去バージョンでの注意点を読むための材料です。
導入判断では、次のように分けると整理しやすくなります。公式ブログで「何を目指す機能か」を見る。TechDocsで「機能の位置づけとモード」を見る。NSXリリースノートで「自社が採用するバージョンの注意点」を見る。最後に、自社の変更管理で「いつ、どのクラスタへ入れるか」を決めます。
根拠
Broadcom TechDocsのEnhanced Data Pathページは、EDP Standardが一般的なcompute環境やNSX Edge clusterでhost switch network performanceを最大化する推奨モードだと説明しています。NSX 4.2.4リリースノートは、EDPやEnhanced Dataplaneに関わる個別修正を列挙しています。役割が違う資料です。
NSX 4.2.4のEDP関連fixを確認する
NSX 4.2.4リリースノートでは、Enhanced Dataplaneのメモリリークにより、NSX Edge VMとワークロードVMが同一ESXiホスト上で動く場合に断続的な接続障害が起きる修正項目が確認できます。説明では、EDP flow handling pathのメモリリークがENS fastslabやmbuf fastslab memory poolsを消費し、vmxnet3 transmit hangs、vNIC resets、packet loss、BGP/BFD session flapsにつながるとされています。
また、multi-port flow cacheに関わる修正項目もあります。これらは、読者環境で必ず起きる不具合という意味ではなく、EDP導入前にリリースノートを読むべき理由を示す例です。
確認項目
自社の採用バージョンで、既知問題、解決済み問題、アップグレード経路、ドライバ条件、NSX EdgeとワークロードVMの配置を確認します。リリースノートを読まずに性能機能だけを有効化するのは避けたいところです。
VCF 9.1のNSX更新と合わせて見る
VCF 9.1では、NSXまわりでVPC、Transit Gateway、Virtual Network Appliance、Avi Load Balancer連携、Edge関連UIなど、多くの更新が並びます。EDP Standardの切替と、VPC Network SpanやTGW外部接続の変更を同じ作業枠に詰め込むと、トラブル時の原因が見えにくくなります。
ネットワーク更新は、性能、配置、外部接続、IPAM、ロードバランサ、Edge、監視を分けて進める方が安全です。EDPは性能経路の確認、VPC Network Spanは配置可能範囲の確認として、目的を分けて扱います。
注意点
一度に複数のNSX変更を入れると、性能値が変わった理由を説明しにくくなります。EDPの検証期間は、できるだけ他のネットワーク変更を止め、測定条件をそろえるのが望ましいです。
EDP StandardとEDP Dedicatedをどう切り分けるか
一般的なcompute環境やNSX Edge clusterで、host switch network performanceを高める推奨モードとして見ます。
物理CPU予約、トラフィックパターン、ネットワーク要件を理解して設計する選択肢として扱います。
Standardで不足を感じた時に、Dedicatedの要件と運用負荷を改めて評価します。
StandardとDedicatedは単純な勝敗ではなく、対象ワークロードと設計条件で切り分けます。
EDPにはStandardとDedicatedがあります。この記事の中心はEDP Standardです。Broadcom TechDocsは、EDP Standardを一般的なcompute環境やNSX Edge clusterでhost switch network performanceを最大化する推奨モードとして説明しています。
EDP Dedicatedは、より特殊な要件を持つ選択肢です。物理CPUなどのリソース予約が必要になり、ワークロードのトラフィックパターンやネットワーク要件を理解して設計する必要があります。
本稿の中心はEDP Standard
一般的な企業のprivate cloudやVCF上のアプリ基盤では、まずEDP Standardをどう評価するかが現実的です。新規VCF 9.xなら既定値として、既存VCF 5.2.xなら任意切替として見ます。
EDP Standardは、Flow Cache、Thread Load Balancer、Mbuf Framework、VMXNET3、NetQueue、NUMAなどが組み合わさって効果を出します。単一の設定で完結する魔法のスイッチではありません。
条件
VMXNET3の比率、NSXバージョン、TNP対象、ホスト容量、監視基準がそろっていれば、EDP Standardは前向きに評価できます。逆に、この棚卸しができない環境では、まず現状把握を優先した方がよいです。
Dedicatedは性能要件だけで選ばない
EDP Dedicatedは、poll-modeの仕組みでCPUコアを専用的に使う設計として説明されています。公式ブログでは、telcoや5Gのような用途で使われる一方、動的でburstyな企業アプリケーションにはEDP Standardが推奨される、と整理されています。
Dedicatedは、名前だけ見ると高性能版に見えます。しかし、CPUコアを専用に使うなら、空いている時でも一般アプリへ戻せないリソースが生まれます。性能要件、トラフィックパターン、可用性、コスト、運用体制を含めた専門設計が必要です。
注意点
EDP Standardで足りないからすぐDedicated、という判断は避けます。まずStandardで実測し、pNIC飽和、CPU消費、遅延SLO、Edge配置、アプリ特性を見たうえで、サポート窓口や専門設計へ進むべきです。
Standardで不足を感じた時の追加評価
Standardで期待した効果が出ない場合は、EDP以外の要因も疑います。VMがVMXNET3ではない、E1000が混在している、物理NICやドライバが古い、NUMAをまたいでいる、監視機能の負荷が高い、NSX EdgeとワークロードVMの配置が偏っている、といった原因は珍しくありません。
EDPの評価では、性能値だけでなく、運用負荷も見ます。切替作業が難しすぎる、戻し方が曖昧、障害時の切り分けができないなら、本番展開の前に設計を戻した方がよいです。
評価基準
追加評価へ進む目安は、同じ条件で測ってもpacket rate、latency、CPU utilization、アプリSLOが改善しない場合です。その時も、Dedicatedを決め打ちせず、VM、NSX、ホスト、物理NIC、監視設定を順に切り分けます。
PoC前チェックリスト
PoCの目的は最高値を出すことではなく、本番に入れてよい条件と止める条件を見える形にすることです。
EDP StandardのPoCは、ベンチマークを一回走らせるだけでは足りません。対象クラスタ、VM、NSX、運用、測定、戻し方を先に決めておくと、結果を本番判断へつなげやすくなります。
特に既存環境では、TNP変更とVCP remediationが絡む可能性があります。PoCの段階から、maintenance modeに入れるホスト、退避先、作業時間帯、失敗時の判断基準を決めておくべきです。
構成と対象クラスタを固定する
まず、対象workload domain、cluster、transport zone、TNP、NSX Edge、vDS、物理NICを固定します。対象を広げすぎると、結果の解釈が難しくなります。
PoCでは、通信量が多く、かつ影響範囲を管理できるクラスタを選びます。管理ドメインや重要アプリの本番クラスタを最初に選ぶより、検証しやすいワークロードドメインから始める方が現実的です。
確認項目
TNPの対象範囲、ホスト数、残り容量、DRSの余力、NSX Edgeの配置、vMotion可能性、メンテナンスウィンドウ、変更承認を確認します。ここが曖昧なら、性能測定へ進む前に止まるべきです。
VMと通信の前提を固定する
次に、対象VMのvNIC、OS、VMware Tools、通信方向、packet size、通信量、アプリSLOを固定します。VMXNET3とE1000が混ざったまま測る場合は、結果を分けて解釈します。
可能なら、東西トラフィック、南北トラフィック、NSX Edge経由、分散ファイアウォールあり、観測ログありのように、代表パターンを決めます。すべてを同時に測るより、説明可能な範囲に絞る方が有効です。
確認項目
VMXNET3比率、E1000残存、測定ツール、監視ダッシュボード、vNICエラー、pNIC使用率、NSX Edge CPU、アプリ応答時間を記録します。測定項目は、PoC前に合意しておく必要があります。
失敗時の戻し方を決める
EDP Standard切替で期待した結果が出ない場合、戻すのか、対象を絞るのか、NSXバージョンを見直すのか、VMXNET3移行を先にするのかを決めておきます。戻し方が決まっていないPoCは、本番判断につながりません。
TNP変更やremediationが絡むなら、ロールバックも同じくらい慎重に扱います。切替後の性能が改善しても、戻し方を説明できない状態では、運用チームの合意は得にくいはずです。
注意点
PoCの成功条件は、最大スループットだけではありません。作業が再現できること、測定が説明できること、戻し方が決まっていること、アプリ担当が受け入れられることまで含めて評価します。
導入判断のまとめ
VMXNET3、NSXバージョン、TNP対象、maintenance mode、測定基準がそろっている場合です。
vNIC種別、対象クラスタ、退避容量、戻し方、観測項目が曖昧な場合は先に整理します。
公式例は導入判断のきっかけとして読み、自社ワークロードで再測定して容量計画に使います。
1518-byte framesの性能例やCPU削減の数字は、自社環境で再測定して初めて判断材料になります。
EDP Standardは、VCF 9.xの新規導入では最初から意識すべき前提です。既存VCF 5.2.xでは、任意切替として対象を絞り、VMXNET3、NSXバージョン、TNP、maintenance mode、測定基準を確認してから進めるべきです。
公式ブログの性能例は、導入判断のきっかけとして有用です。ただし、1518-byte framesの34Gbpsから64Gbps、最大28コアから16コア、observability低下as low as 18.4%という数字は、自社環境の保証値ではありません。自社のワークロードで再測定して初めて、容量計画に使える材料になります。
採用してよいケース
EDP Standardを前向きに評価してよいのは、VMXNET3の棚卸しが終わっており、NSXの採用バージョンを説明でき、TNPの対象範囲が明確で、ホストをmaintenance modeへ入れる余力があり、切替前後の測定基準がそろっている場合です。
この条件がそろっていれば、EDP Standardはネットワーク性能だけでなく、CPU消費や観測機能の負荷を見直す良い機会になります。
評価基準
採用判断では、最大値より再現性を優先します。何度測っても同じ傾向が出るか、負荷が高い時間帯でもSLOを守れるか、運用チームが切替と戻しを説明できるかを見ます。
先に止まるケース
E1000が多く残っている、NSX修正レベルを説明できない、TNPの対象範囲が曖昧、maintenance modeに入れる余力がない、切替前の基準値がない場合は、EDP Standardの導入判断より棚卸しを優先します。
特に既存環境では、ネットワーク性能改善の話が、VMテンプレート更新、NSXパッチ、ホスト容量、運用手順の見直しへ広がることがあります。これは遠回りではなく、EDPを正しく評価するための前処理です。
注意点
EDP Standardを採用するかどうかは、公式ブログの数値を信じるかどうかではありません。自社環境で、性能、安定性、運用、戻し方を説明できるかどうかです。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, "Improving VMware Cloud Foundation Performance with Enhanced Data Path (EDP)", 2026年6月9日。確認日: 2026年6月11日。https://blogs.vmware.com/cloud-foundation/2026/06/09/improving-vmware-cloud-foundation-performance-with-enhanced-data-path-edp/
- Broadcom TechDocs, "Enhanced Data Path", VMware Cloud Foundation 9.0/9.1 documentation。確認日: 2026年6月11日。https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/advanced-network-management/administration-guide/transport-zones-and-transport-nodes/enhanced-datapath-1.html
- Broadcom TechDocs, "VMware NSX 4.2.4 Release Notes"。確認日: 2026年6月11日。https://techdocs.broadcom.com/us/en/vmware-cis/nsx/vmware-nsx/4-2/release-notes/vmware-nsx-424-release-notes.html
- Broadcom TechDocs, "VMware Cloud Foundation 9.1 Release Notes – NSX What's New"。確認日: 2026年6月11日。https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/release-notes/vmware-cloud-foundation-9-1-0-0-release-notes/what-s-new/whats-new-nsx.html
- Daily VCF, VMware Cloud Foundation News Aggregator。需要シグナルとして確認。確認日: 2026年6月11日。https://dailyvcf.com/