【VMware Explore on Tour in Singapore 2026】VCF 9.1への移行を成功に導くポイント【セッションレポート】
はじめに
こんにちは、インフラ技術部のN.Aです。
シンガポールにて開催(2026/10/1~2)されていました「VMware Explore on Tour in Singapore 2026」にRe:Qから3名で参加させて頂きました!
会場および基調講演(General Session)の様子はこちらのブログで紹介していますので、是非ご覧ください!
【VMware Explore on Tour Singapore 2026】VMware歴10年超のエンジニアがシンガポール現地からレポート!
数あるセッションの中から、セッション「Planning and Executing the Transition to VCF 9.1」を受講してきました。
画像:VMware Explore 2026 on Tour in Singapore Hansd-on Labsセッション会場
本セッションはHansd-on Labsでの開催でしたが、実機を触るハンズオン形式ではなく、既存環境からVCF 9.1へ安全に移行するためのアーキテクチャ設計や運用上の注意点を学ぶ講義形式で進められました。
vSphere 8のサポート終了(EOS)が約1年後(2027年10月)に迫る中、多くのIT部門にとってVCF 9.1への移行検討は本格化させるべきタイミングです。
セッションでは、移行プロジェクトを推進する上で必ず押さえておくべきポイントを解説していました。
1. VCF 9.1移行で押さえるべき主要アーキテクチャ変更
VCF 9.1への移行は単なるバージョンの置き換えではなく、プラットフォーム構造の見直しを伴います。特に注意すべき主要な変更点は以下の3点です。
VCF Operationsが必須コアコンポーネント化
従来のVCF 5.2等ではオプション扱いだったVCF Operationsが、SDDC Managerをデプロイ・運用する前の「必須コンポーネント」となりました。
インプレースアップグレード非対応機能が存在
旧来のvRealize Suite Lifecycle Managerは廃止され、VCF Operationsへ機能が統合されています。また、ログ管理(旧Log Insight)やID管理(旧VIDMから新VIDBへの切り替え)は、既存環境からの直接的なインプレースアップグレードをサポートしていません。
これらは新環境側へ新規アプライアンスとしてデプロイし、データを移行・再設定する手順が必要です。
FQDNに関する小文字ルールの徹底
ランタイム、VCF Fleet管理、インスタンス、アイデンティティブローカー、ライセンスサーバー用に5つのFQDNを準備する必要がありますが、これらはすべて「小文字」で統一する必要があります。
大文字が混在しているとインストーラーでエラーの原因となるため、DNS設計時の厳格なチェックが必要です。

画像:VCF 5.x/Aria 8⇒VCF 9.1のコンポーネント構成マップ
2. 失敗しないアップグレード手順と現場での考慮点
コンポーネント間の依存関係が複雑なVCF環境では、正しい順序でアップグレードを進めることが不可欠です。
推奨されるアップグレード順序
1. 前提条件の検証:証明書、パスワード、NTP同期、ネットワーク設定の確認
2. VCF Operationsの適用・デプロイ:先行して運用基盤を更新
3. SDDC Managerのアップグレード
4. VCF管理サービスおよびライセンスサービスのデプロイ:9.1から導入された管理アプライアンスの展開
5. 管理ドメインスタックの更新:NSX Manager -> vCenter -> ESXi -> NSX Edge の順で適用
6. オプション機能の適用および最終処理
画像:インプレースアップグレードの順序
3. 移行の「波(Wave)」の設計とストレージ決定の重要性
移行を成功させるには、システムをどのようにグループ分けし、どのインフラ上で動かすかという初期設計が重要です。
移行単位(Wave)は「アプリの依存関係」で決める
移行の単位を単なる「VM〇台ずつ」といった機械的な数で分割するのは推奨されません。
ビジネスサービスやアプリケーションの依存関係グループ(Wave)単位で設計し、リスクの低い開発・検証環境から段階的に切替え、サインオフを得ながら本番環境へ進めるアプローチが鉄則です。
ストレージアーキテクチャは初期に確定させる
vSAN(ESA/OSA)、NFS、FC-SAN等の主要ストレージ構成は、アップグレードプロセスの初期段階で決める必要があります。一度選択した構成を後から変更・切り替えることは極めて困難または不可能なため、自社の要件に合わせた慎重な選定が求められます。
4. ライセンス・認証基盤(VIDB)の刷新
VCF 9.1では、運用管理を効率化するための共通基盤も新しくなっています。
中央集中型のライセンスサーバー
従来の個別のライセンスキー入力方式から、ライセンスサーバーアプライアンスによる一元管理へ移行しました。
インターネット接続型(24時間ごとに使用状況を自動同期)またはオフライン型(180日ごとにポータル経由でファイル更新)を選択可能です。
VIDB(VCF Identity Broker)によるシングルサインオン(SSO)
これまでバラバラになりがちだったコンポーネント間の認証を統合し、Active DirectoryやEntra ID等のエンタープライズIDと連携することで、単一のサインオン環境と統合ロール管理を実現します。
画像:VIDBによる統合SSO環境のイメージ
5. まとめ:安全なVCF 9.1移行に向けた次のアクション
セッションを受けて痛感したのは、VCF 9.1が従来のvSphereとは構造や概念から異なり、vSphere 8からの直接移行が不可能だという点です。
直前になって慌てないためにも、まずは自環境の洗い出しから早々に準備を始めるべきだと感じました。考慮すべき項目は多いですが、Broadcom公式の移行ドキュメントが充実しているため、これらをガイドにすれば着実に進められそうだと感じました。
VCF 9.1への移行は、単なるパッチ当てやバージョンアップ作業ではなく、ネットワーク・ストレージ・セキュリティ・認証を一体で再構築する「インフラ近代化プログラム」です。
vSphere 8のEOSまで残り1年となった今、まずは既存環境のアセスメントから着手し、余裕を持った移行ロードマップを策定することが重要です。
当社でもVCFに焦点を当てて、最新情報を引き続きキャッチアップし、理解を深めてまいりたいと思います。




