3行まとめ：vSANネットワークは10GbE、VMkernel、MTUを別々に合格させない
all-flash clusterでは10GbE NICを前提に、専用性、冗長性、共有時の制御まで確認する。
vSAN traffic用VMkernel port、VLAN、subnetを全ホストで同じ設計として確認する。
MTUは設定画面だけで判断せず、全ホスト間のvmkpingで実際の疎通を確認する。
vSANは分散ストレージのため、1ホストだけの差分やfailover後の経路差が運用リスクになります。
VCF 9.1でvSANを使うなら、まず見るべきは「vSANが有効か」ではなく、vSAN trafficを載せる物理NIC、VMkernel、VLAN、MTU、subnetがクラスタ全体でそろっているかです。 Broadcom TechDocsのvSAN network checklistは、all-flash clusterで10GbE NICが必要になること、VMkernel port、VLAN/MTU/subnet、vmkping、物理スイッチ、iperfなどを確認項目として挙げています。 NIC teamingやNetwork I/O Controlは性能改善の飾りではなく、障害時、メンテナンス時、vMotionやVM trafficと重なる時間帯に、vSAN trafficをどう守るかを決める設計項目です。
VCF 9.1のvSANまわりでは、Storage Policy、snapshot、replication、VCF Operations監視など、機能面の話題が目立ちます。ただし、vSANは分散ストレージです。VMやコンテナのデータが複数ホストにまたがって動く以上、ネットワークが片ホストだけずれている、jumbo frameが一部経路で落ちる、failover後のuplinkだけMTUが違う、といった小さな差がそのまま運用リスクになります。
今回このテーマを選んだ理由は、Broadcom TechDocsのVCF 9.1 vSAN network design/checklistページ群が2026年6月15日更新として確認でき、2026年6月12日のVMware Cloud Foundation BlogでもvSANの運用、Health、Capacity、Performance確認が改めて取り上げられているためです。直近のBroadcom Watch Japanでは、VCF 9.1のvSANストレージ設計やVCF 9.1 Protection and Recoveryを扱いました。この記事ではそこから話を広げず、vSAN network designだけに絞ります。
確認日は2026年6月16日です。Broadcom Watch JapanはBroadcomおよびVMware by Broadcomとは非提携の情報整理サイトであり、本文は公式ドキュメント確認の入口として使う前提です。実環境の構成変更、サポート判断、障害対応は、契約しているサポート窓口と自社の変更管理に合わせて確認してください。
まず10GbEを「足りるか」ではなく「何を載せるか」で見る
- 1vSAN専用か共有か
vSAN trafficを専用リンクに載せるのか、vMotionやManagement、VM trafficと共有するのかを決める。
- 2ピーク時の重なり
host evacuation、vSAN resync、backup、監視trafficが同じ時間帯に重なる前提で見る。
- 3障害時の片系運用
片方のuplinkやswitch経路に切り替わった時も、vSAN trafficが流せるかを確認する。
- 4共有時の制御
共有リンクを使うなら、Network I/O Controlでどのtrafficを守るかを設計に入れる。
10GbEは確認の入口であり、専用性、冗長性、共有時の制御、再同期時の余裕まで見て判断します。
vSANネットワークの話は、どうしても「10GbEで足りるか」という問いに寄りがちです。しかし設計前に必要なのは、帯域の数字を単独で見ることではありません。どのtrafficを同じ物理NICに載せるのか、ホスト退避や再同期の時間帯に何が重なるのか、障害時に片系だけで流せるのかを先に分ける必要があります。
Broadcom TechDocsのChecklist Summary for vSAN Networkは、shared 10GbE NICかdedicated 1GbE NICかを確認し、all-flash clusterでは10GbE NICが必要になると示しています。ここでの実務ポイントは、10GbEという数字を「設計終了」の印にしないことです。10GbEは確認の入口であり、vSAN trafficの専用性、冗長性、共有時の制御、再同期時の余裕まで見て初めて判断材料になります。
vSAN trafficをどのリンクに載せるかを先に決める
vSAN traffic専用の物理NICを用意する設計では、確認の中心は物理冗長化とswitch pathになります。どちらのToRに接続しているか、片系障害時に同じVLAN/MTU/subnetで到達できるか、standby側のportにも同じ設定が入っているかを見ます。
一方で、vMotion、Management、VM traffic、NSX関連trafficと同じ物理NICを共有する設計では、平均帯域だけでは足りません。vMotionが走る時間帯、host evacuation、vSAN resync、バックアップ、監視trafficが重なった時に、vSAN trafficがどの優先度で扱われるかを決める必要があります。このときNetwork I/O Controlは、後から思い出す性能チューニングではなく、共有リンクを採用する時点での設計条件になります。
確認項目
| 観点 | 先に決めること | 合格にしない状態 |
|---|---|---|
| 物理NIC | vSAN専用か共有か | 余ったuplinkに載せるだけ |
| 帯域 | 平常時と再同期時の想定 | 平均利用率だけで判断 |
| 冗長化 | active/standby、active/active、LACPのどれか | vSphere側だけ設定済み |
| 共有traffic | vMotion、Management、VM、NSX、backupとの関係 | 混雑時の優先順位が未定 |
| 監視 | vSAN Health、performance、VCF Operationsで見る指標 | 設定後に見る場所が未定 |
all-flashや高密度構成では「最低ライン」と「本番余裕」を分ける
all-flash clusterでは10GbE NICが要求されるという公式チェック項目があります。ただし、10GbEが要求されることと、すべての本番環境で余裕があることは別です。ホスト密度が高い、キャッシュ/容量デバイスが多い、メンテナンス中に再同期が増える、将来vSAN ESAやより重いワークロードを見込む、といった条件では、最低ラインと本番余裕を分けて評価する必要があります。
ここで避けたいのは、PoCで小さな負荷を通した結果を、そのまま本番保証にしてしまうことです。vSAN networkは、平常時よりも障害時、退避時、再同期時に設計の癖が出ます。検証では、通常運用だけでなく、ホスト1台のメンテナンス、リンク片系停止、再同期発生時のtraffic、vMotionとの重なりを少なくとも確認対象に入れておきます。
注意点
10GbE、25GbE、100GbEのようなNIC速度の選定は、公式チェックリストだけで一律に決まりません。サーバー構成、vSANの種類、ワークロード、サポートされるハードウェア、スイッチ設計、将来拡張によって変わります。本文では10GbEを入口として扱い、上位帯域や専用ファブリックの要否は自社環境で検証すべき条件として残します。
VMkernelはホストごとの設定ではなくクラスタ整合性で確認する
vCenter上でvSANが有効に見えても、VLAN、subnet、MTU、物理経路がずれていれば確認は終わりません。
vSAN networkで次に見るべきなのは、各ホストのvSAN用VMkernel portです。Broadcom TechDocsのチェックリストは、vSAN network traffic用のVMkernel portが各ホストに設定されていること、全interfaceでVLAN、MTU、subnetが同一であることを確認項目にしています。
ここでの落とし穴は、1台ずつ見れば正しそうに見える設定が、クラスタ全体で見るとそろっていないことです。たとえば、あるホストだけVLAN IDが違う、port group名は同じだがuplinkの物理経路が違う、standby uplink側だけMTUが小さい、vSAN serviceが別のvmkに残っている、といった状態です。
vSAN用VMkernel portを全ホストでそろえる
確認は、vCenterの画面で「vSANが有効」と見えるところで止めません。ホストごとに、どのVMkernel adapterがvSAN trafficを担っているのか、同じdistributed port groupに乗っているのか、VLAN、subnet、MTU、uplinkの意図がそろっているのかを表にします。
確認項目
| 確認軸 | 見る内容 | ずれた時の影響 |
|---|---|---|
| VMkernel adapter | vSAN serviceが有効なvmk | trafficが想定外の経路に出る |
| VLAN | vSAN用VLAN IDとtrunk許可 | 特定ホストだけ通信不可 |
| subnet | 全ホストのvSAN vmk IP範囲 | vmkpingやHealth checkの失敗 |
| MTU | VMkernel、port group、vDS、物理switch | jumbo frameの片落ち |
| uplink | active/standby、LAG、物理port | failover後だけ通信不可 |
| 命名 | port group名、運用台帳、host profile | 設定差分の見落とし |
VLAN、subnet、MTUは「同じに見える」を信用しすぎない
VLAN、subnet、MTUは、管理画面上では整って見えても、物理switch側のtrunk、inter-switch link、LAG、standby側portでずれることがあります。vSAN networkはクラスタ内の全ホスト間通信が前提なので、1対1の疎通確認だけでは不十分です。
たとえば4ホスト構成なら、少なくとも各ホストのvSAN VMkernelから他ホストのvSAN VMkernelへ通信できることを確認します。jumbo frameを採用するなら、通常の小さいpingではなく、想定するpacket sizeで通るかを確認します。Broadcom TechDocsのチェックリストも、jumbo framesを使う場合は9000 packet sizeでvmkpingが全ホスト間で成功することを確認するよう促しています。
評価基準
合格にできるのは、設定値がそろっている状態ではなく、vSAN trafficを担うVMkernelから、想定するVLAN/subnet/MTUで全ホスト間の到達性を確認できた状態です。設定値のスクリーンショットと疎通結果を別々に保存しておくと、後で障害が起きた時に「いつからずれていたか」を追いやすくなります。
vMotionやManagement VMkernelと混同しない
VCF環境では、Management、vMotion、vSAN、NSX、backupなど複数のtrafficが同じvDS上に並ぶことがあります。VMkernel adapterが複数ある場合、どのvmkがvSAN trafficを担当しているのかを明示しないと、vmkpingの確認も監視の読み方も曖昧になります。
特に、vMotion用VMkernelで疎通確認してしまい、vSAN用VMkernelの経路を確認したつもりになる事故は避けたいところです。runbookには、port group名だけでなく、vmk番号、IP、VLAN、MTU、対象host pair、実行した確認内容を残します。
MTUは設定値ではなくvmkpingで経路を確認する
- 1仮想switch
vDSまたはstandard switchのMTUが意図した値になっているかを確認する。
- 2VMkernel adapter
vSAN用VMkernel adapterのMTUが意図した値になっているかを確認する。
- 3Port groupとVLAN trunk
distributed port groupやVLAN trunkの設定が全ホストでそろっているかを確認する。
- 4物理switch経路
ToR、inter-switch link、LAGを含む経路で同じMTU方針になっているかを確認する。
- 5vmkping
全ホスト間でvmkpingを実行し、jumbo frames利用時は9000 packet sizeで確認する。
MTUは設定画面の値だけで合格にせず、実際にvSAN trafficが通る経路で疎通を確認します。
jumbo frameは、端点だけ9000にしても成立しません。VMkernel、port group、vDS、物理NIC、ToR、inter-switch link、LAG、VLAN trunkまで、経路全体で同じ方針になっている必要があります。設定画面のMTUだけを見て合格にすると、実際には途中の物理switchで落ちているケースを見逃します。
Broadcom TechDocsのChecklist Summaryは、VLAN、MTU、subnetが全interfaceで同一であること、全ホスト間でvmkpingを実行できること、jumbo frames利用時は9000 packet sizeでvmkpingできることを確認項目にしています。この記事ではコマンドの細かいオプションを固定しません。VCF 9.1の公式ドキュメント、利用中のESX/ESXiバージョン、自社runbookで、source VMkernel指定、packet size、do-not-fragment相当の扱いを確認してから実行してください。
jumbo frameは端点だけそろえても足りない
MTU確認は、次の順に切り分けると見落としが減ります。
- vDSまたはstandard switchのMTUが意図した値か。
- vSAN用VMkernel adapterのMTUが意図した値か。
- distributed port groupやVLAN trunkの設定が全ホストでそろっているか。
- active uplinkだけでなく、standby/failover後のuplinkでも同じMTUが通るか。
- ToR間、LAG、inter-switch linkをまたぐ経路でpacketが落ちないか。
- 全host pairで、vSAN VMkernelをsourceにしたvmkpingが成功するか。
- vSAN Healthでネットワーク関連の警告が残っていないか。
この順番にすると、vSphere側の設定ミスと物理switch側の設定漏れを分けやすくなります。vCenterで見える設定値だけをそろえるのではなく、実際の経路で確認するのが要点です。
失敗した時はvSphere側と物理側を分けて切り分ける
vmkpingが失敗した時、すぐにvSANそのものの問題として扱うと遠回りになります。まずは経路を分解します。
| 症状 | まず見る場所 | よくある確認漏れ |
|---|---|---|
| 小さいpingは通るがjumboだけ落ちる | MTU、physical switch、inter-switch link | 片方のToRだけMTU未設定 |
| 特定host pairだけ失敗する | VLAN trunk、uplink、port group | 1ホストだけVLAN許可漏れ |
| active uplinkでは通るがfailover後に落ちる | standby uplink、switch port | standby側portのMTU/VLAN差分 |
| vmkpingのsourceが意図と違う | VMkernel adapter、routing | vMotion vmkで確認していた |
| Health checkだけ警告が残る | vSAN Health、DNS、遅延、packet loss | 一時的疎通だけで合格にした |
下振れ要因
片方向だけ通る、特定の時間帯だけ遅い、メンテナンス時だけ落ちる、host evacuation中だけ遅延が伸びる。こうした状態は、設定値だけでは見つかりません。変更前にベースラインを取り、変更後も一定期間はvSAN Health、performance、物理switchのerror counterを見ます。
NIC teamingと物理スイッチは片側だけで設計しない
挙動は読みやすいが、standby側のswitch portにも同じVLAN、MTU、flow control方針が必要になる。
vSphere側だけで選ばず、物理switch側の理解、設定、運用体制と合わせて判断する。
Advanced NIC Teamingでは、複数VMkernel adapterやdedicated subnetの条件を確認する。
通常時の負荷分散だけでなく、uplinkやswitch障害後にどの経路へ切り替わるかを見る。
単純で信頼できる構成にするか、高度なteamingで経路を分けるかは、障害時の動きで判断します。
vSANのNIC teamingは、vSphere側のpolicy名を選んで終わりではありません。Broadcom TechDocsのBasic NIC Teamingページは、vSANのようなIP storageではネットワーク冗長性の実装がbest practiceであり、複数NICをteamとして構成して高可用性とload balancingを実現できると説明しています。同時に、確信がない場合はActive/Standby構成とexplicit failoverを使う選択肢も示しています。
この記述は、複雑なteamingを否定するものではありません。ただし、LACPやIP hashなど物理switch側の理解と設定が必要な方法を、vSphere側だけで選ぶのは危険です。単純で信頼できる構成にするのか、高度なteamingで経路を分けるのかを、障害時の動きで判断します。
Basic NIC Teamingは障害時の経路で見る
Active/Standbyの良さは、通常時の挙動が読みやすいことです。active uplinkが落ちたらstandby uplinkに切り替える。設計としては単純ですが、standby側の物理switch portに同じVLAN、MTU、flow control方針が入っていなければ、障害時に初めて壊れます。
確認項目
| vSphere側 | 物理側 | 失敗しやすい点 |
|---|---|---|
| active/standby uplink | それぞれのswitch port | standby側のVLAN/MTU漏れ |
| failback | 復旧後の経路戻り | 復旧直後のpacket loss |
| network failure detection | link state / beacon probingなど | 上位経路障害を検知できない |
| notify switches | MAC学習の更新 | 切替直後の到達性遅延 |
| load balancing policy | switch側の期待値 | vSphere側と物理側の前提不一致 |
Advanced NIC TeamingはLACPとsubnet条件を確認する
Broadcom TechDocsのAdvanced NIC Teamingページは、複数のVMkernel adapterと2つのdedicated subnetを使ってvSAN networkを構成できること、LAG/LACPを使う場合はsingle VMkernel adapterで構成できることを説明しています。また、vSphereとvSANは同じsubnet上の複数VMkernel adapterをサポートしない、という注意もあります。
この点は実務上かなり重要です。「vmkを2つ作れば冗長化できる」と単純に考えると、同一subnetに複数vmknicを置くような構成に寄ってしまいます。複数VMkernel adapterを使うなら、別subnet、別VLAN、別physical fabricのように、経路をどう分けるかを設計します。LACPを使うなら、vSphere側のLAG、物理switch側のport channel、hash policy、VLAN trunk、MTUを同じ図で確認します。
注意点
LACPは「束ねた分だけvSANが単純に速くなる」機能ではありません。trafficの流れ方、flow単位の分散、host間通信の偏り、障害時の再収束、物理switchの設定品質によって結果は変わります。高度なteamingを使う場合ほど、設定前の設計図と設定後の実測が必要になります。
物理スイッチはvSAN設計の外側ではない
Broadcom TechDocsのチェックリストは、物理スイッチがvSAN requirementsを満たすこと、flow controlやfeature interoperabilityを確認すること、dropped packetsやpause framesのような性能問題がないことも確認対象にしています。つまり、vSAN network designはvSphere管理者だけで閉じる話ではありません。
物理switch側では、ToR冗長、VLAN許可、MTU、LACP、spanning tree、buffer、link speed、duplex、error counter、dropped packet、pause frame、firmware、inter-switch linkを確認します。vCenter上のhost networkingが正常に見えても、物理switchでerror counterが増えているなら、設計確認は終わっていません。
Network I/O Controlは共有リンクの保険として先に設計する
vSAN、vMotion、Management、VM traffic、backup、NSX/Edge関連trafficの共有条件を決める。
競合時にvSAN trafficをどの優先度で扱うかを、運用ピークを前提に設計する。
安易に固定せず、環境、ワークロード、サポート方針に合わせて許容可否を確認する。
VCF OperationsやvSAN Healthで、変更後のHealth、Capacity、Performanceを確認する。
専用NICでは役割が限定的になる場合があり、共有NICではメンテナンス時のtraffic集中まで含めて設計します。
Network I/O Controlは、vSphere Distributed Switchでnetwork trafficにQoSレベルを設定する機能です。Broadcom TechDocsは、vSAN trafficがvMotion、management、VM trafficなどと物理NICを共有する場合に有用だと説明しています。
ここで大事なのは、NIOCを「入れれば速くなる機能」と見ないことです。NIOCは、共有リンクでtraffic同士が競合した時に、どのtrafficを守り、どのtrafficを遅らせてもよいかを決めるための設計項目です。
vSAN trafficを他のtrafficと共有する条件を決める
専用NICでvSAN trafficを流すなら、NIOCの役割は限定的になる場合があります。共有NICでvSAN、vMotion、Management、VM traffic、backup、NSX/Edge関連trafficを扱うなら、NIOCのshares、reservation、limitをどう扱うかを先に決めます。
特に、メンテナンス時はtrafficが重なりやすくなります。vMotion、host evacuation、vSAN resync、バックアップ、監視のピークが同じ時間帯に来るなら、平常時の帯域だけを見ても意味が薄くなります。
reservationは安易に推奨しない
Broadcom TechDocsは、NIOCのreservationでvSANに最小帯域を保証できる一方、未使用のreservation帯域をVM trafficに割り当てられないこと、system traffic types全体のreserved bandwidthは最も低いcapacityの物理network adapterが提供するbandwidthの75%を超えられないことを説明しています。また、vSAN best practicesとして、vSAN環境ではNIOC reservationsを避ける旨も示しています。
そのため、この記事では「vSANにreservationを入れれば安心」とは書きません。まずsharesと混雑時の優先順位を設計し、reservationを検討する場合は、未使用帯域、他trafficへの影響、物理NICの最小capacity、サポート方針、自社の運用基準を確認します。
評価基準
| 項目 | 見ること | 判断の向き |
|---|---|---|
| shares | 混雑時の相対優先度 | vSANを守る意図が明確か |
| reservation | 最小帯域保証と未使用帯域 | 安易に使わず条件付きで検討 |
| limit | 上限設定の必要性 | vSANを絞っていないか |
| traffic重なり | vMotion、resync、backup、VM traffic | ピーク時の挙動を検証 |
| 観測 | vSAN Health、performance、VCF Operations | 変更後に異常を拾えるか |
VCF OperationsとvSAN Healthで変更後を観測する
VMware Cloud Foundation BlogのModernize with Virtualized Storageは、vSANのHealth、Capacity、Performanceを確認する組み込みツールやVCF Operations dashboardsに触れています。ネットワーク設計の記事であっても、この観測導線は重要です。
NIOC、NIC teaming、MTU、物理switchの変更後は、設定が通ったかだけでなく、vSAN Health、network performance、resync traffic、latency、throughput、host NIC error、packet loss、VCF Operationsのアラートを見ます。特に、メンテナンス直後とピーク時間帯で観測する項目を分けておくと、平常時だけ問題ない状態を見抜きやすくなります。
導入前チェックリストで「設定したつもり」を止める
公式情報は設計確認の入口です。個別環境の判断はCompatibility Guide、ハードウェア情報、最新TechDocs、サポート窓口で確認します。
最後に、設計前レビューで止めるためのチェックリストに落とします。この表は、作業後の合否判定ではなく、作業に入る前の確認漏れを減らすためのものです。
帯域とVMkernelのチェック
| 分類 | 確認すること |
|---|---|
| 帯域 | all-flash clusterの10GbE要件、専用/共有、再同期、退避、将来拡張を分けて見る |
| 物理NIC | active/standby、active/active、LACP、link speed、duplex、error counterを確認する |
| VMkernel | 全ホストでvSAN service、vmk、IP、VLAN、subnet、MTU、port groupをそろえる |
| traffic分離 | vMotion、Management、VM、backup、NSX関連trafficと混同しない |
MTUと物理switchのチェック
| 分類 | 確認すること |
|---|---|
| MTU | VMkernel、port group、vDS、物理switch、inter-switch linkを同じ方針で確認する |
| vmkping | source VMkernelを指定し、全host pairで想定packet sizeの到達性を確認する |
| 物理switch | VLAN trunk、LACP、flow control、pause frames、dropped packets、bufferを確認する |
| failover | active uplinkだけでなくstandby/failover後の経路でも確認する |
NIOCと運用監視のチェック
| 分類 | 確認すること |
|---|---|
| NIOC | 共有NICで使うtraffic class、shares、reservation、limitの方針を決める |
| reservation | vSAN環境では安易に使わず、未使用帯域と75%上限を確認する |
| 観測 | vSAN Health、performance、VCF Operations、物理switch counterを見る |
| 変更管理 | 変更前ベースライン、変更後観測期間、戻し方、サポート確認を残す |
未確認として残すべきこと
公式ページで確認できるのは、設計上の確認項目と一般的なベストプラクティスです。個別環境で何GbEが十分か、どのswitch構成が最適か、NIOC reservationを許容するか、LACPを使うべきかは、サーバー、NIC、switch、vSAN構成、ワークロード、サポート契約によって変わります。
この記事で断定しないものは、性能値、容量削減率、障害時の復旧時間、ベンダー別switch推奨、すべての環境に共通するNIC速度です。導入前にはBroadcom Compatibility Guide、該当ハードウェアのサポート情報、最新TechDocs、サポート窓口の見解を確認してください。
更新履歴・運用メモ
- 2026年6月16日確認。Broadcom TechDocsのVCF 9.1 vSAN Network Design、Checklist Summary、NIC Teaming、Advanced NIC Teaming、Network I/O Control、VMware Cloud Foundation Blog「Modernize with Virtualized Storage」を参照した。
- 2026年6月15日更新として確認できるTechDocsページ群を需要シグナルにした。本文では検索スニペットではなく、取得できた公式ページ本文の確認項目を優先した。
- Broadcomの公式発表、VCF 9.1、vSAN、NSX、Tanzu、セキュリティ製品の更新を継続して追う場合は、記事を読み終えた後にニュースレターを補助導線として使える。売買推奨や投資助言ではない。
次に読むなら
参照した主な情報源
- Broadcom TechDocs, Designing vSAN Network, VMware Cloud Foundation 9.1
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/vsan-deployment-administration-and-monitoring/vsan-network-design.html
- Broadcom TechDocs, Checklist Summary for vSAN Network, VMware Cloud Foundation 9.1
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/vsan-deployment-administration-and-monitoring/vsan-network-design/checklist-summary-for-vsan-network.html
- Broadcom TechDocs, Basic NIC Teaming, Failover, and Load Balancing, VMware Cloud Foundation 9.1
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/vsan-deployment-administration-and-monitoring/vsan-network-design/nic-teaming-failover-and-load-balancing.html
- Broadcom TechDocs, Advanced NIC Teaming, VMware Cloud Foundation 9.1
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/vsan-deployment-administration-and-monitoring/vsan-network-design/advanced-nic-teaming.html
- Broadcom TechDocs, Network I/O Control, VMware Cloud Foundation 9.1
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/vsan-deployment-administration-and-monitoring/vsan-network-design/network-i-o-control.html
- VMware Cloud Foundation Blog, Modernize with Virtualized Storage, 2026年6月12日
https://blogs.vmware.com/cloud-foundation/2026/06/12/modernize-with-virtualized-storage/