3行まとめ
このテーマをもう少し広げて見るなら、VCF Operations 9.1 Diagnosticsを旧vSphere/NSX環境で使う前に：Findings、ログ連携、更新方式を確認する と VCF 9.1のAPI-first自動化を導入前に確認する：Real-Time Metrics、vCenter Utilization、SDK/PowerCLIの実務ポイント も合わせて確認してください。管理VMの割り当て棚卸しと、DiagnosticsのFindingsやログ確認を切り分けて読めるため。
vCenter Server VMとNSX Manager VMを分け、vCPU、メモリ、ディスク容量を一覧化する。
取得した値は、性能問題の結論ではなく、移行前に割り当てを説明するための確認表として扱う。
Upgrade Planning Tool、KB 440630、TechDocsと合わせて、容量、IP、順序、メンテナンス計画へ落とす。
List viewは結論そのものではなく、VCF 9.1計画に必要な前提をそろえる入口になる。
- VCF Operationsでは、vCenter Server VMとNSX Manager VMをList viewで分けて抽出し、vCPU、メモリ、ディスク容量の割り当て値を棚卸しできる。
- これは性能診断ではなく、VCF 9.1移行前に「管理VMへ何を割り当てているか」をそろえるための確認表として読むのが実務的だ。
- 取得した一覧は、VCF 9.1 Upgrade Planning Tool、Broadcom KB 440630、TechDocsのInfrastructure Operations/Cost and Capacity Managementと突き合わせて、容量・IP・順序・メンテナンス計画へ落とす。
VMware Cloud Foundation公式ブログは2026年6月1日、VCF OperationsでvCenter Server VMとNSX Manager VMのリソース割り当てを取得する手順を紹介した。Broadcom Watch Japanでは、この投稿を単なるUI操作メモではなく、VCF 9.1へ進む前の管理VM棚卸しとして読む。
直近のVCF 9.1関連記事では、API-firstや管理サービスIPを含む導入前チェックと、VCF Edge 9.1のZero Touch Provisioningを扱った。今回はその続きとして、既存環境の「管理コンポーネントに割り当て済みのリソース」をどう見える化するかに絞る。
Broadcom Watch JapanはBroadcomおよびVMware by Broadcomとは非提携の独立した情報整理サイトであり、この記事は投資助言、契約判断の代行、公式サポート回答ではない。作業前には必ず自社の契約、サポート窓口、最新のBroadcom公式資料を確認してほしい。
管理VMの割り当て確認がVCF 9.1計画で重要になる理由
- 11. VCF 9.1の方向性
プライベートクラウド、AI、Kubernetes、既存ワークロードを支える基盤として全体像を確認する。
- 22. 既存管理基盤
vCenter Server、NSX、VCF Operations、SDDC Manager、管理サービス、IPレンジ、FQDNを棚卸し対象として見る。
- 33. 管理VMの割り当て表
管理コンポーネントに割り当て済みのvCPU、メモリ、ディスク容量を説明できる形にする。
- 44. 計画への接続
容量、ネットワーク、作業順序、担当範囲を決める前提として一覧を使う。
VCF 9.1の導入判断では、製品機能だけでなく、既存環境の管理VMに何を割り当てているかを説明できる状態が重要になる。
VCF 9.1では、プライベートクラウド、AI/モダンアプリ、運用統合、ライフサイクル管理が一つの文脈で語られることが増えた。Broadcomの2026年5月5日の公式発表でも、VCF 9.1は本番AIワークロードやKubernetes、既存ワークロードを支えるプラットフォームとして位置づけられている。
ただし、導入担当者が最初に困るのは大きな製品メッセージではない。実際には、既存のvCenter Server、NSX、VCF Operations、SDDC Manager、管理サービス、ライセンスサーバー、IPレンジ、FQDN、メンテナンス時間をどう並べるかで止まる。公式発表の価値を現場の作業計画へ落とすには、まず現状の管理VMを数字で見えるようにする必要がある。
読者の出発点はアップグレード前の棚卸し
今回の公式ブログが扱うのは、VCF OperationsのList viewを使い、vCenter Server VMとNSX Manager VMの割り当て済みリソースを取り出す方法だ。ここで重要なのは、取得する値が「今どれだけ使っているか」ではなく「VMに何が割り当てられているか」である点だ。
この違いを混同すると、記事の使い方を誤る。CPU使用率やメモリ圧迫を調べたいなら、時系列メトリック、アラート、ワークベンチ、ログ、ポリシー、しきい値を見る必要がある。今回の一覧は、その前段にある構成棚卸しだ。
判断に使う問い
たとえば、次のような問いに答えるために使う。
- どのvCenter Server VMに何vCPUを割り当てているか。
- NSX Manager VMのメモリ割り当てがサイトや管理ドメインごとにばらついていないか。
- ディスク容量の割り当てを、アップグレード前のバックアップ、ログ、スナップショット方針と分けて見られるか。
- 複数サイトの管理VMを合計したとき、運用基盤側の余力と説明できる数字になっているか。
- メンテナンスウィンドウやアップグレード順序を組む前に、棚卸し表として関係者へ渡せるか。
なぜvCenter Server VMとNSX Manager VMを先に見るのか
vCenter ServerとNSXは、VCF環境の管理とネットワークを支える中心的なコンポーネントだ。どちらも利用者アプリケーションそのものではないが、ここが不安定になると、ワークロードの展開、ネットワーク変更、証明書、ライフサイクル管理、障害調査に広く影響する。
特にVCF 9.1の移行やアップグレードを考えると、管理VMの割り当てを後回しにしにくい。Broadcom KB 440630は、VCF/VVF 9.1への移行で必須のアップグレード順序があること、VCF Management Services、IPレンジ、既存コンポーネントの扱いなどを公式に整理している。ここで必要になるのは、抽象的な「たぶん足りる」ではなく、現在の構成を説明できる数字だ。
vCenter Server VMとNSX Manager VMを先に見る理由は、単に重要だからではない。VCF Operations上でそれぞれの管理アプリケーション単位にグルーピングしやすく、棚卸し表として切り出しやすいからだ。最初の表が作れれば、次にVCF Operations自身、SDDC Manager、管理サービス、ライセンスサーバー、バックアップ、ログ、監視対象へ広げられる。
VCF Operationsで取得する3つの値：vCPU、メモリ、ディスク
vCPU、メモリ、ディスクだけでなく、所属と取得日を残すと、後続のレビューで使いやすい棚卸し表になる。
公式ブログが示す実務上の軸は明快だ。VCF Operationsに十分な権限のあるアカウントで入り、List viewを作り、対象をvCenter Server VMまたはNSX Manager VMとしてまとめ、構成プロパティからvCPU、メモリ、ディスク容量を表示する。
ここでは、操作手順を細かく再掲するよりも、取得する値の読み方を整理する。
vCenter Server VMのList viewで見る項目
vCenter Server VM向けには、VCF Operations上でvCenterに関連する仮想マシンを対象にし、VMware Infrastructure HealthのvCenter Appでグループ化する。表示する値は、仮想CPU数、メモリ、ディスク容量の3つを基本にする。
公式ブログでは、メモリとディスク容量はKB単位のプロパティをGBへ変換して扱う流れが示されている。ここは現場で意外と大事だ。KBのままCSVへ出すと、レビュー会議で単位換算が必要になり、複数サイトを合計する時にミスが混ざる。最初からGBの列名でそろえ、VM名、vCenter App、サイト、管理ドメイン、取得日を補助列として足す方が扱いやすい。
表にするなら、最小構成は次のようになる。
| 列 | 目的 |
|---|---|
| VM名 | 対象VMを一意に確認する |
| vCenter App | どのvCenter Serverアプリケーションに属するかを見る |
| vCPU | 割り当て済みCPU数を確認する |
| Memory GB | 割り当て済みメモリを確認する |
| Disk Space GB | 割り当て済みディスク容量を確認する |
| Site/Domain | 集計単位をそろえる |
| 取得日 | アップグレード計画との時点差を残す |
リサイズ判断に使わない
この一覧は、リサイズ指示書ではない。あるVMの割り当てが大きい、小さいと見えたとしても、すぐに変更すべきとは限らない。まずは、公式ドキュメント、サイジング、サポート条件、既存の障害履歴、バックアップ方式を確認するための入口にする。
NSX Manager VMのList viewで見る項目
NSX Manager VMも同様に、対象をNSX側の管理アプリケーションとして分けて見る。vCenter Server VMと同じ列構成で取得できれば、管理VM全体の割り当てを横並びで比較しやすい。
ただし、vCenter Server VMとNSX Manager VMを同じ表へ無理に混ぜると、説明しづらくなる。NSX Managerはネットワーク、セキュリティ、クラスタ構成、管理プレーンの可用性に関係する。vCenter Serverは仮想化基盤の管理、インベントリ、ホスト、クラスタ、ライフサイクル連携に関係する。どちらも重要だが、障害時の影響範囲や変更承認の担当者が異なることが多い。
そのため、実務では2枚の表に分けたうえで、最後に合計表を作る方が読みやすい。
| 表 | 主な読者 | 使い道 |
|---|---|---|
| vCenter Server VM一覧 | 仮想化基盤、運用、変更管理 | vCenter単位の割り当て、移行対象、メンテナンス計画 |
| NSX Manager VM一覧 | ネットワーク、セキュリティ、運用 | NSX単位の割り当て、管理プレーン、ネットワーク変更影響 |
| 管理VM合計 | 運用責任者、PM、調達、容量計画 | サイト別/ドメイン別の総量、追加リソース見積もり |
ここでも、取得値は割り当て値であり、利用率ではない。割り当て値が大きいことは、実使用量が常に高いことを意味しない。逆に、割り当て値が小さく見えても、性能上の問題がないとは言い切れない。割り当て表は、性能分析の結論ではなく、次の調査対象をそろえる道具だ。
棚卸し結果を容量計画に変換する
- 11. VM単位
個別VMの割り当てが想定から外れていないかを見る。
- 22. アプリケーション単位
vCenter App、NSX Appごとに合計し、管理プレーンの塊として見る。
- 33. 移行単位
サイト、管理ドメイン、メンテナンス対象、プロジェクト単位で合計する。
- 4補助列を足す
site、management_domain、component、upgrade_wave、owner、review_statusを加える。
- 5合計表にする
管理クラスタ余力、将来増分、一時領域、バックアップ、ログ保持の確認につなげる。
VM単位の違和感を見るだけで止めず、管理ドメインや作業波ごとの合計に変換すると容量計画へ接続しやすい。
List viewでCSVを出せたら、次の課題は「一覧をどう読むか」になる。ここで失敗しやすいのは、VM単位の数字だけを見て、サイト全体、管理ドメイン全体、アップグレード対象全体の合計へ変換しないことだ。
容量計画で使うなら、少なくとも次の3段階で見る。
- VM単位: 個別VMの割り当てが想定から外れていないかを見る。
- アプリケーション単位: vCenter App、NSX Appごとに合計し、管理プレーンの塊として見る。
- 移行単位: サイト、管理ドメイン、メンテナンス対象、プロジェクト単位で合計する。
VM単位の割り当てと合計値を分ける
VM単位の表は、差分を見つけるために向いている。たとえば同じ役割の管理VMなのに割り当てが極端に違う場合、過去のサイジング、障害対応、手動変更、サポート指示、拡張予定があったかを調べるきっかけになる。
一方、アップグレード計画で必要なのは、個別VMの違和感だけではない。メンテナンス対象の合計値、管理クラスタの余力、移行作業中に必要な一時領域、バックアップやスナップショットの保持方針、ログの増加余地も見る必要がある。
そこで、CSVを出した後は、次のような補助列を足すと扱いやすい。
site: 拠点、データセンター、リージョンなど。management_domain: 管理ドメインや作業対象の区切り。component: vCenter Server、NSX Managerなど。upgrade_wave: 第1波、第2波、保留などの作業単位。owner: 仮想化基盤、ネットワーク、セキュリティ、運用など。review_status: 確認済み、要再確認、変更予定、保留。
この列を足すだけで、表は「数字の一覧」から「計画の材料」に変わる。どのチームがどの数字を確認したのか、いつの数字を使って計画したのかが残るからだ。
Cost and Capacity Managementへつなげる
Broadcom TechDocsのVCF 9.1には、Infrastructure OperationsとCost and Capacity Managementの章がある。Infrastructure Operationsでは、VCF Operationsを使ってVCFプラットフォームのcompute、storage、networkを監視・最適化する位置づけが説明されている。Cost and Capacity Managementは、容量予測、最適化、コスト可視化、showback/chargeback、予算管理といった領域につながる。
今回のList viewは、その全機能を置き換えるものではない。むしろ、正式な容量管理へ入る前に、管理VMの割り当てを人間が読める表にそろえる作業だと考えるとよい。
目的別に分ける
たとえば、次のように分ける。
| 目的 | List viewの役割 | 追加で見るもの |
|---|---|---|
| 現状棚卸し | 管理VMのvCPU、メモリ、ディスク割り当てを一覧化 | 取得日、所属、作業対象 |
| 容量見積もり | 管理系リソースの合計を作る | 管理クラスタ余力、将来増分 |
| 性能確認 | 対象VMを絞る入口にする | 使用率、アラート、ワークベンチ、ログ |
| コスト説明 | 管理プレーンの割り当てを説明する | showback/chargeback、予算、調達 |
| 変更承認 | 変更対象と責任者を明確にする | 承認履歴、サポート条件、戻し手順 |
重要なのは、割り当て値を「削れるコスト」と短絡しないことだ。管理VMは、ワークロードVMとは違う責任を持つ。過剰割り当てに見える場合でも、公式サイジング、サポート要件、将来のワークロード、ログ保持、冗長性、障害時の調査負荷を確認してから判断する必要がある。
アップグレード計画とメンテナンス計画に落とす
管理VMの割り当て表は公式ツールの代替ではなく、計画ツールや公式資料を読む前に現場側の入力材料をそろえる表として使う。
VCF 9.1では、既存環境の出発点が一つではない。既存のvSphere環境、VCF環境、vSANやNSXを含む構成、Aria Automationを含む構成など、組み合わせによって確認順序が変わる。2026年5月28日に紹介されたVCF 9.1 Upgrade Planning Toolは、この複雑さを整理する入口として位置づけられている。
管理VMの割り当て表は、このツールの代替ではない。むしろ、ツールやTechDocsを読む前に、現場側が入力できる材料をそろえる作業だ。
VCF 9.1 Upgrade Planning Toolと併用する
VCF 9.1 Upgrade Planning Toolは、現在のデプロイメントとバージョン、目標シナリオを指定し、アップグレードワークフロー、フェーズ、リソース・ネットワーク要件、注意点、関連ドキュメントへの導線を示すものとして紹介されている。
併用時の確認項目
ここで、管理VMの割り当て表は次のように使える。
- 現在のvCenter Server/NSX構成を、ツールで選ぶ現行構成の説明材料にする。
- フェーズごとのメンテナンス対象を、VM一覧と照合する。
- リソース・ネットワーク要件を読む前に、既存割り当ての合計値を手元に置く。
- 作業前後で同じList viewを取り、差分を確認する。
- PDFや計画書へ落とす時に、公式ツールの結果と自社の棚卸し表を並べる。
この流れにすると、会議で「公式ツールではこう出たが、うちの管理VMは今どれだけ割り当てているのか」という確認に答えやすい。逆に、棚卸し表がないと、ツールの結果だけを見て、現場の構成差分を後から探すことになる。
KB 440630で順序と既知論点を確認する
Broadcom KB 440630は、VCF/VVF 9.1へのアップグレード順序と関連論点を整理している。本文で特に見ておきたいのは、VCF Operationsのアップグレード順序、VCF Management Services、IPアドレス、既存構成ごとの移行経路だ。
KBでは、VCF Management ServicesがVCF 9.1のライフサイクルや運用機能に関わる共通ランタイムとして説明され、管理ネットワーク上のIPレンジに関する要件も示されている。最小12 IP、追加18 IP、最大30 IPという数字や、内部IPレンジの衝突確認は、管理VMのCPU/メモリ/ディスクとは別の論点だ。だが、アップグレード計画では同じ時期に確認しなければならない。
ここを混同しないために、計画表では次のように分けるとよい。
| 論点 | 今回のList viewで確認できるか | 見る資料 |
|---|---|---|
| vCenter Server VMのvCPU/メモリ/ディスク割り当て | 確認できる | 2026年6月1日VCFブログ |
| NSX Manager VMのvCPU/メモリ/ディスク割り当て | 確認できる | 2026年6月1日VCFブログ |
| VCF Management ServicesのIP要件 | List viewだけでは確認できない | KB 440630、TechDocs |
| アップグレード順序 | List viewだけでは確認できない | KB 440630、Upgrade Planning Tool |
| 性能ボトルネック | List viewだけでは結論を出せない | VCF Operationsのメトリック、アラート、ログ |
| ライセンス・契約条件 | List viewでは確認できない | Broadcom契約資料、サポート窓口 |
この分離が大切だ。管理VMの割り当てが見えたからといって、アップグレード計画が完成するわけではない。だが、割り当てが見えていない状態でアップグレード計画に入ると、リソース、IP、順序、責任分界の議論が混ざりやすい。
使う前に決めておく運用ルール
- 計画開始時
現状の管理VM割り当てを把握する。
- 変更承認前
見積もりと作業対象を確定する。
- 作業直前
直近の手動変更や差分を確認する。
- 作業後
アップグレード後の割り当てと差分を残す。
比較単位を途中で変えないように、VM名、コンポーネント名、サイト、管理ドメイン、作業波、担当、確認状態をそろえて保存する。
VCF OperationsのList viewは、作るだけなら難しくない。難しいのは、誰がいつ取り、どの粒度で保存し、どの会議で使い、作業後にどう更新するかだ。
棚卸しを取るタイミング
おすすめは、少なくとも4回に分けることだ。
| タイミング | 目的 |
|---|---|
| 計画開始時 | 現状の管理VM割り当てを把握する |
| 変更承認前 | 見積もりと作業対象を確定する |
| 作業直前 | 直近の手動変更や差分を確認する |
| 作業後 | アップグレード後の割り当てと差分を残す |
特に作業直前の再取得は省かない方がよい。アップグレード計画は数週間から数か月かけて進むことがあり、その間に管理VMの割り当てや構成が変わることがある。古いCSVをもとにメンテナンス計画を作ると、作業日の判断がずれる。
比較単位をそろえる
比較単位は最初に決める。vCenter単位で見るのか、NSX環境単位で見るのか、サイト単位で見るのか、管理ドメイン単位で見るのかを途中で変えると、前回との差分が追いにくい。
複数の拠点や管理ドメインがある場合は、次の順でそろえると読みやすい。
- VM名とコンポーネント名をそろえる。
- vCenter Server VM表とNSX Manager VM表を別々に保存する。
- サイト/ドメイン列を足す。
- 作業波、担当、確認状態を足す。
- 最後に合計表を作る。
こうしておくと、ネットワーク担当者はNSX Manager VM表を、仮想化基盤担当者はvCenter Server VM表を、運用責任者は合計表を見ればよい。全員に同じ巨大CSVを読ませるより、判断が速い。
変更判断は「割り当て表」だけで終わらせない
List viewで出した数字は、あくまで割り当て表だ。変更判断に使うなら、次の情報を合わせる。
変更前に合わせて見る情報
- 公式TechDocsのサイジング、設計、アップグレード、Infrastructure Operations。
- Broadcom KBの既知論点、アップグレード順序、IP/FQDN条件。
- VCF Operationsのアラート、メトリック、ワークベンチ、ログ。
- バックアップ、スナップショット、ログ保持、監査要件。
- サポート契約、保守窓口、ベンダーが提示する作業条件。
- 直近の障害履歴、手動変更、未解決チケット。
この確認を入れると、割り当てが大きく見えるVMを安易に縮小したり、割り当てが小さいVMを根拠なく拡張したりするリスクを避けやすい。管理VMは、失敗時に全体へ影響しやすい。表があるからこそ、表だけで判断しない姿勢が必要だ。
まとめ：確認結果から次のアクションを選ぶ
管理VMの割り当て、IPレンジ、FQDN、アップグレード順序、容量計画、運用責任を表に落とすと、作業計画として扱いやすくなる。
今回の公式ブログは、VCF Operationsで管理VMの割り当てを取り出す実用的な入口を示している。読者が得るべき結論は、「この操作を覚えた」ではなく、「アップグレード計画の前に、管理VMの割り当てを説明できる表を持てる」ことだ。
最後は、取得結果を次のアクションに分ける。
| 状態 | 判断 | 次の行動 |
|---|---|---|
| 表が取れ、単位も担当もそろっている | 計画材料として使える | Upgrade Planning Tool、KB 440630、TechDocsと突き合わせる |
| 表は取れたが、所属や担当が不明 | まだ計画材料として弱い | site/domain/owner/review_status列を補う |
| vCenterとNSXの数字が混ざっている | レビューしづらい | 2表に分け、最後に合計表を作る |
| 割り当てが想定と違うVMがある | 変更前に調査が必要 | 公式サイジング、障害履歴、サポート指示を確認する |
| IPや管理サービス要件が未確認 | アップグレード計画を進めにくい | KB 440630、TechDocs、ネットワーク担当で再確認する |
| 性能問題の有無を判断したい | List viewだけでは不足 | メトリック、アラート、ログ、Workbenchを確認する |
VCF 9.1の導入やアップグレードは、公式発表の機能名だけでは進まない。管理VMの割り当て、IPレンジ、FQDN、アップグレード順序、容量計画、運用責任を一つずつ表に落とした時に、ようやく作業計画として扱える。今回のList viewは、その地味だが重要な最初の一枚になる。
次に読むなら
Broadcomの公式発表、VMware Cloud Foundation Blog、TechDocs、KBの更新を継続して追う場合は、月次まとめとニュースレターも補助導線になる。本文の確認を終えた後に使う案内であり、投資判断や契約判断を急がせるものではない。
更新履歴
- 2026年6月2日
2026年6月1日のVMware Cloud Foundation公式ブログ、2026年5月28日のVCF 9.1 Upgrade Planning Tool紹介、2026年5月5日のBroadcom VCF 9.1発表、Broadcom TechDocs、Broadcom KB 440630を確認し、初版を作成した。
確認日と参照資料を残すと、アップグレード計画との時点差を説明しやすい。
- 2026年6月2日: 2026年6月1日のVMware Cloud Foundation公式ブログ、2026年5月28日のVCF 9.1 Upgrade Planning Tool紹介、2026年5月5日のBroadcom VCF 9.1発表、Broadcom TechDocs、Broadcom KB 440630を確認し、初版を作成した。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, "Retrieve vCenter Server VMs and NSX VMs resource allocations in VCF Operations"
https://blogs.vmware.com/cloud-foundation/2026/06/01/retrieve-vcenter-server-vms-and-nsx-vms-resource-allocations-in-vcf-operations/ 確認日: 2026年6月2日
- VMware Cloud Foundation Blog, "Announcing the VMware Cloud Foundation 9.1 Upgrade Planning Tool"
https://blogs.vmware.com/cloud-foundation/2026/05/28/announcing-the-vmware-cloud-foundation-9-1-upgrade-planning-tool/ 確認日: 2026年6月2日
- Broadcom News, "Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI"
https://news.broadcom.com/emea/releases/broadcom-announces-vmware-cloud-foundation-9-1 確認日: 2026年6月2日
- Broadcom TechDocs, "VMware Cloud Foundation 9.1"
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.html 確認日: 2026年6月2日
- Broadcom TechDocs, "Infrastructure Operations"
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/infrastructure-operations.html 確認日: 2026年6月2日
- Broadcom TechDocs, "Cost and Capacity Management"
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/cost-and-capacity-management.html 確認日: 2026年6月2日
- 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 確認日: 2026年6月2日