この投稿は、vExperts Advent Calendar 2025の14日目です。
はじめに
VCF Operations は、VCF 環境全体を横断的に管理・可視化・分析できる運用基盤で、現在の VCF では必須のコンポーネントとなっています。
そのため、これまで vRealize Operations や Aria Operations を積極的に利用してこなかったユーザーであっても、VCF を導入すると自然と触ることになるコンポーネントです。
本記事では、そんなユーザー向けにVCF Operations を「実際のトラブル対応でどう使うのか」 を、運用目線で紹介していきます。
本記事では、Hands-on Labs HOL-2601-04 の内容をもとに、
VCF Operations の トラブルシューティング ワークベンチ を使った実践的なトラブルシューティングの流れを紹介します。
よくある仮想マシンのトラブル対応
従来の仮想基盤運用では、VMのパフォーマンス劣化のトラブルが発生した際に、まずCPU使用率やメモリ使用率を確認し、「高い」「低い」といった状態から原因を推測するケースが多かったと思います。
しかし、この方法では
「CPU 使用率が高い＝CPU リソースが不足している」
「メモリ使用率が高い＝メモリが足りていない」
といった 結果から原因を推測する思考になると思います。
実際には、パフォーマンス劣化の原因がリソース不足ではなく、設定変更や一時的な制限によるものであるケースもあるかと思います。こうした情報はパフォーマンス情報を確認しているだけでは把握できません。
VCF Operations が提供する別の視点
VCF Operations の強みは、CPU やメモリといった数値を収集することではありません。
メトリクス、イベント、設定変更、アラートを同じ時間軸で関連付けて確認できる点 にあります。
特にトラブル対応において重要なのは、「何が起きていたのか」だけでなく、「その直前に何が変わったのか」を把握できることです。
この考え方を実際の運用で体現できるのが、トラブルシューティング ワークベンチ です。
トラブルシューティング ワークベンチは、特定のオブジェクトを起点に、問題の原因となり得る情報を集約して表示するための専用画面です。
トラブルシューティング ワークベンチの画面構成
トラブルシューティング ワークベンチは、VCF Operations管理下で発生した問題を 特定のオブジェクトを起点に分析するための画面です。
画面は大きく分けて、左側のスコープ選択エリアと右側の証拠表示エリアの2つで構成されています。
左側：調査対象（スコープ）の指定
画面左側には、今回のトラブル調査に含める オブジェクトの範囲（スコープ） がツリー形式で表示されています。
この例では、仮想マシン hol-snapshot-001 を起点として、
その上位にあるホスト、クラスタ、データストアなどの関連オブジェクトが並んでいます。
ここで重要なのが スコープレベル です。
スコープレベルは、「どこまでを調査対象に含めるか」を示しており、
レベルを下げるほど対象は狭く、上げるほど広くなります。
たとえば、
• 仮想マシン単体だけを確認したい場合
• まずは影響を受けているオブジェクトに限定して状況を把握したい場合
には、スコープを広げすぎず、対象を最小限に絞ることが有効です。
トラブルシューティングでは、
最初からすべてを含めるのではなく、「必要になったら広げる」という考え方が重要になるかと思います。
右側：潜在的な証拠の一覧
画面右側には、潜在的な証拠 がカード形式で表示されます。
ここには、選択したオブジェクトと時間範囲に基づき、
• 発生していた イベント
• 実施された プロパティの変更（設定変更）
• 異常と判断された メトリクス
が時系列で整理されて表示されます。
この画面のポイントは、「メトリクスを見るための画面」ではなく、
トラブルの原因になり得る情報を一か所に集めて確認できる画面であるという点です。
画面上部では、時間の範囲 を指定できます。
画像の例では「過去 7 日間」が選択されていますが、トラブルが発生したとされる時間帯に合わせて調整することで、関係のない過去の情報を除外できます。
時間範囲を適切に絞ることで、証拠情報が整理され、原因の特定がしやすくなります。
トラブルシューティング ワークベンチの考え方
トラブルシューティング ワークベンチを利用する際に重要なのは、画面操作そのものではなく、調査の進め方です。
まず意識すべき点は、最初からスコープを広げすぎないことです。
クラスタ全体や上位オブジェクトまで含めてしまうと、関係のないイベントや証拠が大量に表示され、かえって原因の特定が難しくなります。
トラブルが報告されている場合は、まず影響を受けている仮想マシンなど、最小限のオブジェクトにスコープを絞って確認すること が有効です。
実践：一時的な VM パフォーマンス劣化
Hands-on Labs では、仮想マシンのパフォーマンスが断続的に低下するというシナリオが用意されています。
アプリケーション担当から「通常利用中に VM の動作が遅くなる」という報告がありましたが、OS やアプリケーション側では問題が確認できませんでした。
トラブルシューティング ワークベンチでスコープを レベル0、時間範囲を過去6時間に設定し、仮想マシンを起点に調査を進めると、潜在的な証拠の中に プロパティ変更 が表示されていることが分かります。
そこには、一時的に
CPU 制限 が 500MHz、
メモリ 制限 が 1GB
に設定されていた履歴が残っていました。
この設定により、
仮想マシンは実際の負荷に関係なく CPU の割り当てが制限され、
メモリについても VMkernel による回収が発生する状態となっていました。
参考：仮想マシンのメモリとCPUリソース制限の影響
https://knowledge.broadcom.com/external/article/326270/impact-of-virtual-machine-memory-and-cpu.html
その結果、短時間ではありますが、
仮想マシンのパフォーマンス低下が発生していました。
メトリクスだけを確認していた場合、
リソース不足と誤認していた可能性がありますが、
実際の原因は 人為的な設定変更 でした。
このケースでは、特別な分析を行ったわけではありません。
スコープを適切に絞り、時間軸を意識し、メトリクスよりも先に設定変更を確認しました。
この流れを意識しただけで、原因は自然と明らかになりました。
VCF Operations は、トラブルの原因を自動的に提示するツールではありません。
しかし、思い込みを排除し、事実ベースで原因に辿り着くための情報を整理して提示してくれるツール だと言えます。
運用目線での所感
VCF Operations を使ったトラブル対応では、「どこから確認するか」が明確になるだけで、
対応スピードが大きく向上します。
障害が発生した際には、まずトラブルシューティング ワークベンチを開き、設定変更の有無や時系列で関連イベントをスコープを活用し確認する。
この流れが習慣化されることで、不要な切り分けや推測は大幅に減らせます。
おわりに
なお、本記事で紹介した内容は、Hands-on Labs のドキュメントに含まれる VCF Operations の機能の一部 に過ぎません。
VCF Operations には、本記事で触れたトラブルシューティング ワークベンチ以外にも、
• アラートによる予兆検知
• 症状や影響範囲を考慮した問題の優先度付け
• ダッシュボードやレポートを用いた継続的な可視化
• ログ連携による詳細な原因分析
といった、日々の運用を支援する多くの機能が用意されています。
今回は「実際のトラブル対応において、どのような考え方で VCF Operations を活用できるのか」に焦点を当てて紹介しましたが、
VCF Operations は 日常運用から障害対応、さらには将来のキャパシティ計画までを支える運用基盤 です。
今後は、アラートやログ連携、ダッシュボードといった他の要素についても、
運用目線で掘り下げていければと思います。