KVM/Proxmoxのリソース最適化：仮想マシンによるハードウェアの「食いつぶし」を防ぐ – ITFROMZERO

Table of Contents

パフォーマンスと仮想マシンの集約率のバランス：現実的な課題

Proxmoxでラボを構築し始めたばかりの頃は、つい「足りないよりは多いほうがいい」という心理に陥りがちです。仮想マシン（VM）に対して無計画にリソースを割り当ててしまう傾向がありますが、vCPUやRAMを多く割り当てればVMが速くなるわけではありません。むしろ、リソースの競合によってHypervisor全体のパフォーマンスを低下させる原因になります。

私は現在、12台のVMとコンテナが混在するホームラボを運用しています。Disk I/Oのボトルネックでノードがフリーズした経験から学んだのは、適切なリソース割り当ての仕組みを理解することが、システムを24時間365日安定稼働させる鍵であるということです。高価なハードウェアは必要ありません。必要なのはスマートな設定です。

Over-provisioning vs. Fixed Allocation：どちらを選ぶべきか？

仮想化において、区別しておくべき2つのリソース管理手法があります：

1. Over-provisioning（オーバープロビジョニング）

これは、物理マシンの実際のリソースよりも多くのリソースをVMに割り当てる方法です。例えば、32GBのRAMしかないサーバーで、10台のVMにそれぞれ4GB（計40GB）を割り当てるようなケースです。

メリット： ハードウェアを最大限に活用でき、コスト効率が非常に高い。
リスク： すべてのVMが同時にピーク負荷に達すると、HypervisorのRAMが枯渇し、継続的なスワップやシステムクラッシュを引き起こす可能性があります。

2. Fixed Allocation（固定割り当て）

各VMが独立したリソースを占有します。Hypervisorはそのリソースを「ロック」し、他のVMが干渉できないようにします。

メリット： パフォーマンスが極めて安定し、リソースの奪い合いが発生しない。
デメリット： VMがアイドル状態で5〜10%程度の負荷しかかかっていない場合、リソースが無駄になる。

私の経験則： CPUについては、1:3の比率（1つの物理コアを3つのvCPUに割り当てる）程度であれば、比較的自由にオーバープロビジョニング可能です。ただし、RAMに関しては非常に慎重になるべきです。Ballooningはテスト環境のみでの使用をお勧めします。

CPUの最適化：vCPUを重荷にしないために

4つの物理コアしかないホスト上のVMに8つのvCPUを割り当てるのは、典型的な間違いです。この場合、Context Switching（コンテキストスイッチ）が頻繁に発生します。CPUがタスクの切り替えに追われ、レイテンシ（遅延）が急増します。

今すぐCPU Typeを「Host」に変更する

Proxmoxのデフォルト設定では、古いサーバーへのライブマイグレーションを可能にするために kvm64 が使用されます。しかし、kvm64 ではAES-NIやAVXといった重要な命令セットが隠されてしまいます。世代の異なるCPUが混在するクラスターを運用する予定がないのであれば、物理チップの性能を100%引き出すために host に変更しましょう。

# VM ID 100に物理CPUの命令セットを使用させる
qm set 100 --cpu host

NUMAとCPU Pinningの威力

デュアルソケットのサーバーでは、NUMA (Non-Uniform Memory Access) 機能を有効にしてください。これにより、VMはどのRAMがどのCPUに近いかを認識できるようになり、システムバス経由のデータアクセス遅延を最小限に抑えられます。

大規模なデータベースを運用する場合は、CPU Pinningの利用を検討してください。この技術はvCPUを特定の物理コアに固定するもので、データを常にL1/L2キャッシュ内に保持しやすくなり、処理速度が大幅に向上します。

RAM管理：Ballooning活用の技術

Memory Ballooningの仕組みとは？

Ballooningは、VMの内部にある「風船」のようなものだと考えてください。HypervisorのRAMが不足すると、この風船を膨らませて領域を占有し、VMにRAMをホストへ返却させます。この機能を動作させるには、qemu-guest-agent のインストールが必要です。

# Ubuntu/Debianにエージェントをインストールする
sudo apt update && sudo apt install qemu-guest-agent -y
sudo systemctl enable --now qemu-guest-agent

警告： MySQL、PostgreSQL、Redisなどのデータベースには、絶対にBallooningを使用しないでください。データベースは常にすべてのデータをRAMにキャッシュしようとします。突然RAMが回収されると、サービスがフリーズしたり、即座にクラッシュしたりする原因になります。

Disk I/O：最も厄介なボトルネックの解消

仮想化環境において、最初にボトルネックとなるのは多くの場合Disk I/Oです。IO Wait 指標が10%を超えると、CPUが空いていてもVM上のすべての操作が「重く」感じられるようになります。

VirtIO SCSI SingleとIO Threadの有効化

デフォルトのドライバは使用せず、VirtIO SCSI Single を選択して、各仮想ディスクが独自のキュー（queue）を持つようにしましょう。特に IO Thread は必ず有効にしてください。このオプションにより、読み書き操作が専用のCPUスレッドで実行されるようになり、VMのメイン処理スレッドを妨げることがなくなります。

# /etc/pve/qemu-server/100.conf における最適化設定の例
scsihw: virtio-scsi-single
virtio0: local-lvm:vm-100-disk-0,iothread=1,discard=on

「うるさい隣人」を防ぐための帯域制限（Rate Limiting）

バックアップを実行中のVMがディスク帯域を使い果たし、他のVMを停止させてしまうことがあります。公平性を保つため、優先度の低いVMには読み書き速度を50MB/sや100MB/sに制限することをお勧めします。

# VM 100の読み書きを最大50MB/sに制限する
qm set 100 --virtio0 local-lvm:vm-100-disk-0,bwlimits=read=50,write=50

推奨される最適化ワークフロー

Hypervisorをスムーズに動作させるため、私は常に以下の4つのステップに従っています：

モニタリング： htop や iostat -x 1 を使用して、ボトルネックの原因となっているVMを特定する。
CPU： 常に Type: Host を選択する。軽量なワークロードの場合、vCPU:pCPUの比率は4:1を超えないようにする。
RAM： データベースには固定割り当てを行う。BallooningはWebサーバーやプロキシのみに使用する。
Disk： SSD/NVMeを優先し、VirtIO SCSI Single を使用。空き容量を解放するために常に Discard を有効にする。

リソースの最適化は、継続的な微調整のプロセスです。これらの実戦的なテクニックが、皆さんのKVM/Proxmox環境をマスターする助けになれば幸いです。