なぜKVMを手動管理する代わりにProxmoxを選ぶのか?
virshやlibvirtでKVMをセットアップしたことがあるなら、VMの作成、ネットワーク設定、ディスクのアタッチ——すべてコマンドを打ちながら構文を覚えておかなければならないあの感覚をご存知だろう。Proxmox VEはKVM(とLXCコンテナ)をフル機能のWebインターフェースでラップし、クラスター管理、スナップショット、バックアップをまとめて提供することで、その問題を解決する。
私のホームラボではProxmox VEで12台のVMとコンテナを管理している——本番環境に持ち込む前にあらゆるものをテストするプレイグラウンドだ。素のKVMをやめた理由はシンプルで、VMが5〜6台を超えるとコマンドラインでの管理が本当に時間を食い始めるからだ。Proxmoxなら新しいVMの作成はweb UIで約2分、それでもSSHでノードに入ってコマンドを打つことはいつでもできる。
手動KVMと比べて最も便利だと感じるのは、すべてのVM設定が/etc/pve/qemu-server/<vmid>.confにテキストファイルとして保存され、バックアップやバージョン管理が簡単なことだ。web UIを通じた変更はすべてログに記録される——後でデバッグするとき、ログをフィルタリングするだけで誰が何時に何を変更したかわかる。
Proxmox VEのインストール
実際のハードウェア要件
Proxmox VEは仮想化対応CPU(Intel VT-xまたはAMD-V)が必要だ。インストール前に確認しておこう:
egrep -c '(vmx|svm)' /proc/cpuinfo
# 結果が0より大きければCPUは対応済み — 0が出たらBIOSでIntel Virtualization Technologyを有効にする
動作に必要な最小構成:
- CPU:4コア(複数VMを並列実行するなら8コア)
- RAM:8GB(本格的なホームラボには32GB以上を推奨)
- ストレージ:SSD 128GB以上——HDDは複数VMが同時にディスク書き込みを行うと深刻なボトルネックになる
- NIC:ギガビット1ポート(管理ネットワークとVMトラフィックを分けたいなら2ポート)
インストール手順
ProxmoxのサイトからISOをダウンロードし、起動用USBを作成する:
dd if=proxmox-ve_8.x.iso of=/dev/sdX bs=1M status=progress
# /dev/sdXを自分のUSBデバイスに置き換える(lsblkで確認)
インストーラーはシンプルなウィザード形式で、ディスク選択、タイムゾーン、rootパスワードを順番に設定していく。ネットワーク部分は少し注意して入力しよう:
- Management IP:Proxmox web UI用の静的IP(例:
192.168.1.10/24) - Gateway:ルーターのIP(
192.168.1.1) - Hostname:FQDN、例:
pve.homelab.local
インストール後、https://192.168.1.10:8006(HTTPS、ポート8006)でweb UIにアクセスする。rootと設定したパスワードでログインする。ブラウザがSSL証明書の警告を表示するが、これはProxmoxの自己署名証明書なので「詳細設定 → 続行」をクリックすれば問題ない。
詳細設定——VMの作成と管理
ProxmoxへのISOアップロード
VMを作成する前に、OSのISOが必要だ。最速の方法はSSH経由でノードに直接ダウンロードすること:
wget -P /var/lib/vz/template/iso/ \
https://releases.ubuntu.com/22.04/ubuntu-22.04.3-live-server-amd64.iso
# チェックサムを確認
sha256sum /var/lib/vz/template/iso/ubuntu-22.04.3-live-server-amd64.iso
またはweb UIからローカルマシン経由でアップロードできる:Datacenter → pve → local (pve) → ISO Images → Upload。
Web UIでのVM作成
右上のCreate VMをクリックする。ウィザードは7つのタブで構成されている——よく見落とされるポイントを整理しておこう:
- General:VM IDは自動採番される。
ubuntu-prod-01、debian-test-02のように分かりやすいパターンで名前を付けよう。 - OS:アップロードしたISO、OSタイプとバージョンを選択する(デフォルトで読み込まれるドライバーに影響する)。
- System:Linuxはデフォルトのまま。Windowsをインストールする場合はOVMF(UEFI)を有効にし、Windows 11にはTPM 2.0を追加する。
- Disks:I/Oパフォーマンスを最大化するためバスタイプにVirtIO Blockを選択する。ストレージがSSDならDiscardを有効にする(TRIMサポート)。
- CPU:コア数を設定する。割り当てすぎに注意——オーバーコミットは可能だが、すべてのVMが同時に高負荷になるとCPUの競合がすぐに起きる。
- Memory:Ballooning Deviceを有効にすると、アイドル時にVMがホストにRAMを返却できる——複数VM実行時にかなりのメモリ節約になる。
- Network:ブリッジは
vmbr0がデフォルト。スループット最大化にはVirtIOモデルを選択し、古いOSでVirtIOドライバーがない場合はE1000を使う。
CLIでのVM作成(qmコマンド)
複数のVMをまとめて作成したり、自動化スクリプトを書く場合はqmを使う:
# ID 200のVMを作成
qm create 200 --name ubuntu-test \
--memory 2048 \
--cores 2 \
--net0 virtio,bridge=vmbr0 \
--scsihw virtio-scsi-pci \
--scsi0 local-lvm:32 \
--ide2 local:iso/ubuntu-22.04.3-live-server-amd64.iso,media=cdrom \
--boot c --bootdisk scsi0 \
--ostype l26
# VMを起動
qm start 200
# 状態を確認
qm status 200
# グレースフルシャットダウン(ACPIシグナルを送信)
qm shutdown 200
# 即時停止(電源を抜くのと同等)
qm stop 200
スナップショットとVMのクローン
最もよく使う機能だ——リスクのある操作をテストする前にスナップショットを取り、テンプレートから新しいVMを作るためにクローンする:
# スナップショットを作成
qm snapshot 200 snap-before-upgrade --description "Before Ubuntu dist-upgrade"
# VMのスナップショット一覧を表示
qm listsnapshot 200
# スナップショットにロールバック(VMを停止するかライブスナップショットを使用)
qm rollback 200 snap-before-upgrade
# 不要なスナップショットを削除
qm delsnapshot 200 snap-before-upgrade
ホームラボでよく使うゴールデンイメージのワークフロー:OSをインストールし、SSHキーと必要なパッケージを揃えた1台のVMを用意してテンプレートに変換する。新しいVMが必要になったらそこからクローンするだけ——ゼロからインストールするより圧倒的に速い:
# VMをテンプレートに変換(変換後は起動不可)
qm template 200
# テンプレートからフルクローン(独立したVM、独自のディスクを使用)
qm clone 200 301 --name web-server-01 --full
# リンククローン(ディスク節約だが、テンプレートへの依存あり)
qm clone 200 302 --name web-server-02
# クローンしたVMを起動
qm start 301
チェックと監視
Web UIでのリソース監視
最初からGrafanaをセットアップする必要はない——Proxmoxのビルトイン監視機能でホームラボには十分だ。任意のノードやVMのサマリーを開けば、CPU、メモリ、ディスクI/O、ネットワークトラフィックのリアルタイムグラフがすぐに確認できる。
メトリクスの履歴は時間、日、週、月、年単位で保持される。VMが突然遅くなったとき、過去24時間のCPU/ディスクI/Oグラフを確認するだけで数分以内に原因を特定できる——手動でログを掘り返す必要はない。
CLIでの監視
# すべてのVMと状態を一覧表示
qm list
# VMの詳細設定を確認
qm config 200
# VMのリアルタイムステータス(CPU、メモリ、稼働時間)
pvesh get /nodes/pve/qemu/200/status/current
# すべてのVMをJSON形式で一覧表示し、名前でフィルタリング
pvesh get /nodes/pve/qemu --output-format json | jq '.[].name'
# ストレージのディスク使用量を確認
pvesh get /nodes/pve/storage --output-format table
# すべてのタスクを表示(失敗したものも含む)
pvesh get /nodes/pve/tasks --output-format table | head -20
VMダウン時のアラートスクリプト
Proxmox 8.xにはNotifications機能が組み込まれている(Datacenter → Notificationsから設定)。Telegram経由のシンプルなアラートが欲しい場合は、このスクリプトで十分だ:
#!/bin/bash
# /root/check-vms.sh — cronで5分ごとに実行
TELEGRAM_BOT_TOKEN="your_bot_token"
CHAT_ID="your_chat_id"
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
status=$(qm status $vmid | awk '{print $2}')
name=$(qm config $vmid | grep '^name:' | awk '{print $2}')
if [ "$status" != "running" ]; then
curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
-d "chat_id=${CHAT_ID}&text=⚠️ VM ${name} (ID: ${vmid}) status: ${status}"
fi
done
# crontabに追加
*/5 * * * * /root/check-vms.sh
vzdumpでのVMバックアップ
Datacenter → Backupのweb UIからスケジュールバックアップを設定するのが最も簡単だ。スケジュール外でバックアップが必要な場合はCLIを使う:
# zstd圧縮でVM 200をバックアップ(高速かつ良好な圧縮率)
vzdump 200 --storage local --compress zstd --mode snapshot
# すべてのVMをバックアップ
vzdump --all --storage local --compress zstd --mode snapshot
# バックアップファイルからリストア
qmrestore /var/lib/vz/dump/vzdump-qemu-200-2024_01_15-10_30_00.vma.zst 300
# 300はリストア後の新しいVM ID
便利なコツ:snapshotモードを使えばバックアップ中にVMを停止する必要がない。ProxmoxはKVMスナップショットを作成し、そこからバックアップして自動的に後片付けしてくれる——VMは中断なく稼働し続ける。
