3行まとめ
このテーマをもう少し広げて見るなら、VCF 9.xのEnhanced Data Pathを導入前に確認する：EDP Standard、VMXNET3、TNP切替の実務ポイント と VCF 9.1のArista/AMD連携を導入前に確認する：EVPN/VXLAN、MI350、AI基盤設計の実務ポイント も合わせて確認してください。CPU/サーバー互換性の棚卸し後に、NIC、VMXNET3、TNP切替などネットワーク性能側の前提を確認できる。
Cascade Lake、Skylakeなどの世代だけでなく、BCG上のサーバーモデル表示まで確認する。
ReadyNode、NIC、HBA、ストレージコントローラ、Restricted/EOLを分けて確認する。
ハードウェア支援はOEM、VCFソフトウェア側の例外確認はBroadcom窓口で証跡を残す。
確認日は2026年6月8日。最終判断はBCG、Broadcom Support、Broadcomアカウントチーム、OEM、契約条件で確認する。
VCF 9.1へ進む前の互換性確認は、Release Notesだけでは終わりません。CPU世代、サーバーモデル、vSAN ReadyNode、NIC/HBAなどのI/Oデバイスを、Broadcom Compatibility GuideとBroadcom KBで分けて確認する必要があります。
公式KBでは、Cascade LakeはVCF 9でDeprecated Modeとして扱われる一方、SkylakeはDiscontinuedとして説明されています。継続利用を検討する場合は、BCGの掲載状態、OEMのハードウェア支援、RPQ/TQの要否を同じ表に置いて判断します。
この記事は、特定サーバーや特定OEMの可否を断定するものではありません。確認日は2026年6月8日で、最終判断はBCG、Broadcom Support、Broadcomアカウントチーム、OEM、契約条件で確認してください。
本記事はBroadcom、VMware、関係会社とは非提携の確認メモです。投資助言ではなく、VCF 9.1移行前に導入企業、運用担当、調達担当、保守担当が同じ前提で話すための整理です。株価や決算ではなく、読者が実際に触れる製品、サポート、互換性、移行計画を主語にします。
VCF 9.1移行前にハードウェア互換性をゲートに置く
- 1現行構成を棚卸し
OEM、モデル、CPU、BIOS、ファームウェア、NIC/HBA、vSAN利用有無、保守期限をそろえる。
- 2BCGとKBを見る
サーバー、CPU、I/Oデバイス、vSAN ReadyNodeをBroadcom Compatibility GuideとKBで確認する。
- 3OEM回答を取る
Confirm w/Vendor、構成差分、古い世代の継続利用はOEMの支援可否を文面で残す。
- 4RPQ/TQ要否を確認
DiscontinuedやBCG非掲載を継続利用する場合は、Broadcom側の例外確認を別に進める。
- 5移行計画へ進む
続行、OEM確認後に続行、刷新、移行延期のどれかに分類して日程を決める。
インストールできそうかと、サポートされるかは別の判断として扱う。
2026年6月5日にVMware Cloud Foundation Blogは、VCF 5.2.xから9.1へ進むアップグレードガイドを公開しました。そこではAria Operations、SDDC Manager、VCF Management Services、NSX、vCenter Server、ESXなどをまたぐ移行順序が示されています。移行手順そのものは重要ですが、その前に止めて確認したいのが、いま使っているホストがVCF 9.xの前提に耐えられるかです。
直近のVMware利用者コミュニティでも、VCF 9.1、Express Patch、Skylake、Cascade Lake、RPQ、HCL確認に関する会話が続いています。この記事では、そうした投稿を需要シグナルとして扱います。個別投稿の真偽を根拠にするのではなく、読者が導入前に何を不安に思っているかを拾い、公式一次情報へ戻して確認します。
すでにVCF 5.2.xから9.1への順序を見ている読者は、VCF 5.2.xから9.1への移行前チェックと合わせて読むと、ソフトウェア手順とハードウェア確認を分けやすくなります。2026年6月のVCF関連更新は、月次まとめでも追っています。
アップグレード手順の前に棚卸しする
最初にやることは、VCF 9.1の新機能を並べることではありません。現行ホストのOEM、モデル、CPUシリーズ、BIOS、ファームウェア、NIC、HBA、ストレージコントローラ、vSAN ReadyNode利用有無、保守契約期限を棚卸しします。
この段階で大事なのは、「インストールできそうか」と「サポートされるか」を混同しないことです。古いハードウェアでインストールが進む場合でも、BCGに掲載されているか、CPU世代がDeprecatedなのかDiscontinuedなのか、OEMがハードウェア側の支援を続けるのかは別問題です。
止める条件を先に決める
移行会議では、互換性が曖昧なまま日程だけを確定しない方が安全です。たとえば、BCG非掲載、Skylake継続利用、EOL I/Oデバイス、OEM保守終了、vSAN ReadyNode未確認のいずれかが残っている場合は、アップグレード日の確定ではなく、確認担当と期限を決める会議に切り替えます。
Release NotesとBCGの役割を分ける
VCF 9.1のWhat's Newには、Enhanced NVMe Memory Tiering、Extended vSAN Deduplication and Compression、vSphere Elastic Provisioning、VCF Management Servicesなどの機能が並びます。これは「何が増えたか」を見る資料です。
一方、CPU、サーバーモデル、I/Oデバイス、vSAN ReadyNodeの互換性は、Broadcom Compatibility Guideと関連KBで確認します。Release Notesだけを読んで、手元のサーバーがそのまま使えると判断しないことが重要です。
使う資料を分ける
- 機能差分を見る資料はVCF 9.1 Release NotesとWhat's Newです。
- アップグレード順序を見る資料はVCF 5.2.xから9.1への公式アップグレードガイドです。
- ハードウェア互換性を見る資料はBCG、CPU deprecation KB、deprecated CPU systems KB、deprecated devices KBです。
- 個別OEMのハードウェア支援は、OEMの保守窓口、契約、案件番号付き回答で確認します。
CPU世代はSupported、Deprecated、Discontinuedで見分ける
BCG掲載、対象サーバーモデル、実機構成、BIOS/ファームウェアの一致を確認して進める。
VCF 9ではDeprecated Modeとして読み、BCG掲載、OEM回答、将来の刷新計画を合わせて判断する。
Discontinuedとして扱い、継続利用ではRPQ/TQやVCF Software Only supportの確認対象にする。
BCG非掲載、EOSL、OEM保守期限、I/Oデバイスの扱いを確認して、刷新や延期を検討する。
Deprecatedは猶予を含む状態、Discontinuedは通常のサポート対象として扱わない方向の確認が必要な状態として読む。
VCF 9.xへの移行で最初に誤解しやすいのが、CPU世代の扱いです。Broadcom KB 318697は、VCF ReleasesにおけるCPU support deprecation and discontinuationを説明しています。Broadcom KB 428874は、ESX 9.0におけるdeprecated CPU systems/serversとサポートへの影響を説明しています。
ここで見るべき言葉は、Supported、Deprecated、Discontinuedです。Deprecatedはまだ使える猶予を含む状態ですが、将来の主要リリースで外れる前提を伴います。Discontinuedは、VCF 9.xで通常のサポート対象として扱わない方向の確認が必要です。
Cascade LakeはDeprecated Modeとして読む
KB 428874は、Intel Cascade Lake generationをVCF 9でDeprecated Modeとして説明しています。つまり、Cascade Lakeを見た瞬間に「使えない」と決めるのは早すぎます。Deprecatedは、現在のVCF 9.xでの扱い、BCG掲載、OEM支援、将来の刷新計画をセットで見る状態です。
ただし、Cascade Lakeだから安心とも言えません。サーバーモデルがBCGでどう表示されるか、VCF Supportedなのか、VCF Supported. Confirm w/Vendorなのか、vSAN ReadyNodeとして使うのか、NICやストレージコントローラがRestrictedではないかを別に見ます。
Cascade Lakeで止めるべきケース
Cascade Lake世代でも、BCGにサーバーモデルが見つからない、Confirm w/Vendorの表示があるのにOEM回答がない、vSAN ReadyNode構成と実機構成が違う、I/OデバイスにEOLが含まれる、といった状態なら移行日程を固める前に止めます。
SkylakeはDiscontinuedとしてRPQ/TQの確認対象にする
KB 428874は、Intel Skylake generationについて、VCF 9ではDiscontinuedとして扱われ、CPU SeriesとサーバーモデルがVCF 9のBCGに掲載されない旨を説明しています。さらに、継続利用にはRPQ/TQが必要になり得ること、承認された場合も基本はVCF Software Only supportになることが示されています。
ここは強く書いておきたい点です。Skylake環境でESX 9.xが動くかどうかと、VCF 9.xで本番サポートを受けられるかは同じではありません。とくに本番環境、監査対象、顧客向けサービス、規制産業では、動作可否より先に支援範囲と責任境界を確認します。
RPQ/TQで自動的にOEM保守が付くわけではない
RPQ/TQは、Broadcom/VMware側の例外確認の入口です。OEMのBIOS、ファームウェア、マイクロコード、ハードウェア交換、障害時の部品供給を自動的に保証するものではありません。古いサーバーを続けるなら、Broadcom側の確認とOEM側の確認を別々の証跡として残します。
CPU KBとBCGを突き合わせる
CPU KBだけで判断すると、サーバーモデルやI/Oデバイスの落とし穴を見落とします。BCGだけを見ると、CPU世代が次の主要リリースでどう扱われるかを読み落とすことがあります。両方を突き合わせて、次のように分類します。
| 分類 | 見る資料 | 実務上の扱い |
|---|---|---|
| Supported | BCG、OEM回答 | 通常の移行候補。ただし構成差分とI/Oデバイスを確認する。 |
| Deprecated | KB 318697、KB 428874、BCG | VCF 9.xでは確認しながら使う候補。刷新期限を同時に決める。 |
| Confirm w/Vendor | BCG、OEM回答 | Broadcom側とOEM側の責任境界を確認してから進める。 |
| Discontinued | KB 318697、KB 428874 | RPQ/TQ、OEM支援、刷新計画を確認する。通常移行と同じ扱いにしない。 |
| Not listed | BCG、OEM、Broadcom窓口 | 検索条件の誤りも含めて再確認し、可否を断定しない。 |
この表は最終結論ではなく、移行前の仕分けです。最終判断は、サーバーモデル、CPU、vSAN、I/Oデバイス、OEM支援、RPQ/TQの回答がそろってから行います。
BCGの表示はBroadcom側とOEM側の責任境界を読む
BCGで見つかるかどうかだけで終わらせず、責任境界と証跡を同じ場所に残す。
VMware Cloud Foundation BlogのVCF 9.0 Server Certification記事は、Broadcom Compatibility GuideをVCF 9.0のハードウェアサポート確認の基準として説明しています。VCF 9.1移行前でも、BCGでサーバー、CPU、I/Oデバイス、vSAN ReadyNodeを確認する基本姿勢は変わりません。
BCGを見るときに大切なのは、表示を「可」か「不可」だけで読まないことです。とくにVCF Supported. Confirm w/Vendorは、Broadcom側のVCFソフトウェア支援と、OEM側のハードウェア支援を分けて読む必要があります。
VCF SupportedとConfirm w/Vendorの違い
VCF Supportedは、BCG上で対象構成がサポート対象として扱われる入口です。もちろん、実機のBIOSやファームウェア、部品差分、構成変更が一致しているかは別に確認します。
VCF Supported. Confirm w/Vendorは、より慎重に読むべき表示です。Broadcom側ではVCFソフトウェアの支援余地があっても、OEMがそのサーバーハードウェア、BIOS、ファームウェア、マイクロコードを支援するかはOEM確認が必要です。
責任境界を表にする
| 項目 | Broadcom側で確認すること | OEM側で確認すること | 自社で残す証跡 |
|---|---|---|---|
| VCFソフトウェア | VCF 9.xでの支援範囲、RPQ/TQ要否 | なし、または共同確認 | Broadcom問い合わせ番号 |
| CPU世代 | Deprecated/Discontinuedの扱い | 対象サーバーでの支援可否 | CPUシリーズ、ホスト一覧 |
| BIOS/ファームウェア | 通常はOEM確認へ誘導 | 提供可否、推奨版、保守期限 | OEM回答日、対象型番 |
| マイクロコード | 支援範囲の前提確認 | 更新提供、脆弱性対応 | バージョン、更新計画 |
| NIC/HBA/ストレージ | BCG、restricted/EOL確認 | ドライバ、ファームウェア、交換部品 | 部品型番、BCG URL |
この責任境界が曖昧なまま進むと、障害時に「ソフトウェアは支援されるが、ハードウェア側は支援外」という状態になりかねません。
Not listedは検索ミスだけで片付けない
BCGで対象サーバーが見つからないとき、最初に疑うべきは検索条件です。製品バージョン、OEM名、モデル名、CPUシリーズ、System Type、vSAN ReadyNodeのカテゴリが合っているかを確認します。
それでも見つからない場合は、単なる検索ミスと決めつけず、CPU、サーバー、I/Oデバイス、または構成部品がEOSLに近い可能性を考えます。KB 428874も、EOLのCPU、サーバー、I/Oドライバの組み合わせでは、ESX 9.xで認識されない、またはアップグレードが失敗する可能性に触れています。
Not listedで次にやること
- 別名、SKU、OEM表記、CPUシリーズ名で再検索する。
- vSAN ReadyNode、Systems/Servers、CPU Series、I/O Devicesを分けて見る。
- OEMに、対象モデルと対象構成がVCF 9.xで支援されるか確認する。
- Broadcomアカウントチームまたはサポートへ、RPQ/TQや例外確認の入口があるか相談する。
- 期限までに確認できない場合は、移行延期またはハードウェア刷新を計画に入れる。
vSAN ReadyNodeはCPU世代だけで判断しない
対象VCF 9.xまたは対象ESXバージョンでReadyNodeとして確認できるかを見る。
どちらの構成で使っているかを分け、認定構成との差分を確認する。
Cascade LakeのDeprecated ModeとSkylakeのDiscontinuedを混同しない。
ディスク、コントローラ、NIC/HBA、NVMeなどをBCGで個別に確認する。
継続利用、段階刷新、移行延期を、BCG掲載、OEM保守、容量、性能、期限で分ける。
vSANでは、CPUだけが条件を満たしていても、部品差分やEOLデバイスで移行判断が変わる。
vSAN環境では、CPU世代の確認だけで終わらせると危険です。KB 428874は、Cascade LakeのvSAN OSA/ESA ReadyNodeがDeprecated Modeとして扱われること、SkylakeはvSAN CPU generationとしてDiscontinuedになり、vSAN ReadyNode BCGに掲載されないことを説明しています。
つまり、vSANではCPU、ReadyNode掲載、ストレージデバイス、コントローラ、NIC、ファームウェア、構成差分を分けて確認します。VCF 9.1の機能面ではNVMe Memory TieringやvSAN関連の更新もありますが、既存ハードウェアが支援されるかは別の確認です。vSphere Foundation 9.1の関連機能は、VVF 9.1リソース確認記事も参考になります。
ReadyNode掲載、OSA/ESA、部品を分ける
vSAN ReadyNodeとして購入したサーバーでも、実際の構成が当時の認定構成と違うことがあります。ディスクを交換した、コントローラを変えた、NICを増設した、ファームウェアだけ古い、という差分があれば、ReadyNode名だけでは判断できません。
VCF 9.1へ進む前には、少なくとも次を分けて確認します。
- ReadyNodeとしての掲載がVCF 9.xまたは対象ESXバージョンで確認できるか。
- OSA/ESAのどちらで使っているか。
- CPU世代がDeprecatedかDiscontinuedか。
- ストレージデバイス、コントローラ、NIC/HBAがBCGで確認できるか。
- OEMがその構成のファームウェア、マイクロコード、交換部品を支援するか。
継続利用、段階刷新、移行延期を選ぶ
vSAN環境では、ホストの一部だけが赤判定になることがあります。全ホストを一気に刷新できない場合は、継続利用、段階刷新、移行延期を現実的に分けます。
| 選択肢 | 向く状態 | 注意点 |
|---|---|---|
| 継続利用 | BCG掲載、OEM確認、I/O確認がそろっている | Deprecatedなら次の刷新期限も決める。 |
| 段階刷新 | 一部ホストやI/Oだけが古い | vSAN構成、クラスタ混在、保守窓口の説明を先に固める。 |
| 移行延期 | Skylake、EOLデバイス、OEM回答なしが残る | ソフトウェア手順より先にハードウェア計画を見直す。 |
本番環境では、「試したら動いた」を判断材料の中心に置かない方が安全です。支援範囲、保守契約、復旧時の責任境界が説明できる状態にしてから移行します。
I/OデバイスはRestrictedとEOLを分けて扱う
Restrictedは猶予、EOLは移行前に止めて確認する条件として扱う。
CPUやサーバーモデルが注目されがちですが、VCF 9.x移行ではI/Oデバイスも重要です。Broadcom KB 391170は、ESX 9.0におけるdeprecated devicesとサポートへの影響を説明しています。ここで出てくるのがRestricted DevicesとEnd of Life Devicesです。
NIC、HBA、ストレージコントローラ、ブートデバイス、GPUやアクセラレータなどは、サーバーモデル名だけでは見えません。とくにストレージやネットワークに関わるEOLデバイスは、アップグレード後の復旧難度が高くなります。
Restricted Deviceは猶予として読む
KB 391170では、Restricted DeviceはESX 9.0ドライバが存在し、BCGにRestrictedとして掲載されるものの、新機能やドライバ拡張は期待できず、修正や回避策も限定的に扱われると説明されています。
これは「問題なし」ではなく、「猶予があるうちに置き換え計画を作る」状態です。移行直後にすべて刷新できない場合でも、Restrictedのまま長期運用するのか、次の更改サイクルで置き換えるのかを決めます。
Restrictedで残す証跡
- BCG上の対象デバイス表示。
- OEMまたはデバイスベンダーの支援回答。
- 代替部品の候補。
- 次回更改時期。
- 障害時に回避策で耐えられる範囲。
EOL Deviceはアップグレード前に置き換える
KB 391170は、EOL Deviceについて、デバイスまたはドライバ、あるいはその両方がリリースから外れ、ESX 9.0で認識されない可能性があると説明しています。さらに、アップグレード時にストレージやデータストアへのアクセス喪失、ネットワークアクセス喪失、以前のホスト設定喪失が起こり得ることにも触れています。
ここは軽く扱えません。EOLデバイスがストレージやネットワーク経路にある場合、アップグレード手順の途中で復旧作業に変わる可能性があります。EOLが確認されたら、VCF 9.1移行の一部ではなく、移行前の置き換えタスクとして扱います。
とくに先に見るI/O
- 管理ネットワークやvMotionに関わるNIC。
- vSANや外部ストレージに関わるHBA、RAIDコントローラ、NVMeデバイス。
- ブートデバイスとストレージパス。
- DPU、GPU、アクセラレータ。
- OEMカスタムイメージやドライバに依存している部品。
I/Oデバイスは「サーバー本体がBCGにあるから大丈夫」と見落とされやすい領域です。ホスト単位ではなく、部品単位で確認します。
OEM確認とRPQ/TQは質問を分けて投げる
- 1対象構成を明示
型番、SKU、CPU、BIOS、ファームウェア、NIC/HBA、ストレージ、vSAN利用有無を添える。
- 2OEMに聞く
ハードウェア支援、推奨版、保守契約上の制限、部品交換、脆弱性対応の継続可否を確認する。
- 3Broadcomに聞く
VCFソフトウェアとしての支援範囲、RPQ/TQ要否、承認時の扱い、提供条件を確認する。
- 4回答を文面で残す
案件番号、回答日、対象型番、対象バージョン、回答者、条件付き回答の条件を保存する。
- 5判断に戻す
標準支援、例外支援、刷新、移行延期のどれに当たるかを移行会議で確定する。
RPQ/TQはOEMのBIOS、ファームウェア、マイクロコード、ハードウェア保守を自動的に保証するものではない。
Skylake、BCG非掲載、Confirm w/Vendor、EOLデバイスが絡む場合、問い合わせ先を一つにまとめると話が混ざります。Broadcom側に確認することと、OEM側に確認することを分けて、回答を別々の証跡として保存します。
この分け方は、障害時にも効きます。VCFソフトウェアの支援範囲はBroadcom側、ハードウェア、BIOS、ファームウェア、マイクロコード、交換部品はOEM側という責任境界が明確であれば、移行後の説明もしやすくなります。
OEMに確認する項目
OEMには、対象サーバーモデルと対象構成を明示して確認します。CPU世代だけを伝えるのではなく、型番、SKU、BIOS、ファームウェア、NIC/HBA、ストレージコントローラ、vSAN利用有無、対象バージョンを添えます。
問い合わせでは、次を分けて聞くと回答を整理しやすくなります。
- 対象モデルはVCF 9.xまたはESX 9.xでハードウェア支援対象か。
- BIOS、ファームウェア、マイクロコードの推奨版はあるか。
- その構成で保守契約上の制限はあるか。
- Confirm w/Vendor表示の場合、標準支援か例外支援か。
- 障害時の部品交換、ファームウェア更新、脆弱性対応は継続されるか。
- 回答の対象期間と対象バージョンはどこまでか。
回答は文面で残す
口頭回答だけで移行判断をしない方が安全です。案件番号、回答日、対象型番、対象バージョン、回答者、条件付き回答の条件を残します。後から「その条件は別モデルだった」とならないよう、ホスト一覧と結び付けます。
Broadcom側に確認する項目
Broadcom側には、VCFソフトウェアとしての支援範囲、RPQ/TQの要否、承認時の扱い、実装手順の提供条件を確認します。とくにSkylakeやDiscontinued、BCG非掲載の継続利用では、通常の移行とは別の確認になります。
KB 428874は、古いEnd of LifeハードウェアのVCF Software Only supportについて、VCFアカウントチームへの相談、RPQ/TQ、実現可能性、ビジネス上の妥当性、VMware管理承認に触れています。この記事では、承認されるかどうかを断定しません。必要になり得る確認事項として扱います。
RPQ/TQを通常ルートにしない
RPQ/TQは、古いハードウェアを通常のサポート対象に戻す魔法の手続きではありません。承認可否、支援範囲、実装条件、OEM支援の有無、刷新期限を一緒に見ます。承認待ちの状態で本番移行日を確定するのは避けた方がよいでしょう。
棚卸し表に落として移行会議で止める
赤と灰のホストが残る場合は、アップグレード手順の細部より先に互換性の確認へ戻る。
最後は、確認結果を会議で読める表に落とします。細かいURLやKB番号だけを並べるのではなく、ホスト単位で「続行」「OEM確認後に続行」「RPQ/TQまたは刷新」「情報不足」のどれかに分類します。
ここまで来ると、移行会議で話す順番も変わります。最初にハードウェア互換性、次にアップグレードパス、次にライセンスやManagement Services、最後に移行後の監視と刷新計画を見ます。互換性が赤のままなら、アップグレード手順の細部を詰める前に止めます。
棚卸し表に入れる列
| 列 | 入れる内容 | 判定の使い方 |
|---|---|---|
| ホスト名 | vCenter上のホスト名、ラック、用途 | 対象漏れを防ぐ。 |
| OEM/モデル | ベンダー、モデル、SKU | BCGとOEM回答の突き合わせに使う。 |
| CPUシリーズ | Cascade Lake、Skylakeなど | Deprecated/Discontinuedの分類に使う。 |
| BCG表示 | Supported、Confirm w/Vendor、Not listedなど | 次の確認先を決める。 |
| vSAN | ReadyNode、OSA/ESA、構成差分 | vSAN固有のリスクを分ける。 |
| I/Oデバイス | NIC、HBA、コントローラ、GPU | Restricted/EOL確認に使う。 |
| OEM回答 | 案件番号、回答日、条件 | ハードウェア支援の証跡にする。 |
| Broadcom確認 | RPQ/TQ要否、支援範囲 | VCFソフトウェア側の証跡にする。 |
| 判定 | 緑、黄、赤、灰 | 移行会議の結論に使う。 |
緑は続行候補、黄はOEM確認後に続行、赤はRPQ/TQまたは刷新、灰は情報不足です。色だけで終わらせず、必ず次のアクションと担当者を入れます。
移行会議で確認する順番
移行会議では、次の順に確認すると混乱しにくくなります。
- 赤と灰のホストを先に読む。
- Skylake、BCG非掲載、EOL I/Oデバイスを別枠で確認する。
- Confirm w/VendorのOEM回答を確認する。
- vSAN ReadyNodeと構成差分を確認する。
- ソフトウェアアップグレード順序に進む。
- VCF 9.1 Express Patchや適用順序を確認する。
- ライセンス、Management Services、運用監視へ進む。
Express Patchや9.1.0.0100の適用順序は、VCF 9.1 Express Patch 01の確認記事でも整理しています。ただし、パッチ適用の前提として、ホストの互換性とI/Oデバイスの状態を先に見ます。
読了後に残すチェック
この記事を読んだ後、すぐにやることは「VCF 9.1へ進む」と決めることではありません。まず、現在の全ホストを棚卸し表に入れ、BCG、KB、OEM回答、Broadcom確認の不足欄を作ります。
資料・確認ログには、公式資料へ戻るための導線をまとめています。公開情報は更新されるため、社内資料へ転記する場合も、確認日とURLをセットで残してください。
更新履歴
- 2026年6月8日
Broadcom KB 428874、KB 318697、KB 391170、BCG、VCF 9.1 Release Notes、VCF 5.2.x to 9.1 Upgrade Guideを確認した。
- 2026年6月8日
Redditなどのコミュニティ投稿は需要シグナルとしてのみ扱い、事実確認の根拠には使わない方針を明記した。
BCGやKBの表示は変わるため、公開後も確認日と参照元を分けて読む。
- 2026年6月8日: Broadcom KB 428874、KB 318697、KB 391170、Broadcom Compatibility Guide、VCF 9.1 Release Notes、VCF 5.2.x to 9.1 Upgrade Guideを確認し、VCF 9.1移行前のハードウェア互換性チェックとして整理しました。
- 2026年6月8日: Redditなどのコミュニティ投稿は需要シグナルとしてのみ扱い、事実確認の根拠には使わない方針を明記しました。
次に読むなら
参照した主な情報源
- Broadcom KB 428874, Deprecated CPU Systems / Servers in ESX 9.0 and implications for support
https://knowledge.broadcom.com/external/article/428874/deprecated-cpu-systems-servers-in-esx-9.html
- Broadcom KB 318697, CPU Support Deprecation and Discontinuation In VCF Releases
https://knowledge.broadcom.com/external/article/318697/cpu-support-deprecation-and-discontinuat.html
- Broadcom KB 391170, Deprecated devices in ESX 9.0 and implications for support
https://knowledge.broadcom.com/external/article/391170/
- Broadcom Compatibility Guide
https://compatibilityguide.broadcom.com/
- VMware Cloud Foundation Blog, VCF 9.0 Server Certification: Preserving Your Hardware Investment and giving the best ROI, 2026年2月25日
https://blogs.vmware.com/cloud-foundation/2026/02/25/vcf-9-0-server-certification-preserving-your-hardware-investment-and-giving-the-best-roi/
- VMware Cloud Foundation Blog, Modernizing Infrastructure: VMware Cloud Foundation 5.2.x to 9.1 Upgrade Guide, 2026年6月5日
https://blogs.vmware.com/cloud-foundation/2026/06/05/modernizing-infrastructure-vmware-cloud-foundation-5-2-x-to-9-1-upgrade-guide/
- VMware Cloud Foundation 9.1 Release Notes, What's New
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.html