VMware メモリバルーニングとは｜仕組みと esxtop での確認手順

はじめに

「仮想マシンの応答性が低下している」「特定の時間帯にシステムが遅くなる」――こうした事象の背景に、ESXi ホストの物理メモリ逼迫が隠れているケースがあります。

VMware ESXi には、搭載している物理メモリの容量を超えて仮想マシンを稼働させるためのメモリ管理機能（メモリオーバーコミット）が複数用意されています。その中で、物理メモリが不足し始めた段階で最初に発動する回収手段が、本記事で扱う「メモリバルーニング（Memory Ballooning）」です。

バルーニングは、ESXi が備える 4 段階のメモリ回収機構の中で 2 番目に位置する仕組みであり、動作自体は正常です。ただし、バルーニングが継続的に発生している環境は、物理メモリが逼迫しているサインと捉える必要があります。放置するとさらに重い回収手段である「メモリ圧縮」「ホストスワップ」へと進み、パフォーマンス低下を招く可能性があります。

本記事では、VMware ESXi のメモリバルーニングの仕組みを Broadcom 公式ドキュメントに基づいて整理し、vSphere Client と esxtop での確認手順、発生時の対処方法までを解説します。

メモリバルーニングとは

メモリバルーニング（Memory Ballooning）は、ESXi ホストの物理メモリが逼迫した際に、仮想マシンに割り当て済みの未使用メモリを回収して別の仮想マシンへ再配分するメモリ回収技術です。

回収には、VMware Tools（または open-vm-tools）に含まれる「バルーンドライバ（vmmemctl）」が利用されます。

参考: Memory Balloon Driver – Broadcom TechDocs（vSphere 8.0）
“The driver uses a proprietary ballooning technique that provides predictable performance that closely matches the behavior of a native system under similar memory constraints.”
（バルーンドライバは独自のバルーニング技術を用いており、同様のメモリ制約下にある物理マシンの挙動に近い、予測可能なパフォーマンスを実現します）
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/administering-memory-resources/administering-memory-resource-5.html

ゲスト OS からメモリを回収する流れ

通常、仮想マシンは割り当てられたメモリ全体を「自身が所有するメモリ」として認識しています。ESXi は仮想化レイヤを通じてこれを物理メモリへマップしていますが、ホスト全体の物理メモリが逼迫した場合、以下の手順でメモリを回収します。

この仕組みのポイントは、「どのページを解放するかをゲスト OS 自身が判断する」 という点です。ゲスト OS は自分が動かしているプロセスや使用頻度を把握しているため、影響の小さいページから優先的に解放できます。これがホストスワップ（ESXi が機械的に物理メモリを退避する処理）よりもパフォーマンス影響が小さい理由です。

バルーニング発生は物理メモリ逼迫のサイン

バルーニングはメモリオーバーコミットを支える機能ですが、運用管理の観点では注意して扱う必要があります。

• バルーニングが発生している時点で、ホストはすでにメモリ回収が必要な状態（後述の Soft state）に入っています
• バルーニングでも回収しきれない場合、ESXi は「メモリ圧縮」「ホストスワップ」へと進みます
• ホストスワップが発生すると、メモリの内容がディスク（VM スワップファイル）に書き出されるため、I/O 負荷の上昇とアプリケーション応答性の大幅な低下を招きます

つまりバルーニングは、より深刻なメモリ枯渇状態に進む前の早期警告として捉えるのが適切です。

ESXi のメモリ回収 4 段階とバルーニングの位置づけ

ESXi のメモリ回収機構は、バルーニング単独で動作しているわけではありません。物理メモリの逼迫度合いに応じて段階的に発動する 4 つの回収技術 が組み合わされており、バルーニングはその 2 段階目に位置します。

メモリ回収 4 技術の比較

ESXi ホストのメモリ状態（5 段階）

ESXi はホストの空きメモリ量を監視しており、mem.minFree（最小空きメモリ閾値）を基準に 5 段階の状態を遷移します。各状態でどの回収技術が動作するかが定義されています。

mem.minFree の計算式は、最初の 28 GB に対して 899 MB を確保し、28 GB を超える分は 1% を加算します。例えば物理メモリ 64 GB のホストでは以下のように算出されます。

mem.minFree = 899 MB + (64 GB - 28 GB) × 1%
            = 899 MB + 369 MB
            ≈ 1,268 MB

つまり物理メモリ 64 GB のホストでは、空きメモリが約 1.27 GB の 64〜100%（約 813 MB〜1,268 MB）まで減ると Soft state に入り、バルーニングが発動します。

バルーニングがホストスワップより優先される理由

ESXi がメモリ回収時にバルーニングを優先する理由は、「どのメモリページを解放するかをゲスト OS 自身が判断できる」 という点にあります。

バルーニング

ゲスト OS が「解放してもアプリケーション影響の小さいページ」を選んで解放

ホストスワップ

ESXi がゲスト OS の状態を把握できないまま機械的にページを退避（重要なページが選ばれる可能性あり）

そのためバルーニングが正常に機能している環境では、Hard state に進んだとしてもパフォーマンス低下を比較的小さく抑えられます。逆に、バルーニングが機能しない（VMware Tools 未導入の）VM はホストスワップへ直行するため、影響が大きくなる傾向があります。

参考: Memory Reclamation – Broadcom TechDocs（vSphere 8.0）
“Anything beyond the reservation is allocated using the host’s physical resources or, when physical resources are not available, handled using special techniques such as ballooning or swapping.”
（予約された容量を超える領域は物理リソースから割り当てられ、物理リソースが利用できない場合はバルーニングやスワッピングといった特殊な手法で処理されます）
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/administering-memory-resources/memory-reclamation.html

メモリバルーニングの確認方法

バルーニングの発生状況は、用途に応じて 2 つの方法で確認できます。

vSphere Client（GUI）

過去の傾向を時系列で分析する場合に適しています。

esxtop コマンド（CLI）

現時点で発生している事象をリアルタイムに調査する場合に適しています。

【GUI】vSphere Client のパフォーマンスチャートで確認

過去のバルーニング発生履歴を確認したい場合は、vSphere Client のパフォーマンスチャートが便利です。以下の手順は vSphere 8.0 系の HTML5 ベース vSphere Client を前提としています。

1. vSphere Client にログインし、対象の 仮想マシン または ESXi ホスト を選択
2. [監視（Monitor）] タブを開き、左ペインの [パフォーマンス（Performance）] を選択
3. [詳細（Advanced）] を選択
4. グラフ右上の [チャート オプション（Chart Options）] を開く
5. [メモリ（Memory）] のカテゴリで、カウンタ一覧から「バルーン（Balloon / vmmemctl）」にチェック
6. 必要に応じて時間範囲（過去 1 日 / 1 週間 / 1 か月など）を変更

参考: Memory (Balloon) チャート – Broadcom TechDocs（vSphere 8.0）
“The Memory (Balloon) chart displays balloon memory on a host.”
（Memory (Balloon) チャートはホストのバルーンメモリを表示します）
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-monitoring-and-performance/monitoring-inventory-objects/overview-performance-charts/hosts/memory-balloon-host.html

通常時、このグラフは「0」のまま推移します。グラフが上振れしている時間帯があれば、その時点でバルーニングが発生していたと判断できます。あわせて「Swap In Rate / Swap Out Rate」もチャートに追加すると、ホストスワップに進んでいたかどうかも把握できます。

【CLI】esxtop コマンドでリアルタイムに確認

esxtop は ESXi に SSH 接続して使用するリアルタイム監視コマンドで、現在のメモリ状態を秒単位で確認できます。

手順

esxtop
# m を押下 → メモリパネルへ切替
# f を押下 → フィールド選択（J を有効化して MCTL 系列を表示）
# V を押下（大文字）→ VM のみ表示に絞り込み

確認すべき 2 つのレイヤ

esxtop でバルーニングを確認する際は、「ホスト全体」と「VM 個別」の 2 つのレイヤで見る のがポイントです。

MEM overcommit avg: 0.50, 0.50, 0.50
PMEM   /MB:  4095   total: 883 vmk, 1258 other, 1953 free
VMKMEM /MB:  4077 managed: 244 minfree, 3062 rsvd, 1015 ursvd, soft state
PSHARE /MB:  2855 shared,   97 common: 2758 saving
SWAP   /MB:   257 curr,    241 rclmtgt:  0.00 r/s,  0.00 w/s
ZIP    /MB:    26 zipped,   15 saved
MEMCTL /MB:  1330 curr,   1330 target,  3327 max

   GID NAME           MCTL?  MCTLSZ  MCTLTGT  MCTLMAX
  3991 vm-server1       Y      0.00     0.00  1996.46   ← 正常（バルーニング無し）
  3988 vm-server2       Y   1330.86  1330.86  1330.86   ← 上限までバルーニング発生中
  4004 vm-server3       N      0.00     0.00     0.00   ← VMware Tools 未導入

バルーニングの前提条件と落とし穴

バルーニングは強力な仕組みですが、機能するためにはいくつかの前提条件があります。また、運用上の落とし穴もあるため、設計段階で押さえておきたいポイントを整理します。

落とし穴 1: 「予約」の過剰設定による集約率低下

バルーニング対策として「予約（Reservation）」を多用したくなりますが、過剰な予約はホスト全体の集約率を下げる結果につながります。

• 予約された分のメモリは他 VM に割り当てられない（オーバーコミットの効果が打ち消される）
• vSphere HA を有効化している場合、予約値が HA スロットサイズ に反映され、フェイルオーバー可能な VM 数が減少
• 大きな予約を持つ VM は、移行先ホストに同等以上の空きメモリが無いと vMotion に失敗する

予約は「絶対にパフォーマンスを落とせない VM のみ最小限に」という運用が現実的です。

落とし穴 2: 継続的なバルーニングは設計見直しのサイン

短時間のバルーニング発生は ESXi の正常動作ですが、業務時間帯に常態的にバルーニングが発生している場合は、メモリオーバーコミット率が現実のワークロードに対して過剰 と判断できます。以下のいずれかの対応を検討する段階です。

• ホスト追加またはメモリ増設による物理リソースの拡張
• 重要 VM の他クラスタへの分散
• vSphere 9.0 環境であれば Memory Tiering over NVMe の導入検討

バルーニングが発生した時の対策

バルーニングが発生していることが確認できた場合、以下の順序で原因を切り分けて対処します。

STEP

リソース割り当ての設定を確認

物理メモリそのものは十分でも、VM 個別の設定によりバルーニングが誘発されているケースがあります。

「制限（Limit）」が設定されていないか

仮想マシンのメモリ「制限（Limit）」は、その VM が利用できる物理メモリ量に上限を設ける設定です。例えば、メモリ 4 GB を割り当てている VM に対して「制限: 2 GB」が設定されていると、ESXi はホスト全体のメモリ状況にかかわらず、その VM に 2 GB を超える物理メモリを与えません。結果として、ゲスト OS が 2 GB を超える要求を出した時点でバルーニングやホストスワップが発動します。

意図しない制限が設定されている場合は、「無制限（Unlimited）」に戻すことで解消します。

「予約（Reservation）」を活用

データベースサーバなどパフォーマンス維持を優先したい VM に対しては、メモリの「予約（Reservation）」を設定する選択肢があります。予約された容量分の物理メモリは ESXi により常に確保され、その VM に対してバルーニングは発生しません。

ただし、前述の「落とし穴」でも触れたとおり、HA スロットサイズへの影響や vMotion 失敗のリスクがあるため、重要 VM のみ最小限の予約にとどめることをおすすめします。

STEP

他ホストへの分散（vMotion / DRS）

クラスタ内の他ホストにメモリの余裕があるなら、vMotion による負荷分散が有効です。DRS（Distributed Resource Scheduler）が有効化されていれば自動で行われますが、緊急時は手動で対象 VM を退避させることもできます。

仮想マシンを無停止で別ホストへ移行させる「vMotion」の仕組みや実行要件については、関連記事『VMware vMotion の 3 種類と実行要件｜帯域・CPU 互換性のポイント』も参考にしてください。

STEP

物理メモリ増設または Memory Tiering の活用

クラスタ全体でメモリが不足している場合は、根本的なリソース拡張が必要になります。

物理メモリ（DIMM）の増設

最もシンプルで効果が確実な方法です。短期的なコストは発生しますが、運用負荷の継続的な低減を考えれば費用対効果の高い選択肢です。

Memory Tiering over NVMe（vSphere 9.0 で GA）

2025 年 6 月に GA した VMware Cloud Foundation 9.0（vSphere 9.0） から、ローカル NVMe デバイスを 2 次メモリ階層として利用する Memory Tiering over NVMe が正式機能となりました。DRAM と NVMe の 2 階層構成で、頻繁にアクセスされるページは DRAM に、コールドなページは NVMe に配置することで、DIMM 増設に頼らずホストの実効メモリ容量を拡張できます。

参考: What’s New with vSphere in VMware Cloud Foundation 9.0 – VMware Cloud Foundation Blog
“vSphere 8.0 Update 3 launched with a tech preview the Memory Tiering capability and it is now GA with VCF 9.0 which allows you to use NVMe devices that you can add locally to an ESXi host as tiered memory.”
（vSphere 8.0 Update 3 で Tech Preview 提供されていた Memory Tiering 機能は、VCF 9.0 で GA となり、ESXi ホストにローカル接続した NVMe デバイスを階層化メモリとして利用できるようになりました）
https://blogs.vmware.com/cloud-foundation/2025/06/23/vsphere-in-vcf-9-0-whats-new/

DRAM 増設に比べて単位容量あたりのコストを抑えられるため、メモリオーバーコミットが常態化している環境では中長期的な選択肢として検討する価値があります。

まとめ

本記事では、VMware ESXi のメモリバルーニングについて、仕組みから確認方法、対処法までを整理しました。

• バルーニングは VMware Tools 内のバルーンドライバ（vmmemctl）を介してゲスト OS からメモリを回収する仕組み
• 動作自体は正常だが、バルーニング発生はホストの物理メモリが逼迫しているサイン
• ESXi のメモリ回収機構は TPS → Ballooning → Compression → Swap の 4 段階で、バルーニングは 2 段階目に位置する
• 確認は vSphere Client（傾向分析）と esxtop（リアルタイム調査）を使い分けるのが効果的
• esxtop では MCTL? / MCTLSZ / MCTLTGT / MCTLMAX の 4 列とホスト全体の MEMCTL/MB 行をセットで見るのがポイント
• 対策は「VM の制限・予約の見直し → vMotion / DRS による分散 → 物理メモリ増設または Memory Tiering の検討」の順で切り分ける

以上、最後までお読みいただきありがとうございました。