追記: 2026年6月6日の最新情報
2026年6月5日にVMware Cloud Foundation Blogが、VCF 5.2.xから9.1へのアップグレードガイドを公開しました。旧vSphere 8.xやNSX 4.xを含む環境でDiagnosticsを使う場合も、Findingsの確認だけで終わらせず、AriaからVCF Operationsへの移行、VCF Management Services、NSX/vCenter Server/ESXiを含む更新順序と合わせて読む必要があります。
- Diagnostics Findingsは、既存環境の状態を把握する入口として使う。
- アップグレード可否は、Management Servicesの導入、ライセンス、ソフトウェアデポ、ログ管理、データプレーン更新の順序と分けて判断する。
- VCF 5.2.xから9.1へ進む環境では、確認日、対象コンポーネント、Findings更新方式を運用メモに残す。
公式ガイドはVMware Cloud Foundation 5.2.x to 9.1 Upgrade Guideです。Diagnosticsの結果は「移行前に見る材料」として扱い、最終判断は互換性、バックアップ、既知問題、サポート条件と合わせて確認してください。
このテーマをもう少し広げて見るなら、VCF 9.1のAPI-first自動化を導入前に確認する：Real-Time Metrics、vCenter Utilization、SDK/PowerCLIの実務ポイント と vSphere Foundation 9.1リソースを導入前に読む：NVMe Memory Tiering、Live Patching、VCFとの違い も合わせて確認してください。Diagnosticsで見つけた課題をAPI-first運用や自動化の確認へつなげられる。
3行まとめ
vSphere 8.xとNSX 4.xを含む環境でも、VCF Operations 9.xのDiagnostics Findingsを移行準備の入口にできます。
Diagnostics Findings、VCF Health、証明書管理、ログFindings、KB参照は前提が異なります。
8.18.x、9.0.x、9.1.xではFindingsの範囲と更新方式が変わるため、確認タイミングを運用手順に入れます。
確認日、ライセンス、ログ連携、閉域網の扱いを分けて記録すると、導入後の期待違いを減らせます。
- VCF Operations 9.xのDiagnostics Findingsは、vSphere 8.xとNSX 4.xを含む既存環境でも確認対象にできるとBroadcom/VMwareの公式ブログが説明しています。
- ただし、Diagnostics Findings、VCF Health、証明書管理、ログFindings、KB参照は同じ機能ではありません。VCF/VVFライセンス、ログ連携、閉域網の扱いを分けて確認する必要があります。
- 8.18.x、9.0.x、9.1.xではFindingsの範囲と更新方式が変わるため、導入判断では「見える/見えない」だけでなく、更新タイミングと運用手順まで決めておくのが安全です。
VCF 9.1の一般提供後、導入前の関心は「新機能をどう使うか」から、「既存のvSphere 8.x、NSX 4.x、運用ログ、ライセンスのまま、どこまで移行準備に使えるか」へ移っています。直近では、VCF PowerCLI 9.1のOAuth認証や、VCF Operationsで管理VMのリソース割り当てを確認する流れを追いました。今回はそこから一段下げて、VCF Operations 9.1のDiagnosticsを旧コンポーネント環境で使う前に、導入担当者が確認すべき点を整理します。
Diagnosticsは「VCF 9.1へ完全移行した後に初めて見る画面」ではありません。公式ブログは、vSphere 8.xとNSX 4.xを使う顧客でもVCF Operations 9.xを導入またはアップグレードし、対象統合のFindingsを利用できると説明しています。一方で、Findingsの種類、ログ連携、KB参照、VCF Health、証明書管理は前提が異なります。同じチェック項目としてまとめすぎると、期待していた問題検出が出ない、閉域網で推奨対応を読めない、といったズレが起きます。
この記事は2026年6月3日JST時点で、VMware Cloud Foundation Blog、Broadcom Knowledge Base、VCF 9.1 FAQ、VCF Operations Datasheetを確認して作成しています。Broadcom Watch JapanはBroadcom Inc.および関係会社とは非提携です。導入やサポート判断では、必ずBroadcom/VMwareの一次情報と契約条件を確認してください。
旧vSphere/NSX環境でDiagnosticsはどこまで使えるか
VCF Operations 9.xを導入またはアップグレードし、vSphere 8.xやNSX 4.xに対するDiagnostics Findingsを確認します。
対象統合、認証情報、ログ連携、KB参照経路、ライセンス範囲がそろっているかを先に確認します。
旧コンポーネントの全機能をVCF 9.1相当に変える説明や、すべての問題を自動解決する説明とは分けます。
旧環境でも使えることと、すべてのFindingsが同じ条件で動くことは同じではありません。
まず押さえたいのは、VCF Operations 9.x Diagnosticsの話と、VCF 9.1フルスタック導入の話を分けることです。公式ブログ「Diagnostics for VMware Cloud Foundation (VCF) 9.1 with Old Versions of VCF Components」は、vSphere 8.xとNSX 4.xの環境でも、VCF Operations 9.xをインストールまたはアップグレードし、これらの統合に対するFindingsが引き続き機能すると説明しています。
これは、既存環境をすぐにVCF 9.1へ上げられない企業にとって大きな意味があります。Diagnosticsを使う目的が「現行環境の既知問題、設定変更、アップグレード推奨を先に洗い出すこと」であれば、VCF 9.1の全コンポーネント移行を待たずに、運用確認の入口として使える可能性があります。
vSphere 8.xとNSX 4.xでも確認対象になる理由
根拠: 公式ブログが示す対象
Broadcomの説明では、VCF Operationsに含まれるDiagnostics Findingsは、VCFとVMware vSphere Foundationの顧客の双方でサポートされます。vSphere 8.xとNSX 4.xの環境では、旧コンポーネントに対して設定変更やアップグレードを推奨するFindingsを確認でき、9.xへのアップグレード推奨も得られるとされています。
つまり、Diagnosticsは「現行環境の棚卸し」と「VCF 9.x移行準備」の間に置ける機能です。既存環境で起きている問題を把握しないままアップグレード計画だけを作るより、先にFindingsで既知問題、構成上の注意、セキュリティアドバイザリ、証明書や運用状態に関する情報を確認した方が、移行前のリスクを分解しやすくなります。
条件: 自動解決ではなく確認入口として扱う
ただし、ここで確認できるのは「公式情報でサポートされる範囲のFindings」です。vSphere 8.x/NSX 4.x環境のあらゆる問題を自動的に解決する機能ではありません。特に、ログFindingsを使う場合はログ連携が必要であり、KB参照や推奨対応を読むにはインターネット接続や社内の参照手順が絡みます。
先に確認すべき3つの分岐
確認項目: 現行環境、運用機能、更新運用
導入前の確認は、次の3つに分けると整理しやすくなります。
- 現行環境の確認では、vSphere 8.x、NSX 4.x、vSAN、vCenter、ESXiの版数と統合状態を見ます。判断のポイントは、Findingsの対象になる統合が正しく接続されているかです。
- 運用機能の確認では、VCF/VVFの契約範囲、VCF Health、証明書管理、ログ管理を見ます。Diagnostics FindingsとVCF専用機能を混同していないかを確認します。
- 更新運用の確認では、Management Pack、Diagnostics Content Pack、パッチ適用、KB参照を見ます。新しいFindingsをどの頻度で取り込むかが判断のポイントです。
この3つを一つのチェック表に押し込むと、問題が見つからなかった時の原因が分かりにくくなります。Findingsが出ない理由は、環境に問題がないからとは限りません。統合が切れている、ログが入っていない、権限や証明書が古い、Findings更新を取り込んでいない、という可能性もあります。
導入前にそろえるVCF Operations側と旧コンポーネント側の前提
Diagnosticsが使えるバージョンか、Management PackやContent Packの状態が確認できるかを見ます。
vCenter、ESXi、vSAN、NSX、SDDC Managerなどのクラウドアカウント、証明書、権限が有効かを確認します。
ログFindingsを使う場合は、Operations for Logsまたは統合ログ基盤に対象ログが入っているかを確認します。
推奨対応やKBリンクを読むためのインターネット接続、プロキシ、社内承認フローを準備します。
vSphere 8.x、NSX 4.x、vSAN、vCenter、ESXiのバージョンとサポート状態を記録します。
導入前の確認を分けておくと、Findingsが少ない時に収集不足、ログ不足、対象外のどれかを切り分けやすくなります。
VCF Operations 9.x Diagnosticsを既存環境へ入れる時は、製品名だけを見て「9.xだから新しい」と判断しない方が安全です。確認すべき対象は、VCF Operations側の状態と、接続されるvSphere/NSX側の状態に分かれます。
VCF Operations 9.x側で見る項目
確認項目: Operations側の収集状態
VCF Operations側では、まずDiagnosticsが有効なバージョンに上がっているか、対象コンポーネントへの統合が残っているかを確認します。Broadcom KB 371661は、VCF Operations 9.xのDiagnosticsではSkyline Advisor由来のデータセットを含み、パッチベースと構成ベースのFindingsを扱うと説明しています。これにより、8.18.x時代よりも現行環境の構成確認に寄った使い方がしやすくなります。
注意点: ログFindingsはログ連携が前提
あわせて、ログ管理との連携を確認します。Broadcom KB 375104は、ログFindingsがOperations for Logsに収集されたログを前提にすること、Refresh Findingsでオンデマンドにログベースの確認を実行できることを説明しています。ログ転送が未設定のまま「Diagnosticsを入れたのにログ系のFindingsが少ない」と判断すると、切り分けを誤ります。
VCF Operations側で最初に見るべき項目は、次のようなものです。
- VCF Operationsのバージョンが9.x、または記事で扱う9.1.x相当の機能確認に適した状態か。
- vCenter、ESXi、vSAN、NSX、SDDC Manager、VCF Automationなど、対象統合のクラウドアカウントや認証情報が有効か。
- 証明書、サービスアカウント、権限、時刻同期が原因で収集が止まっていないか。
- Operations for Logsまたは統合ログ基盤に、Findingsで使いたい対象ログが入っているか。
- KBリンクや推奨対応を読むためのインターネット接続、プロキシ、社内手順が準備されているか。
vSphere 8.x/NSX 4.x側で見る項目
条件: 収集状態を現在の環境に合わせる
旧コンポーネント側では、バージョン番号だけでなく「Operationsが見られる状態か」を確認します。vSphere 8.x、NSX 4.xの環境であっても、統合が古い資格情報のままならFindingsは期待通りに出ません。証明書更新やサービスアカウント変更後にクラウドアカウント統合を再接続していない場合も、収集情報が古いまま残る可能性があります。
KB 375104は、環境を更新したのにProperty Findingsが残る場合、クラウドアカウント統合の再確立が必要になることがあると説明しています。これは実務上かなり大事です。Findingsを「現在の真実」と見る前に、そのFindingsがどの収集状態から出ているのかを確認しなければなりません。
確認項目: 旧環境の母集団
旧環境を対象にする場合、次の観点を最初の実行前チェックに入れておくと、後のレビューが楽になります。
- vCenter/ESXiでは、版数、証明書、権限、管理対象ホストを確認します。ここを見落とすと、収集対象が欠け、Findingsの母集団がずれます。
- NSXでは、NSX Manager連携、認証情報、ネットワーク到達性を確認します。ここが崩れると、NSX関連Findingsが出ない、または古い情報で残る可能性があります。
- vSANでは、クラスタ状態、ログ、アラート、容量情報を確認します。ストレージ系の問題検出や推奨対応に影響します。
- ログでは、収集先、保持期間、取り込み遅延を確認します。Refresh Findingsを実行しても、必要なログがなければログFindingsは不足します。
- サポート手順では、KB参照、SR作成、社内承認を確認します。推奨対応を読めても、実行判断に進めない状態を避けるためです。
この段階では、VCF 9.1へ移行するかどうかを急いで決める必要はありません。むしろ、Diagnosticsを使って「移行前に直すもの」「移行計画に入れるもの」「旧環境では許容するもの」を分けるのが目的です。
VCF/VVFライセンスで何が違うか
ライセンス差は単純な優劣ではなく、契約、構成、利用する機能で確認条件が変わります。
Diagnosticsを旧環境で使う時に混乱しやすいのが、VCFとVVFの境界です。Broadcom KB 375104は、Diagnostics FindingsはVCFとVVFの双方で利用できる一方、VCF HealthはVCF顧客向けであると説明しています。公式ブログも、VCFライセンスを持つ顧客ではVCF Healthや証明書管理などの機能に触れることになると説明しています。
ここでのポイントは、「Diagnosticsが見える」ことと「VCF Operationsのすべての運用機能を同じ条件で使える」ことを分けることです。
Diagnostics FindingsはVCF/VVF双方で確認する
根拠: FindingsとVCF Healthを分ける
Findingsは、既知問題、設定、パッチ、セキュリティアドバイザリ、ログに基づく問題候補を運用者に示す機能です。VVF環境でも利用対象になるため、vSphere中心の環境であっても、現行運用の棚卸しに使える余地があります。
注意点: 契約上の範囲は別に確認する
ただし、Findingsを見られることは、契約上のサポート範囲や高度な運用機能が同じであることを意味しません。VCF 9.1 FAQでは、VCF OperationsがVCFの構成要素として位置づけられ、ライセンス管理やFleet単位の運用にも関係することが説明されています。ライセンス、サポート、Advanced Services、VCF専用機能は、契約と環境構成に沿って別途確認する必要があります。
VCF Healthや証明書管理は別枠で見る
条件: VCF専用機能と既存環境確認を混ぜない
VCF Healthや証明書管理は、旧環境のDiagnostics Findingsと同じ粒度で語ると誤解が生まれます。VCFライセンスを持つ環境では、VCF Health、証明書管理、統合された運用ダッシュボードのような機能が関係します。一方、VVFやvSphere中心の環境では、Diagnostics Findingsを使った既知問題の把握が主目的になりやすいはずです。
評価基準: 機能ごとに記録行を分ける
導入計画では、次のように行を分けて記録するのが実務的です。
- Diagnostics Findingsは、VCF環境ではスタック全体の運用確認に組み込み、VVFや旧vSphere中心の環境では現行環境の棚卸しに使います。
- VCF Healthは、VCF環境のヘルス確認として扱います。VVFや旧vSphere中心の環境では、対象外なのか契約・構成次第なのかを別途確認します。
- 証明書管理は、VCF運用機能として計画に入れます。既存環境では、現在の証明書管理手順と連携できるかを確認します。
- ログFindingsは、VCF環境ではログ統合を標準運用に入れ、既存環境ではログ転送と保持期間を先に整えます。
- KB参照は、サポート手順と連動させます。閉域網では、社内参照手順を別に用意します。
この分け方をしておくと、導入レビューで「VVFでもDiagnosticsは使えるのか」「VCF Healthも同じように見えるのか」という質問が来ても、機能ごとに答えられます。
Findingsの種類と更新タイミングを分けて運用する
- 1Property Findingsを確認
4時間ごとの収集を前提に、設定変更やパッチ適用直後のタイムラグを記録します。
- 2Log Findingsを確認
ログ管理が統合され、対象ログが収集されている状態でRefresh Findingsを使います。
- 3HybridやVMSA関連を分ける
ログ、構成、セキュリティアドバイザリのどの条件で出ているFindingsかを確認します。
- 4レビュー結果を記録
実行する推奨対応、移行計画へ入れる対応、保留する対応を分けてチケット化します。
Refresh Findingsで更新できる範囲と、定期収集を待つ範囲を混同しないことが重要です。
Diagnosticsで一番大事なのは、Findingsを一枚岩として見ないことです。公式ブログとKBを読む限り、少なくともプロパティFindings、ログFindings、ハイブリッドFindings、VMSA関連Findings、構成ベースのFindingsが関係します。運用上は、これらの発見条件と更新条件を分ける必要があります。
プロパティFindingsは4時間ごとの収集として考える
根拠: 自動収集とRefresh Findingsは同じではない
公式ブログは、8.18.x時代のProperty Findingsが自動的に4時間ごとに生成され、Refresh Findingsでは更新されないと説明しています。KB 375104でも、Active Findingsの文脈でプロパティベースのシグネチャが4時間ごとにスキャンされることが説明されています。
注意点: 変更直後の画面を断定しない
実務上は、Findings画面を開いてすぐに「いまの状態」と断定しないことが大事です。証明書を更新した、NSX側の設定を変えた、vCenterをパッチ適用した、クラウドアカウント統合を再接続した、という直後には、収集タイミングとFindings更新のタイムラグを考慮する必要があります。
確認項目: 初回レビューで残す記録
導入後の初回レビューでは、次のように記録すると、後で説明しやすくなります。
- 何時に統合を再接続したか。
- 何時に対象コンポーネントの設定変更やパッチ適用を行ったか。
- 何時のFindings画面をレビューしたか。
- Property Findingsなのか、Log Findingsなのか。
- Findingsの推奨対応を実行したのか、保留したのか。
ログFindingsはRefresh Findingsとログ連携が前提
条件: ログ管理と対象ログを先にそろえる
ログFindingsは、プロパティFindingsとは違う運用です。KB 375104は、ログベースの確認を行うにはログ管理がインストールされ、環境に統合されている必要があると説明しています。また、Refresh Findingsを使って、特定のコンポーネント、機能、能力に絞ってログスキャンを実行できるとしています。
つまり、ログFindingsを使いたいなら、次の前提を先に確認する必要があります。
| 確認項目 | なぜ必要か |
|---|---|
| ログ収集先が決まっている | Findingsが見るログが入っていなければ検出できない |
| 対象コンポーネントのログが転送されている | vCenter、ESXi、NSX、vSANなどの範囲が欠けると結果が偏る |
| 保持期間が運用目的に合っている | 過去事象を追いたい場合、ログが消えていると確認できない |
| Refresh Findingsの実行権限がある | 手動実行できなければ初回確認や障害後確認に使いにくい |
| 実行負荷と時間を見積もっている | ログ量が多い環境ではクエリ時間が運用に影響する可能性がある |
公式KBは、ログFindingsやAudit Events、vMotion monitoringがOperations for Logsのデータを問い合わせるため、日常運用への影響を把握する必要があるという趣旨も示しています。特に大規模環境では、Refresh Findingsを「気になった時に何度も押す」運用ではなく、実行タイミングと対象を決めて使う方が安全です。
KB参照にはインターネット接続が絡む
根拠: 評価とKB参照は別の動き
Diagnosticsそのものの評価ロジックと、KB参照は分けて考えます。KB 375104は、環境評価そのものはインターネット接続を必要としない一方、Findingsに紐づくKBへのアクセスは必要になると説明しています。また、診断シグネチャの更新は製品パッチとして提供され、ダウンロードが必要になります。
注意点: 閉域網では参照手順を別に用意する
閉域網や厳格なプロキシ環境では、ここが実務上の壁になります。Findingsが出ても、推奨対応やKBをその場で読めなければ、担当者は別端末で確認する、社内ナレッジへ転記する、承認されたURLだけを通す、といった手順が必要です。
確認項目: KBと更新取得の経路
導入前チェックでは、次の問いを残しておくとよいでしょう。
- VCF OperationsからKBリンクへ直接アクセスできるのか。
- 直接アクセスできない場合、誰がどの端末でKBを確認するのか。
- KB番号、Findings名、対象オブジェクト、推奨対応を社内チケットへどう転記するのか。
- パッチやManagement Pack、Diagnostics Content Packの取得手順は承認済みか。
- 監査上、外部KBを参照した履歴をどう残すのか。
Diagnosticsを閉域網で使う場合、単に「インターネット接続なしでも評価できる」とだけ覚えるのは危険です。評価、KB参照、更新取り込みは別の作業です。
8.18.x、9.0.x、9.1.xで変わる更新方式を確認する
- 8.18.x
Operationsがすでに収集していた限られたデータを使い、主にビルドやバージョンベースのルールを扱います。
- 9.0.x
独自のデータ収集が加わり、Skyline Advisor由来のルール群やハイブリッドFindingsを確認する流れになります。
- 9.1.x
Diagnostics Content Packが導入され、Management PackとContent Packを分けて更新方式を見ます。
- 運用時の確認
Findings Catalog、Broadcom KB、Content Pack更新状況を確認し、数字を固定値として扱わないようにします。
Findingsの件数や範囲は、製品パッチ、Content Pack、KB更新、セキュリティアドバイザリに応じて変わります。
公式ブログは、Diagnosticsの進化を8.18.x、9.0.x、9.1.xで分けて説明しています。この部分は、導入担当者にとって単なる履歴ではありません。いま見えているFindingsがどの世代の仕組みに基づくのか、今後の更新をどの手順で取り込むのかを判断する材料になります。
Findings数とdatasetは固定値として暗記しない
根拠: 世代ごとに収集方式が違う
公式ブログによると、8.18.xはOperationsにおけるDiagnostics Management Packの最初のバージョンで、Operationsがすでに収集していた限られたデータを使い、主にビルドやバージョンベースのルールを扱っていました。8.18.0では約250件のプロパティFindingsがあり、後続バージョンでVMSAルールが追加され、ログベースFindingsも存在しました。
9.0.xでは、Diagnostics Management Packの第2世代として独自のデータ収集を行い、Skyline Advisorにあったルール群を作れるようになったとされています。公式ブログは、9.0.xに約600件のプロパティFindings、約100件のログFindings、さらにログとプロパティチェックを組み合わせるハイブリッドFindingsがあると説明しています。
9.1.xでは、第3世代としてDiagnostics Content Packが導入され、Management PackとContent Packの分離が説明されています。公式ブログは、9.1.xで約700件のプロパティFindingsと約300件のログFindingsがあるとしています。
注意点: 数字は確認時点の公式説明として扱う
ただし、これらの数字は運用設計で固定値として暗記するものではありません。Findingsは製品パッチ、Management Pack、Content Pack、KB更新、サポートでのトレンド、セキュリティアドバイザリに応じて変わります。記事や設計書には「確認時点の公式説明」として書き、実環境ではFindings CatalogやBroadcom KBで更新状況を確認する方が現実的です。
Diagnostics Content Pack更新を運用項目に入れる
条件: 本体更新とコンテンツ更新を分ける
9.1.xで重要なのは、Diagnostics Content PackをManagement Packから分け、より頻繁にリリースできるようにするという方向性です。公式ブログは、Management Packはスケジュールされた製品リリースで更新される一方、Content Packはより頻繁に出せることを目標にしていると説明しています。
これは、既知問題やセキュリティアドバイザリへの追従を重視する環境では大きな変更です。パッチ適用だけを月次で見ていた運用では、Diagnosticsのルール更新を取り逃がす可能性があります。
確認項目: 定例運用に入れるバージョン情報
定例運用には、次の確認を入れておくのがよいでしょう。
- VCF Operations本体のバージョンとパッチレベル。
- Diagnostics Management Packのバージョン。
- Diagnostics Content Packのバージョン。
- Broadcom KB 371661の更新日と最新バージョン情報。
- Findings Catalogで新規/変更Findingsがないか。
- 新しいVMSA、サポートKB、既知問題が運用対象に影響するか。
特にセキュリティアドバイザリをFindingsで追う場合、更新取り込みの遅れは「問題がない」ではなく「見ているルールが古い」につながります。運用レビューでは、Findings件数だけでなく、Findingsを生成するコンテンツの鮮度を確認するべきです。
導入前から定例運用までのチェックリスト
- 導入前
環境種別、コンポーネントバージョン、目的、統合、ログ、KB参照経路、担当者を確認します。
- 初回実行後
Active Findingsの種類、対象オブジェクト、推奨対応、KBリンク、収集時刻を確認します。
- 定例運用
重大度、対応状況、保留理由、再発状況、移行計画への反映を継続的に見直します。
- アップデート時
Management Pack、Content Pack、KB更新、VCF Operationsのバージョン変更後にFindingsの変化を確認します。
初回レビューだけで判断せず、更新後に増えたFindingsや消えたFindingsの理由まで記録します。
ここまでの内容を、導入前、初回実行後、定例運用に分けてまとめます。Diagnosticsは一度入れて終わりの機能ではありません。旧環境で使うほど、更新、統合、ログ、KB参照、契約範囲を定期的に見直す必要があります。
導入前チェック
確認項目: 初回導入前に決めること
導入前は、次の順番で確認すると迷いにくくなります。
- 対象環境がVCFなのか、VVFなのか、vSphere中心の既存環境なのかを記録する。
- vSphere 8.x、NSX 4.x、vSAN、vCenter、ESXiのバージョンとサポート状態を確認する。
- VCF Operations 9.xを導入またはアップグレードする目的を、移行準備、既知問題確認、セキュリティ確認、ログ調査のどれに置くか決める。
- クラウドアカウント統合、証明書、サービスアカウント、権限を確認する。
- ログFindingsを使う場合は、Operations for Logsまたはログ統合の対象、保持期間、転送状態を確認する。
- KB参照、パッチ取得、Content Pack更新に必要なネットワーク経路を確認する。
- Findingsのレビュー担当、推奨対応の承認者、チケット化ルールを決める。
評価基準: 期待値を下げて役割を決める
この段階で「Diagnosticsを入れれば自動で全部わかる」という期待値を下げておくことが大切です。Diagnosticsは、運用者の判断を置き換えるものではなく、既知問題と確認観点を集約する入口です。
初回実行後チェック
確認項目: Findingsの数より理由を見る
初回実行後は、Findingsの数だけを見るのではなく、出ているFindingsと出ていないFindingsの理由を確認します。
| 確認すること | 見る理由 |
|---|---|
| Active Findingsの種類 | プロパティFindingsとログFindingsのどちらが中心かを把握する |
| 対象オブジェクト | vCenter、ESXi、NSX、vSANなどの母集団が期待通りかを確認する |
| 推奨対応 | すぐ実行するもの、移行計画へ入れるもの、保留するものを分ける |
| KBリンク | 社内環境で参照できるか、チケットへ記録できるかを確認する |
| 収集時刻 | 設定変更後のタイムラグや再接続漏れを確認する |
| ログFindings | Refresh Findingsの対象、実行時間、ログ保持期間を確認する |
注意点: Findingsを運用の言葉へ変換する
初回レビューで大事なのは、Findingsの数を減らすことではなく、Findingsを運用の言葉へ変換することです。たとえば「このFindingsはアップグレード計画へ入れる」「これは旧環境では許容する」「これは証明書更新後に再確認する」といった分類を作ります。
定例運用と更新時チェック
確認項目: 定期的に見るリズム
定例運用では、次のようなリズムを作ると、Diagnosticsを移行準備と日常運用の両方に使いやすくなります。
- 週次または月次で、Active Findingsと新規Findingsを確認する。
- パッチ適用、証明書更新、NSX変更、vCenter更新の後に、クラウドアカウント統合と収集状態を確認する。
- VMSAや重要KBが出た時に、DiagnosticsのFindings更新が追従しているか確認する。
- ログFindingsを使う障害後レビューでは、ログ保持期間とRefresh Findingsの実行範囲を記録する。
- VCF 9.1または9.xへのアップグレード計画と、旧環境で残す既知問題を分けて管理する。
VCF 9.1全体の導入前チェックを進める場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-13-vcf-91-upgrade-api-ip-check/">VCF 9.1を導入前に確認する記事</a>も合わせて見ると、API-first、アップグレード計画、管理サービスIPの確認と接続できます。VCF Operationsで何を見るかを具体化したい場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-15-vcf-operations-vcenter-nsx-resource-allocation/">vCenter Server VMとNSX VMのリソース割り当て確認</a>も関連します。
実務上の注意点：未確認情報と公式情報を混ぜない
公式ブログ、Broadcom KB、VCF 9.1 FAQ、TechDocs、契約文書、サポート回答を判断の土台にします。
コミュニティや専門メディアの話題は需要シグナルとして扱い、本文や社内資料では断定に使いません。
KB参照、パッチ取得、Content Pack更新、サポート手順を、ネットワーク制約と社内手順に合わせて確認します。
旧環境でDiagnosticsを使う価値は、移行を急がせることではなく、移行前に潰す運用課題を分けることにあります。
公式情報で確認できる範囲と、現場で追加確認が必要な範囲を分けて記録します。
VCF 9.1まわりでは、コミュニティや専門メディアで、要件、ライセンス、アップグレード、管理サービス、IPアドレス、旧環境対応に関する話題が続いています。これらは需要シグナルとして有用です。読者が何に困っているか、どの確認表が必要かを知る手掛かりになります。
一方で、実際の記事や社内資料では、公式ブログ、Broadcom KB、VCF 9.1 FAQ、TechDocs、契約文書、サポート回答を事実認定の土台にする必要があります。Diagnosticsが旧環境で使えるという説明も、ライセンス機能の境界も、ログFindingsの条件も、最終的には一次情報で確認するべきです。
特に次の点は、噂や社内伝聞だけで決めない方が安全です。
- VCF/VVFで利用できる機能範囲。
- VCF Health、証明書管理、ライセンス管理の対象。
- 旧vSphere/NSX環境でサポートされる統合範囲。
- Diagnostics Content PackやManagement Packの提供方法。
- 閉域網でのKB参照、パッチ取得、サポート手順。
- VCF 9.1へのアップグレード可否、前提バージョン、移行手順。
旧環境でDiagnosticsを使う価値は、移行を急がせることではありません。むしろ、いまの環境で見えている既知問題と、9.xへ進む前に潰すべき運用課題を分けることにあります。
次に読むなら
Broadcomの公式発表、VCF 9.1の製品更新、VMware Cloud Foundationまわりの確認表を継続して追う場合は、<a href="https://avgo-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>で更新通知を受け取れます。本文の判断材料を読んだ後の補助導線として使ってください。
更新履歴
- 2026年5月28日
VMware Cloud Foundation Blogで、旧バージョンのVCFコンポーネント環境におけるDiagnostics 9.1の扱いが説明されました。
- 2026年6月3日
VMware Cloud Foundation Blog、Broadcom Knowledge Base、VCF 9.1 FAQ、VCF Operations Datasheetを確認しました。
- 実環境へ適用する前
Findings、ライセンス、KB、Content Pack、サポート条件は、公式ページと契約条件で再確認します。
仕様やKBは更新されるため、運用判断では確認日と参照元を残しておくと説明しやすくなります。
- 2026年6月3日: VMware Cloud Foundation Blog、Broadcom Knowledge Base、VCF 9.1 FAQ、VCF Operations Datasheetを確認し、VCF Operations 9.1 Diagnosticsを旧vSphere/NSX環境で使う前の確認事項を整理しました。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, "Diagnostics for VMware Cloud Foundation (VCF) 9.1 with Old Versions of VCF Components"
https://blogs.vmware.com/cloud-foundation/2026/05/28/diagnostics-for-vmware-cloud-foundation-vcf-9-1-with-old-versions-of-vcf-components/ 確認日: 2026年6月3日
- Broadcom Knowledge Base, "Questions and Answers for Diagnostics for VMware Cloud Foundation"
https://knowledge.broadcom.com/external/article/375104 確認日: 2026年6月3日
- Broadcom Knowledge Base, "Diagnostics for VMware Cloud Foundation Findings"
https://knowledge.broadcom.com/external/article/371661/diagnostics-for-vmware-cloud-foundation.html 確認日: 2026年6月3日
- VMware, "VCF 9.1 Frequently Asked Questions: May 28, 2026"
https://www.vmware.com/docs/vmware-cloud-foundation-9-1-general-faqs 確認日: 2026年6月3日
- VMware, "Datasheet for VMware Cloud Foundation Operations"
https://www.vmware.com/docs/vmw-vcf-operations-datasheet 確認日: 2026年6月3日
- VMware Cloud Foundation Blog, "Scale, Simplify, and Secure Your Private Cloud Operations with VCF 9.1"
https://blogs.vmware.com/cloud-foundation/2026/05/05/scale-simplify-and-secure-your-private-cloud-operations-with-vcf-9-1/ 確認日: 2026年6月3日