3行まとめ
このテーマをもう少し広げて見るなら、VCF 5.2.xから9.1へ移行前に確認する：8ステップ順序、VCF Management Services、NSX経路の実務ポイント と VCF Operationsでオンプレ本番運用を見直す：88.8%調査、Day 2、容量・コスト可視化の実務ポイント も合わせて確認してください。vCenter Linkingの前提になるVCF 5.2.xから9.1への移行順序、管理サービス、NSX経路を先に確認できるため。
共有SSOドメインとレプリケーション中心の発想から、VCF Operationsを中心にした管理体験へ読み替えます。
どのvCenterを同じグループで見せるか、誰がVCF SSOでログインするか、共通IdPをどう使うかを先に決めます。
対象vCenterの版数、ELM残存、VCF Operationsログ、Broadcom KBを導入前チェックに入れます。
機能紹介だけでなく、認証、グループ設計、失敗時の確認先を同じ計画に入れることが重要です。
- VCF 9.xのvCenter Linkingは、複数vCenterを従来のEnhanced Linked Modeだけで束ねる発想から離れ、VCF Operations、VCF SSO、共通IdP、vCenter Groupを前提に管理体験を組み直す機能として読む必要があります。
- 2026年6月2日のVMware Cloud Foundation公式ブログでは、VCF Operationsを中央の管理プレーンに置き、vCenter Linking Plugin、Adapters、各vCenterのSync Frameworkを使う構成が説明されています。
- 導入前に見るべき実務ポイントは、対象vCenterがvCenter 9.0以降か、ELMが残っていないか、VCF SSOでログインしているか、失敗時にVCF Operations側のログとBroadcom KBへ戻れるかです。
VMware Cloud Foundation Blogで、2026年6月2日に「vCenter Management Evolved: New vCenter Linking in VMware Cloud Foundation 9.x」が公開されました。直近のVCF 9.1周辺では、アップグレード、VKS、PowerCLI、Express Patchなどの実務記事が続いていますが、このvCenter Linkingは「複数vCenterをどう見せ、どう認証し、どう運用するか」という管理体験そのものに関わります。
この記事では、VCF 9.x環境でvCenter Linkingを使う前に、導入企業、運用担当、調査担当が確認したい点を整理します。作業手順書ではありません。ELM解除、DomainGUID、LDAP変更、復旧作業の判断は影響が大きいため、実作業では必ずBroadcomの最新KB、TechDocs、サポート情報、社内の変更手順を確認してください。
Broadcom Watch JapanはBroadcomおよび関係会社とは非提携です。この記事は製品・サービス情報の整理であり、投資助言や個別環境への導入指示ではありません。
ELMからvCenter Linkingへ、何が変わるのか
単純な優劣ではなく、ELM前提の運用からVCF Operations中心の運用へ責任範囲を読み替えるための比較です。
vCenter Linkingを「ELMの新しい名前」とだけ読むと、導入前の確認を誤りやすくなります。公式ブログが示している変化は、単に複数vCenterをひとつのvSphere Client画面に出すことではありません。VCF 9.xでは、複数vCenter管理の制御点がVCF Operations側へ寄り、認証もVCF SSOと外部IdPを含む設計で考えるようになります。
ELMは共有SSOドメインとレプリケーションを前提にしていた
根拠
Enhanced Linked Modeは、複数のvCenter Serverを同じvSphere Clientビューで扱うために長く使われてきた仕組みです。公式ブログでは、ELMが共有SSOドメインとバックエンドのレプリケーションに依存し、規模が大きくなるほどDay 2運用で負荷になりやすい点が説明されています。
とくに運用上の論点は、リンクされたvCenter同士の状態をそろえ続けることです。バージョン、バックアップ、復元、スナップショット、更新作業をばらばらに扱うと、レプリケーションの整合性が崩れる可能性があります。単体のvCenterを戻すつもりが、SSOドメイン全体の状態に影響する。この緊張感がELM運用の難しさです。
注意点
ここで大事なのは、ELMを一括りに否定しないことです。既存環境では、ELMが長く実運用を支えてきたケースもあります。ただし、VCF 9.xでvCenter Linkingへ進むなら、過去のELM構成がそのまま残っていないかを確認する必要があります。新しい仕組みに移る前の「残存状態」が、失敗時の原因になり得るからです。
VCF 9.xはVCF Operationsを中心に集約する
根拠
2026年6月2日の公式ブログは、VCF 9.xのvCenter Linkingについて、VCF Operationsを中央管理プレーンとして位置づけています。共通IdPと連携し、API駆動で複数vCenterのビューを集約する設計です。ELMのようにバックエンドのデータベースレプリケーションを主軸にして複数vCenterを束ねるのではなく、より分離された構成で一元的な管理体験を作る方向に変わります。
条件
公式ブログでは、vCenter Linkingが同一ビルドであることを絶対条件にしない柔軟性にも触れています。ただし、これを「どんなvCenterでも自由に混ぜられる」と読んではいけません。主要な前提として、対象vCenterはvCenter 9.0以降であることが示されています。導入前の台帳では、対象vCenterごとにバージョン、パッチ状態、VCF Operationsへの登録状態、既存ELMの有無を分けて残すべきです。
VCF 9.1全体のアップグレードや管理サービスの観点は、以前まとめた<a href="https://avgo-watch.blog.mo-gmo.com/avgo-13-vcf-91-upgrade-api-ip-check/" target="_blank" rel="noopener">VCF 9.1導入前チェックの記事</a>も補助になります。この記事ではそこから一段絞り、複数vCenter管理とSSOの見え方に集中します。
変更点は機能名ではなく運用責任で読む
確認項目
導入判断では、「ELMがなくなる」「vCenter Linkingになる」という機能名だけで説明しないほうが安全です。社内の変更審査では、次のように責任範囲を分けると説明しやすくなります。
| 見る項目 | ELMで意識しやすい点 | vCenter Linkingで先に見る点 |
|---|---|---|
| 複数vCenterの見え方 | 共有SSOドメイン内の統合表示 | VCF Operationsで作るvCenter Group |
| 認証 | vSphere SSO中心 | VCF SSOと共通IdP |
| ライフサイクル | リンク全体の整合性に注意 | vCenterごとの独立性とVCF Operations側の制御点 |
| バックアップ/復元 | レプリケーション整合性に注意 | 失敗時のログ、KB、ELM残存確認 |
| 導入前チェック | バージョンとSSOドメイン | vCenter 9.0以降、IdP、ELM解除、DomainGUID |
この表は優劣の比較ではなく、確認軸の違いです。VCF 9.xへ移るなら、複数vCenter管理の責任範囲がVCF Operations、IdP、vCenter Group、ログ運用へ広がると見ておく必要があります。
vCenter Group、VCF SSO、共通IdPを先に確認する
- 1共通IdP
OIDCやSAML、対象ユーザー、権限範囲を決め、共通の認証元として設計します。
- 2VCF SSO
複数vCenter表示に使う認証経路を明確にし、ローカルアカウントでの見え方と混同しないようにします。
- 3VCF Operations
Infrastructure OperationsのConfigurations配下でvCenter Linkingを扱い、vCenter Group作成の操作点になります。
- 4vCenter Group
対象vCenter、FQDN、バージョン、管理ドメイン、用途、命名ルールを台帳化します。
- 5各vCenter
リンク後も、操作時に対象vCenterを選ぶ場面が残る前提で運用手順を整えます。
期待したvCenterが見えない場合は、リンク失敗だけでなく、VCF SSO、共通IdP、ローカルアカウントの差も切り分けます。
vCenter Linkingの導入で最初に決めるべきものは、画面操作の順番ではありません。どのvCenterを同じグループで見せるのか、誰がVCF SSOでログインするのか、どのIdPを共通の認証元にするのかです。ここが曖昧だと、リンクが成功しても「期待したvCenterが見えない」「権限が足りない」「ローカルアカウントでは見え方が違う」という混乱が残ります。
vCenter GroupはVCF Operationsで作る
根拠
2025年6月19日の公式ブログでは、VCF Operations 9のInfrastructure Operations、Configurations配下にあるvCenter LinkingからvCenter Groupを作り、対象vCenterを選ぶ流れが紹介されています。つまり、vCenter LinkingはvCenter単体の隠し設定ではなく、VCF Operations上でグループとして扱う機能です。
確認項目
導入前には、次のような台帳を用意しておくと判断しやすくなります。
| 確認するもの | 見る理由 | メモに残す内容 |
|---|---|---|
| 対象vCenter | どのvCenterを同じ画面で扱うか決める | FQDN、バージョン、管理ドメイン/ワークロードドメイン |
| VCF Operations | vCenter Group作成の操作点になる | 版数、管理対象、ログ取得担当 |
| 管理者権限 | グループ作成と確認に必要 | 作業者、承認者、権限範囲 |
| グループ名 | 運用チームが識別しやすくする | 命名ルール、対象拠点、用途 |
| 利用者 | 誰が複数vCenter表示を使うか決める | 運用、監視、調査、変更担当 |
vCenter Groupは、便利な表示機能であると同時に、運用チームの境界を表します。拠点、事業部、管理ドメイン、ワークロードドメインを無理にひとつにまとめると、見える範囲は広がっても、操作対象の取り違えが起きやすくなります。
共通IdPとVCF SSOで見える範囲を整理する
根拠
2026年6月2日の公式ブログでは、VCF 9がOIDCやSAMLに対応する外部IdP、たとえばOkta、Ping Identity、Microsoft Entra IDなどと連携し、共通の認証元を使って複数環境へのアクセスを統一する設計が説明されています。これは、vCenter Linkingを単なる画面統合ではなく、ID管理の設計として扱うべき理由です。
公式ブログの2025年記事も重要な注意点を示しています。リンクが確立されたあと、複数環境をひとつのvSphere Clientで見るにはVCF SSOでサインインする必要があります。一方、administrator@vsphere.localのようなローカルアカウントでログインした場合は、その特定システムのインベントリだけが見えると説明されています。
注意点
この違いは、障害ではなく仕様上の見え方です。複数vCenterが見えないとき、すぐにリンク失敗と判断する前に、ログインに使ったアカウント、IdP、グループ権限、対象vCenter側の権限を確認する必要があります。
操作時に対象vCenterを選ぶ場面を残す
評価基準
複数vCenterが同じ画面に見えることと、すべての操作が全体に一括で実行されることは別です。2025年の公式ブログでも、リンクされた複数vSphere環境では、操作によって特定のvCenter Serverを選ぶ場面があると説明されています。
運用手順では、次のような線引きを残すと安全です。
| 場面 | 確認すること |
|---|---|
| インベントリ確認 | どのvCenter配下のVM、クラスタ、ホストかを明示する |
| 権限確認 | VCF SSOのユーザー/グループが各vCenterで何を操作できるかを見る |
| 変更作業 | 作業対象のvCenterを手順書内で明記する |
| 障害調査 | 画面表示、VCF Operationsログ、対象vCenter側ログを分けて見る |
| 監査 | 誰がどの認証経路で、どのvCenterを操作したかを記録する |
リンク後の画面が便利になるほど、作業対象の取り違えを防ぐ工夫が必要です。複数vCenterを見られるようにすること自体をゴールにせず、「誰が、どの認証で、どのvCenterに対して、どの操作をするか」まで決めておきましょう。
アーキテクチャはPlugin、Adapters、Sync Frameworkで読む
- 1VCF Ops Console
vCenter Groupを有効化するワークフローの開始点になります。
- 2vCenter Linking Plugin
グループの中核ロジックを持ち、同期データやメタデータを管理します。
- 3Central DB
設定や共有データをVCF Operations appliance内に保持する構成として説明されています。
- 4Adapters
VCF Operationsと対象vCenterの通信を担い、Adapter側の例外確認にも関わります。
- 5VC Linking Sync Framework
各vCenter側で、信頼確立や同期処理の裏側を支えます。
- 6ログ確認
vrops-vcenter-linking.logとManagementAdapter_xx.logを、切り分けの入口として準備します。
内部構造の暗記ではなく、信頼確立、同期、Adapter例外をどのログで追うかを決めるための整理です。
vCenter Linkingのアーキテクチャは、細部まで覚える必要はありません。ただし、障害時にどこを見るかを決めるために、VCF Operations側とvCenter側の役割は理解しておくほうが安全です。公式ブログは、VCF Ops Console、vCenter Linking Plugin、Adapters、vCenter側のVC Linking Sync Frameworkという流れで構成を説明しています。
VCF Operations側に設定と共有データが集まる
根拠
公式ブログによると、vCenter Groupを有効化するワークフローはVCF Ops Consoleから始まります。その下でvCenter Linking Pluginが中核のロジックを持ち、グループの同期データやメタデータを管理します。設定や共有データは、VCF Operations appliance内のCentral DBに保持される構成として説明されています。
注意点
本文でここまで触れる理由は、内部DBの構造を解説したいからではありません。導入前に「制御点はどこか」を把握するためです。vCenter Linkingで問題が起きたとき、vCenterだけを見ても全体像をつかめない場合があります。VCF Operations側でグループ設定、同期状態、ログを確認する前提を手順に入れておく必要があります。
AdaptersがvCenterとの通信を担う
根拠
公式ブログでは、Pluginが各vCenterへ直接通信するのではなく、AdaptersがSuite APIsやgRPCを使ってvCenter Serverとやり取りすると説明されています。Adaptersは、vCenterのidentity取得、trust確立、WatchとApplyの処理に関わります。
確認項目
この構成から、導入前の確認項目が見えてきます。
| 確認項目 | なぜ見るか |
|---|---|
| VCF Operations applianceから各vCenterへの到達性 | AdaptersがvCenterと通信できる必要がある |
| 証明書と名前解決 | trust確立やAPI通信で問題を起こしやすい |
| API/gRPC/HTTP2に関わる通信制御 | 通信経路で遮断されると同期に影響する |
| VCF Operations側のログ取得手順 | 失敗時にStateManagerやAdapterログを追う必要がある |
| 対象vCenter側の状態 | ELM残存、DomainGUID、SSO情報を確認する必要がある |
VCF Operationsで管理VMやNSX関連リソースを見る観点は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-15-vcf-operations-vcenter-nsx-resource-allocation/" target="_blank" rel="noopener">VCF Operationsで管理VMのリソース割り当てを確認する記事</a>でも扱っています。vCenter Linkingそのものとは別ですが、VCF Operationsを運用の中心に置くという意味では合わせて確認したい領域です。
信頼確立と同期は「画面表示」の裏側で動く
確認項目
公式ブログは、vCenter Groupを作ってリンクを有効にすると、対象vCenterの準備状態確認、SSO Domain IDやSTS情報の取得、trust確立、Watchによる変更取得、Applyによる反映という流れが走ると説明しています。表向きにはグループ作成の画面操作に見えても、裏側では認証情報、証明書、信頼関係、同期データが関わります。
そのため、導入前のチェックでは「vCenterが画面に出るか」だけでなく、次の順で確認すると実務的です。
- 対象vCenterがvCenter 9.0以降か。
- VCF Operationsから対象vCenterへ到達できるか。
- 共通IdPとVCF SSOの設計が決まっているか。
- 対象vCenterがELMに残っていないか。
- 対象vCenterごとのDomainGUIDが想定どおりか。
- 作業失敗時にVCF Operationsログを採取できるか。
この順番を飛ばして、リンク作成ウィザードだけで進めると、失敗したときに原因を切り分けにくくなります。
ELM残存とDomainGUIDは失敗前に見る
- 1vCenterが候補に出ない
有効なvCenterインスタンスがない旨のエラーや、グループ作成が進まない状態を出発点にします。
- 2ELM残存を疑う
対象vCenterがまだEnhanced Linked Modeの一部ではないか、解除が不完全ではないかを確認します。
- 3DomainGUIDを確認する
ELM解除後の残存要素として、DomainGUID重複が疑われるかを確認します。
- 4VCF Operationsログを見る
vrops-vcenter-linking.logでtrust確立やStateManagerのエラーを確認します。
- 5AdapterログとKBへ戻る
ManagementAdapter_xx.logとBroadcom KB 429352、431689を参照し、実行判断をサポートや社内手順と合わせます。
リンク作成時に初めて調べるのではなく、ELM解除履歴、DomainGUID、ログ取得手順を計画段階で確認します。
vCenter Linkingで困りやすいのは、「作れるはずのグループにvCenterが出ない」「リンク処理が進まない」「エラー文言だけでは原因が見えない」という場面です。Broadcom KB 429352と431689は、こうした失敗例を導入前チェックに変換するうえで有用です。
vCenterが候補に出ない場合の読み方
根拠
Broadcom KB 429352は、VCF OperationsでvCenter Linkingを作成しようとした際に、有効なvCenterインスタンスがない旨のエラーが出るケースを扱っています。KBのCauseでは、vCenterインスタンスがまだEnhanced Linked Modeの一部である、またはELMから適切に解除されておらず、残存構成がリンク処理を妨げる可能性が説明されています。対象環境はVCF 9.x、VCF Operations 9.xです。
確認項目
このKBから導入前に引ける教訓は明確です。リンク作成時に初めてELM残存を調べるのではなく、計画段階で「対象vCenterはELMから外れているか」「解除作業の履歴は残っているか」「各vCenterのDomainGUIDはどうなっているか」を確認しておくことです。
注意点
ただし、KB内のコマンドや解除手順をこの記事だけで実行しないでください。ELM解除やSSO関連の変更は影響が大きく、環境や手順の前提も変わり得ます。記事では確認観点までを示し、実作業は公式KBとサポート確認へ戻すのが安全です。
DomainGUID重複はELM解除後の残存要素として扱う
根拠
Broadcom KB 431689は、VCF 9.0.x、vCenter 9.0.x環境で、vCenter Linkingが失敗するケースを扱っています。Causeでは、9.0へ上げる前にELMを解除したものの、domainGUIDが更新されていない場合があると説明されています。また、複数vCenterで同じDomainGUIDが残っている状態も示されています。
確認項目
この問題は、導入前チェックとして非常に重要です。ELMを「解除済み」と台帳に書いていても、内部的な識別子が期待どおり変わっていない場合、vCenter Linkingでつまずく可能性があります。作業計画では、ELM解除の有無だけでなく、解除後に何を確認したかまで記録したほうがよいでしょう。
注意点
KB 431689のResolutionには、オフラインスナップショット、バックアップ、rootユーザーでのSSH、UUID生成、LDAP変更など、慎重に扱うべき作業が含まれます。ここは本文で簡略化して手順化しません。変更の影響が大きい領域なので、公式KBを確認し、必要に応じてBroadcomサポートや社内のVMware担当者と作業判断を合わせてください。
ログ位置を事前に運用手順へ入れる
確認項目
2026年6月2日の公式ブログは、vCenter Linkingのログ位置として、VCF Operations側の/storage/log/vcops/log/vrops-vcenter-linking.logと、Adapters側の/storage/vcops/log/adapters/ManagementAdapter/ManagementAdapter_xx.logを示しています。KB 429352と431689でも、TRUST_ESTABLISHMENT、NO_AVAILABLE_PEERS、ALREADY_EXISTSなどのエラー文脈が出てきます。
作業前に決めておきたいのは、ログの場所そのものよりも、ログを誰が、いつ、どの判断に使うかです。
| 失敗時に見るもの | 確認する観点 |
|---|---|
| vrops-vcenter-linking.log | Linking処理の状態、trust確立、StateManagerのエラー |
| ManagementAdapterログ | vCenterとの通信、trust確立、Adapter側の例外 |
| 対象vCenterの状態 | ELM残存、DomainGUID、SSO情報 |
| VCF Operations画面 | 対象vCenterが候補に出るか、groupの状態 |
| Broadcom KB | エラー文言と既知原因、Resolutionの前提 |
VCF Operations Diagnosticsや古いコンポーネントを含む環境の確認は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-17-vcf-operations-91-diagnostics-old-components/" target="_blank" rel="noopener">VCF Operations 9.1 Diagnosticsの記事</a>も参考になります。vCenter Linking固有のログとは別ですが、旧環境をVCF 9.1側へ寄せるときの調査観点として近いものがあります。
導入前チェックリストに落とす
未確認の項目がある場合は、ウィザード操作ではなく、公式ブログ、Broadcom KB、社内のELM解除履歴、IdP設計へ戻ります。
vCenter Linkingは、うまく動けば複数vCenter管理をかなり見やすくします。ただし、導入前の確認は画面操作よりも前にあります。最後に、変更審査や運用手順にそのまま転記しやすい形でチェックリストにします。
まず見る8項目
確認項目
| 確認項目 | 見る一次情報 | 判断メモ |
|---|---|---|
| 対象vCenterがvCenter 9.0以降か | 2026年6月2日の公式ブログ | vCenterごとの版数、パッチ状態を台帳化する |
| VCF Operations 9.xの状態 | 公式ブログ、VCF 9.1 FAQ | 管理対象、ログ取得担当、アクセス権を確認する |
| vCenter Group設計 | 2025年6月19日の公式ブログ | どのvCenterを同じグループに入れるか決める |
| 共通IdP | 2026年6月2日の公式ブログ | OIDC/SAML、対象ユーザー、権限範囲を確認する |
| VCF SSOでのログイン | 2025年6月19日の公式ブログ | 複数vCenter表示に使う認証経路を明確にする |
| ローカルアカウント時の見え方 | 2025年6月19日の公式ブログ | 見えない原因をリンク失敗と即断しない |
| ELM解除状況 | Broadcom KB 429352、431689 | 解除履歴、残存構成、DomainGUIDを確認する |
| ログ採取担当 | 2026年6月2日の公式ブログ、Broadcom KB | VCF OperationsログとAdapterログの取得手順を決める |
この8項目がそろってから、vCenter Group作成の実作業へ進むのが安全です。ひとつでも未確認がある場合は、ウィザード操作ではなく、公式ブログ、Broadcom KB、社内のELM解除履歴、IdP設計へ戻るべきです。
失敗時の初動を決めておく
初動順序
失敗時の初動は、作業後に考えるより、事前に決めておくほうが早く動けます。とくに「There are no valid vcenter instances available…」のようなエラーが出た場合、再試行だけで進めるのではなく、ELM残存、DomainGUID、VCF Operationsログ、Adapterログを順番に見る設計にしておく必要があります。
おすすめの初動は次の順です。
- VCF Operations画面で対象vCenterが候補に出るか確認する。
- VCF SSOでログインしているか、ローカルアカウントで見ていないか確認する。
vrops-vcenter-linking.logでtrust確立やStateManagerのエラーを見る。ManagementAdapter_xx.logでAdapter側の例外を見る。- 対象vCenterがELMに残っていないか、解除履歴を確認する。
- DomainGUID重複が疑われる場合は、Broadcom KBへ戻り、実行判断をサポートや社内手順と合わせる。
注意点
DomainGUID変更やELM解除のやり直しは、単なる設定変更ではありません。バックアップ、スナップショット、SSO、LDAP、復旧判断が関わります。この記事では「確認する」までを強調し、実行手順は公式KBへ渡します。
記事の主題ではないが、ライセンスや株価材料と混ぜない
注意点
VCF 9.xのvCenter Linkingは、ライセンス、価格、株価材料として読むよりも、運用設計の変更として読むほうが実務に役立ちます。もちろん、BroadcomのVMware統合、VCF 9.1、ライセンス体系への関心は高いですが、この記事の主語は複数vCenter管理、SSO、IdP、ELM残存、ログ確認です。
AVGO株価や決算の文脈を入れるとしても、製品・サービスへの影響を説明した後の補助線にとどめるべきです。今回の記事では、導入判断のノイズになるため、株価、目標株価、短期的な市場反応は扱いません。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, "vCenter Management Evolved: New vCenter Linking in VMware Cloud Foundation 9.x"（2026年6月2日公開）
https://blogs.vmware.com/cloud-foundation/2026/06/02/vcenter-management-evolved-new-vcenter-linking-in-vmware-cloud-foundation-9-x/
- VMware Cloud Foundation Blog, "Group and Link Your vCenter Servers to Simplify Workload Management"（2025年6月19日公開）
https://blogs.vmware.com/cloud-foundation/2025/06/19/group-and-link-your-vcenter-servers-to-simplify-workload-management/
- Broadcom Knowledge Base 431689, "vCenter linking in VCF Operations fails with errors…"
https://knowledge.broadcom.com/external/article/431689/vcenter-linking-in-vcf-operations-fails.html
- Broadcom Knowledge Base 429352, "vCenter linking in VCF Operations fails with error…"
https://knowledge.broadcom.com/external/article/429352/vcenter-linking-in-vcf-operations-fails.html
- VMware Cloud Foundation 9.1 General FAQs
https://www.vmware.com/docs/vmware-cloud-foundation-9-1-general-faqs
更新履歴
- 2026年6月7日
VMware Cloud Foundation Blog、Broadcom KB 431689、Broadcom KB 429352、VCF 9.1 FAQを確認し、初稿を作成しました。
VCF 9.x関連の前提は更新される可能性があるため、実作業前には最新の公式情報を確認します。
- 2026年6月7日: VMware Cloud Foundation Blog、Broadcom KB 431689、Broadcom KB 429352、VCF 9.1 FAQを確認し、初稿を作成しました。