追記: 2026年6月10日の最新情報
2026年6月10日時点でVCF 5.2.xから9.1への移行計画を見直す場合、8ステップ順序に入る前にCPU/サーバー互換性と保護・復旧系コンポーネントを先に確認したい状況です。BroadcomのKB 428874とKB 318697では、VCF 9.xでのCPUサポート、Deprecated、Discontinuedの扱いが整理されています。
実務上は、Cascade Lake世代はVCF 9でDeprecatedだがサポート対象、Skylake世代はDiscontinuedとして扱われるため、同じ古いサーバーでも判断が分かれます。BCG、OEM側のBIOS/ファームウェアサポート、vSAN ReadyNode、Restricted IO Devices、必要に応じたRPQ/TQを、SDDC ManagerやNSXの作業順序とは別枠で先に確認してください。CPU/サーバー互換性は、後発記事のVCF 9.1移行前にCPU/サーバー互換性を確認する記事でも整理しています。
また、Broadcom TechDocsのProtection and Recovery 9.1.0.0100 Release Notesでは、同リリースにセキュリティ強化が含まれること、VMware Live Site Recovery 9.0.2.3、vSphere Replication 9.0.2.3、vSAN Data Protection 8.0 Update 3からのアップグレードでは保護サイトと復旧サイトの両方に9.1.0.0100 applianceを先に展開する必要があることが案内されています。
このテーマをもう少し広げて見るなら、VCF 9.1移行前にCPU/サーバー互換性を確認する：Skylake、Cascade Lake、BCG/RPQの実務ポイント と VCF 9.1 Express Patch 01を適用前に確認する：9.1.0.0100、5.2.1経路、vSAN/SDDC Manager注意点 も合わせて確認してください。8ステップ順序の前提として、CPU世代、サーバー互換性、BCG、RPQ/TQの確認が必要になるため。
3行まとめ
VCF Operations、SDDC Manager、Management Services、NSX、vCenter、ESXiを一つの作業にまとめず、前後関係で確認します。
VCF Management Servicesでは最低12個、追加18個、最大30個のIPと、内部CIDRの衝突有無を計画段階で確認します。
VCF Upgrade Plannerの結果は、公式情報と現行環境の棚卸しに照合してから変更計画へ落とします。
この記事では作業手順そのものではなく、変更審査前に見落としやすい確認点を整理します。
- VMware Cloud Foundation 5.2.xまたは9.0.xから9.1へ進むときは、vCenterやESXiだけでなく、VCF Operations、SDDC Manager、VCF Management Services、NSXの順序を先に分けて見る必要があります。
- Broadcom KB 440630では、VCF Management Servicesの最低12個のIPアドレス、追加18個、最大30個、内部CIDRの衝突確認など、計画段階で落とし込みたい条件が示されています。
- VCF Upgrade Plannerは便利な入口ですが、出力をそのまま作業計画にせず、公式ブログ、KB、TechDocs、現行環境の棚卸しと照合してからメンテナンス窓に翻訳するのが安全です。
VMware Cloud Foundation Blogで、2026年6月5日に「VMware Cloud Foundation 5.2.x to 9.1 Upgrade Guide」が公開されました。直近のVCF 9.1関連記事では、VKS、PowerCLI、Express Patchなど個別機能の更新が続いていましたが、今回は既存のVCF 5.2.x環境を9.1へ動かすときの順序そのものが主題です。
この記事では、VCF 5.2.xまたは9.0.xを使っている導入企業、運用担当、調査担当が、社内の変更審査に入る前に見るべき点を整理します。作業手順書の代替ではありません。実作業では、必ずBroadcomの最新TechDocs、KB、サポート情報、互換性情報、HCLを確認してください。
Broadcom Watch JapanはBroadcomおよび関係会社とは非提携です。この記事は製品・サービス情報の整理であり、投資助言や個別環境への導入指示ではありません。
まず自社環境を5.2.x、9.0.x、単体vSphere系に分ける
最初の分類は製品名だけでなく、SDDC Managerの有無、NSXの有無、運用系コンポーネントの状態まで含めて見ます。
VCF 9.1への移行を読むとき、最初に分けたいのは「今どの製品を使っているか」ではなく、「どの管理モデルの下にいるか」です。SDDC Managerを使っているVCF 5.2.xまたは9.0.x環境と、vCenter/ESXi中心の環境では、同じ9.1を目指していても入口が変わります。
SDDC Managerを使うVCF 5.2.xまたは9.0.x
Broadcom KB 440630は、VCF 5.2.xまたは9.0.xでSDDC Managerを使う環境について、VCF OperationsをアップグレードしたうえでLCMワークフローに従ってVCF 9.1へ進む経路として整理しています。ここで重要なのは、vCenterやESXiのアップグレードだけを先に考えないことです。
VCF 9.1では、運用、ライフサイクル、ライセンス、管理サービスの置き場所が変わります。公式ブログも、5.2.xから9.1への移行を「単なるバージョン変更」ではなく、統合されたManagement Servicesレイヤーへの移行として説明しています。社内の計画書では、少なくとも次の棚卸しを先に作ると読みやすくなります。
| 確認するもの | 見る理由 | メモに残す内容 |
|---|---|---|
| 現行VCFバージョン | 5.2.x、9.0.x、別経路を分ける | SDDC Managerの版数、適用済みパッチ |
| Aria OperationsまたはVCF Operations | 9.1移行の前半に関わる | 既存構成、管理対象、Collector Group |
| SDDC Manager | LCMワークフローの中心になる | 管理ドメイン、ワークロードドメイン |
| NSX | 管理プレーンとEdgeの順序に関わる | NSX Manager、Edge Cluster、利用機能 |
| vCenter ServerとESXi | 後半の更新対象になる | クラスタ、ホスト、メンテナンス単位 |
vCenter/ESXi中心の環境とは分けて読む
KB 440630には、vCenterとESXだけの環境、Aria Operationsを含む環境、NSXやAria Automationを含む環境なども整理されています。たとえばNSX 4.xがある場合、KBではVCF Installerのconverge workflowを使う経路が示され、独立コンポーネントとしてアップグレードする選択肢がない旨も説明されています。
つまり「vSphere 8.xから9.1へ上げたい」という読者と、「SDDC Manager配下のVCF 5.2.xからVCF 9.1へ移行したい」という読者では、確認すべき順番が違います。この記事の主対象は後者です。vSphere Foundationや単体vSphere寄りの経路を確認したい場合は、公式のVCF Upgrade PlannerとKB側の経路表を起点にしてください。
なお、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>も補助になります。この記事ではそこから一段絞り、5.2.x/9.0.xから9.1へ進む移行計画に寄せます。
8ステップ順序は運用系からデータプレーンへ進む流れとして読む
- 1. VCF Operations
Aria OperationsからVCF Operations 9.1への移行を最初の前提として扱います。
- 2. Cloud Proxy
Cloud Proxyの展開とSDDC adapter Collector Groupの更新を、運用データの見え方に関わる工程として見ます。
- 3. SDDC Manager
SDDC Manager 9.1.0.0へのアップグレードを、以後のライフサイクル管理の土台として確認します。
- 4. Management Services
VCF Management Services Clusterを展開し、ライセンス、デポ、Salt RaaSなどの配置を確認します。
- 5. NSX Management Plane
NSX Manager側の更新を、vCenterやESXiより前に置かれる工程として確認します。
- 6. vCenter Server
vCenter Serverの更新を、管理プレーンとホスト更新の間にある工程として見ます。
- 7. ESXi Hosts
ESXiホストの更新は、前半の管理基盤が整った後のコンピュート側工程として扱います。
- 8. NSX Edge
NSX Edge Clusterは後半の影響範囲として、通信影響と切り戻し観点を分けて確認します。
8ステップは単なる番号順ではなく、運用系、管理サービス、ネットワーク、コンピュートへ進む依存関係として読むと整理しやすくなります。
公式ブログは、VCF 5.2.xから9.1への移行を8ステップの流れで示しています。ここを単なる一覧として読むより、前半は運用・管理レイヤー、後半はネットワーク・コンピュート・データプレーンに進む流れとして読むと、変更審査に落とし込みやすくなります。
前半はOperations、Cloud Proxy、SDDC Manager、Management Services
公式ブログの前半では、Aria OperationsからVCF Operations 9.1への移行、Cloud Proxyの展開とSDDC adapter Collector Groupの更新、SDDC Manager 9.1.0.0へのアップグレード、VCF Management Services Clusterの展開が並びます。
この部分は、仮想マシンやホストを先に触る工程ではなく、9.1で必要になる運用とライフサイクルの土台を整える工程です。とくにAria OperationsからVCF Operationsへの移行は、以後のアップグレード表示、ライセンス、管理サービス、診断の見え方に影響します。
根拠
公式ブログは、5.2.xから9.1への移行対象として、Aria Operations、SDDC Manager、vRSLCM、NSX Manager and Edge Clusters、vCenter Server、ESXi Hostsを挙げています。さらに、最初のステップをAria OperationsからVCF Operations 9.1への移行に置いています。
評価基準
社内計画では、前半だけで次の問いに答えられる状態にしておきたいところです。
- VCF Operationsへ移行する前後で、誰が監視とアラートを確認するか。
- Cloud ProxyやCollector Groupの更新で、既存のメトリクス収集に空白が出ないか。
- SDDC Manager 9.1.0.0への更新後、どの画面やログで状態を確認するか。
- VCF Management ServicesのIP、FQDN、内部CIDRがネットワーク設計に反映されているか。
後半はNSX、vCenter Server、ESXi、Edgeを分ける
公式ブログの後半では、NSX Management Plane、vCenter Server 9.1、ESXiホスト、NSX Edgeが続きます。ここで注意したいのは、NSX、vCenter、ESXiを「まとめて基盤更新」として扱わないことです。
NSX Management Planeは、オーバーレイやEdgeとの関係を持ちます。vCenter Serverは認証、証明書、管理UI、API、ライセンスにも関わります。ESXiホストはローリングメンテナンスやクラスタ単位の影響を伴います。NSX EdgeはNorth-South通信に関係しやすく、最後の整合確認として別枠にした方が事故を見つけやすくなります。
注意点
公式ブログは「8ステップのオーケストレーション」として順序を示していますが、個別環境の停止時間や作業可能時間は示していません。記事やツールの順序を読んだだけで本番作業に入るのではなく、事前検証の場、バックアップ、サポートケースの必要性、変更承認の条件を別に定義してください。
VCF Management Servicesで先に詰まるIPと内部CIDRを見る
12個のIPだけを見ると短期条件に偏ります。変更審査では、追加余地、CIDR衝突、名前解決まで同じ表で残すと説明しやすくなります。
VCF 9.1移行で見落としやすいのが、VCF Management Servicesまわりのネットワーク条件です。公式ブログでは、License Server、Software Depot、Salt RaaSなどの重要サービスを統合クラスタに置く流れが説明されています。Broadcom KB 440630では、さらに具体的なIP条件が示されています。
最低12個、追加18個、最大30個の読み方
KB 440630によると、VCF Management Servicesのデプロイには最低12個のIPアドレスが必要です。さらに、新しいVCF Management Servicesの追加、スケールアウト、将来バージョンへのアップグレードに備えて追加18個を後から加えられると説明されています。最大では30個を見ます。
ここは「12個あればよい」と短く読まない方がいいです。初回デプロイだけを見るなら最低12個ですが、長期運用の計画では、追加18個の余地と管理ネットワーク上のレンジ設計まで含めておく必要があります。KBでは、これらのIPレンジは管理ネットワーク上に置くこと、連続していないレンジを後から追加できることも示されています。
| 項目 | 計画時の見方 | 変更審査で残すメモ |
|---|---|---|
| 最低12個のIP | 初回デプロイに必要な数 | 使用レンジ、予約状況、DNS担当 |
| 追加18個 | Day-Nや将来のスケールアウト余地 | 追加候補レンジ、重複確認 |
| 最大30個 | 長期運用の上限として確認 | 管理ネットワークの空き容量 |
| 連続しないレンジ | 後から追加できる前提 | 運用ルール、申請単位 |
198.18.0.0/15の内部CIDR衝突は別論点
KB 440630では、VCF services runtimeが内部IPレンジとして198.18.0.0/15を使うこと、管理ネットワークと重複しないよう確認することも説明されています。これはVCF Management Servicesに割り当てる管理ネットワーク上のIP数とは別の話です。
また、KBは必要に応じてJSON仕様ファイルで内部レンジを240.0.0.0/15または250.0.0.0/15へ変更できることにも触れています。ここを読むと、移行前にネットワーク担当へ確認すべき問いがはっきりします。
確認項目
- 管理ネットワークで198.18.0.0/15を使っていないか。
- 監視、検証、ラボ、NAT、ルーティング設計で同レンジを特別扱いしていないか。
- 内部CIDRを変更する必要がある場合、JSON仕様ファイルを誰が確認するか。
- VCF License Server runtimeで使われる172.17.0.0/16と管理ネットワークが衝突しないか。
このあたりは、<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>で扱ったリソース確認ともつながります。9.1移行では、CPUやメモリだけでなく、管理ネットワークのアドレス設計も同じ変更計画に入れておくと見通しがよくなります。
VCF Upgrade Planning Toolは計画の入口として使う
- 1入力前の棚卸し
vCenter、ESXi、SDDC Manager、NSX、Aria Operations、Aria Automationの版数と担当チームをそろえます。
- 2Plannerで経路を見る
vSphere中心、NSXあり、Aria Automationあり、フルVCFなど、現行構成に近い経路を確認します。
- 3公式情報と照合する
KB、公式ブログ、TechDocsの順序や前提条件と、Plannerの示す経路を突き合わせます。
- 4メンテナンス計画に直す
実行順、担当、確認項目、切り戻し判断、後続Day-N作業を社内の変更計画へ落とします。
Plannerは計画の完成物ではなく、現行環境の棚卸しと一次情報確認を始める入口として使います。
VCF 9.1では、環境の組み合わせが増え、スタート地点ごとに経路が変わります。そこで役立つのがVCF Upgrade Plannerです。Broadcom KB 440630も、同ツールがvSphereベースの環境からNSXやAria Automationを含む組み合わせ、フルVCF環境まで、VCF 9.1へのアップグレード計画を支援するものとして案内しています。
ただし、ツールは社内の変更計画を自動で完成させるものではありません。入力する前の棚卸しが粗いと、結果も粗くなります。
入力前に現行構成の棚卸しをそろえる
VCF Upgrade Plannerを開く前に、現行構成の一覧を用意しておきたいところです。画面上の選択肢に合わせてその場で思い出すより、管理台帳、ライセンス情報、担当チームの記録を見ながら入力した方が、あとで説明しやすくなります。
確認項目
- 現行のvCenter、ESXi、SDDC Manager、NSX、Aria Operations、Aria Automationの版数。
- VCF Operations 9.0.xがあるか、Aria Operations 8.xなのか、まだないのか。
- NSX 4.x、NSX Edge Cluster、Aria Automationの有無。
- 管理ドメインとワークロードドメインを同じメンテナンス窓で扱うか。
- VCF entitlement、VVF、アドオン、サポート契約の確認担当。
ツール結果はメンテナンス計画に翻訳する
ツールが示す経路は、計画の入口として見るのがちょうどよいです。出力を見たら、次にBroadcom KB、TechDocs、リリースノート、互換性情報へ戻り、実作業のフェーズに分けます。
たとえば、VCF 5.2.xまたは9.0.xでSDDC Managerを使っている環境なら、KBではVCF Operationsをアップグレードした後にLCMワークフローに従う流れとして整理されています。これを社内計画にするなら、単に「VCF Operations更新」と書くのではなく、事前バックアップ、ログ確認、担当者、成功条件、失敗時の連絡先まで落とし込みます。
評価基準
ツール結果、KBの必須順序、社内棚卸し表が矛盾なく並ぶことが最低ラインです。どれか一つだけを根拠にして移行可否を決めない方がよいでしょう。
NSX経路は管理プレーンとEdge Clusterを分けて確認する
- 1Management Services後
VCF Management Services展開後に、NSX Management Planeの更新をVCF全体の順序の中で確認します。
- 2NSX Management Plane
NSX Managerの版数、証明書、オーバーレイ、vCenterやESXiとの前後関係を確認します。
- 3vCenterとESXi
NSXだけを独立して進めず、vCenter ServerとESXiホスト更新との関係を残します。
- 4NSX Edge Cluster
North-South通信、担当チーム、切り戻し判断、ワークロードドメインの扱いを分けて確認します。
- 5Day-N計画
すべてを同じ夜間作業に詰め込まず、後続に回せるワークロードドメインを明確にします。
NSXは管理プレーンとEdge Clusterで影響範囲が変わります。変更計画では順序と担当境界を分けて残すことが重要です。
NSXを含む環境では、9.1移行の読み方が一段難しくなります。公式ブログの8ステップでは、VCF Management Services展開の後にNSX Management Planeをアップグレードし、vCenter Server、ESXiホストの後にNSX Edgeを最後に扱う流れが示されています。
NSX Management Planeをどのタイミングで見るか
NSX Management Planeは、単にNSX Managerの版数を上げるだけの話ではありません。vCenterやESXiとの順序、証明書、オーバーレイ、Edge Clusterとの関係を持ちます。移行計画では、NSXの管理プレーンを「ネットワーク担当の工程」として別紙に逃がすのではなく、VCF全体の順序の中に置いて見ます。
根拠
公式ブログでは、NSX Management Planeのアップグレードを、VCF Management Services展開の後、vCenter ServerとESXiホストの前に置いています。KB 440630でも、NSXがあるvCenter/ESX中心の環境ではVCF Installerのconverge workflowを使う経路が示され、独立コンポーネントとしてのアップグレードではないことが読み取れます。
Edge Clusterとワークロードドメインは後続計画として扱う
KB 440630は、9.1へ環境を上げるときに必須のコンポーネント順序に従う必要がある一方、ワークロードドメインはDay-N手順で後からアップグレードできると説明しています。この一文は、変更審査でかなり大切です。
管理ドメイン、NSX Management Plane、vCenter、ESXi、Edge Cluster、ワークロードドメインをすべて一つの夜間作業に詰め込むと、問題が起きたときに切り分けが難しくなります。公式情報がDay-Nの扱いを示している場合は、何を同じ窓で進め、何を後続に回すかを明確にしてください。
確認項目
- NSX Edge Clusterの有無と、North-South通信の影響範囲。
- 管理プレーンとEdgeの担当チーム、承認者、確認ログ。
- ワークロードドメインを同時に進めるか、Day-Nへ分けるか。
- NSX関連の既知問題、証明書、FQDN、ログ収集の確認先。
- 失敗時に、どの時点で止めるか。
古いvSphereやNSXを含む環境で見え方を確認したい場合は、<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>も合わせて読むと、アップグレード前後のFindingsやログ連携を整理しやすくなります。
移行前チェックリストに落とす
このチェックリストは移行可否を断定するものではありません。公式情報と自社環境の抜けを見つけるために使います。
最後に、この記事の内容を変更審査前のチェックリストへ落とします。ここでは、個別環境の可否を断定しません。目的は、公式情報と自社環境の棚卸しに抜けがないかを確認することです。
最低限の確認項目
| 確認項目 | 主に見る一次情報 | 判断のメモ |
|---|---|---|
| 現行バージョンと対象経路 | KB 440630、VCF Upgrade Planner | 5.2.x、9.0.x、vSphere中心環境を分ける |
| VCF OperationsまたはAria Operations | 公式ブログ、KB | 移行前半の前提として扱う |
| SDDC ManagerとLCMワークフロー | 公式ブログ、KB | 9.1.0.0更新と後続工程を分ける |
| VCF Management ServicesのIP | KB、TechDocs | 最低12、追加18、最大30を確認 |
| 内部CIDR | KB、TechDocs | 198.18.0.0/15、172.17.0.0/16の衝突を見る |
| NSX Management Plane | 公式ブログ、KB | vCenter/ESXiとの順序を分ける |
| vCenter ServerとESXi hosts | 公式ブログ、リリースノート | ローリングメンテナンス、成功条件を定義 |
| Edge Clusterとワークロードドメイン | 公式ブログ、KB | 同日作業かDay-Nかを決める |
すぐ進めやすい環境、先に棚卸しすべき環境
すぐ進めやすいのは、現行のVCF構成、IPレンジ、FQDN、NSXの有無、ワークロードドメインの扱いがすでに台帳化されている環境です。VCF Upgrade Plannerの結果とKBの経路表を照合し、事前検証の場で手順を確認できるなら、社内説明もしやすくなります。
逆に、先に棚卸しすべきなのは、Aria OperationsやNSXの利用範囲が担当者の記憶に依存している環境です。とくに、NSX Edge Cluster、vCenter/ESXiのクラスタ単位、管理ネットワークの空きIP、内部CIDRの衝突確認が未整理なら、9.1の作業日を決める前にそこを固めた方がよいです。
この記事で確認した結論
VCF 5.2.xから9.1への移行は、製品名だけを見ると「VCFのバージョンアップ」に見えます。しかし公式ブログとKBを合わせて読むと、運用系の移行、管理サービスの展開、ライセンスサーバー、NSX、vCenter、ESXi、Edgeを順序立てて扱う作業です。
VCF Upgrade Plannerで入口を確認し、KB 440630で経路と既知の注意点を確認し、TechDocsでVCF Management Servicesの構成要素とネットワーク条件を確認する。この三つを揃えてから、メンテナンス計画、事前検証、サポート確認に進むのが現実的です。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, "Modernizing Infrastructure: VMware Cloud Foundation 5.2.x to 9.1 Upgrade Guide"
https://blogs.vmware.com/cloud-foundation/2026/06/05/modernizing-infrastructure-vmware-cloud-foundation-5-2-x-to-9-1-upgrade-guide/
- Broadcom Knowledge Base, "Upgrade Sequence and Related Issues for VMware Cloud Foundation and vSphere Foundation 9.1"
https://knowledge.broadcom.com/external/article/440630/upgrade-sequence-and-related-issues-for.html
- Broadcom TechDocs, "Components in VCF and vSphere Foundation"
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/vcf-management-appliances.html
- VMware, "VCF 9.1 Frequently Asked Questions: May 2026"
https://www.vmware.com/docs/vmware-cloud-foundation-9-1-general-faqs
- VCF Upgrade Planner
https://vmware.github.io/vcf-upgrade-planner/