実機で試してから書く、自宅サーバーの部活動 2026-09-22 TUE / 記事 14 本

ホーム記事一覧 › Proxmoxのlocal-lvmが満杯でVMが起動しない:原因の見方とディスクの空け方

Proxmox

Proxmoxのlocal-lvmが満杯でVMが起動しない:原因の見方とディスクの空け方

公開 2026-09-14読了 7 分

Photo: panumas nikhomkhai / Pexels

この記事でわかること
Proxmox VEのlocal-lvmが満杯でVMが起動しないときの原因の切り分けと、スナップショット・未使用ディスク・discard未設定という3つの容量の食われ方への対処を順番に整理します。

自宅の Proxmox で VM を起動しようとしたら、起動せずにこんなエラーが出る——というのは、ホームラボでかなり頻度の高いトラブルです。

TASK ERROR: activating LV 'pve/data' failed: Check of pool pve/data failed (status:1). Manual repair required!

先に結論です。このエラーのほとんどは local-lvm(LVM-thin プール)の使用率が 100% に達したことが原因で、容量を食っているのは「スナップショット」「消し忘れた未使用ディスク」「discard 未設定」の3つのどれかです。 そして重要な前提がひとつあります。プールが満杯のまま VM を起動しないでください。 書き込みが失敗してゲスト側のファイルシステムが壊れる可能性があるので、まず空けてから起動します。

なぜ「割り当てた覚えがない容量」が消えるのか

Proxmox VE を標準インストールすると、ストレージが2つできます。

  • local:ISO イメージ・バックアップ・コンテナテンプレートを置くディレクトリ。実体は root LV 上の /var/lib/vz
  • local-lvm:VM の仮想ディスクを置く LVM-thin プール(LV 名は pve/data

ここで最初のつまずきが起きます。local の ISO をいくら消しても local-lvm の空きは1バイトも増えません。 別の LV だからです。「バックアップを消したのに VM が起動しない」の原因はたいていこれです。

そしてもう一段ややこしいのが thin プロビジョニングです。LVM-thin は「32GB のディスクを割り当てても、実際に書き込まれた分しか消費しない」仕組みなので、プールの実容量を超えて割り当てる(オーバープロビジョニング)ことができます。便利な反面、割り当て合計が実容量を超えている状態は Proxmox 側では警告されず、ゲストが書き込みを進めた結果として、ある日いきなり 100% に到達します。

ステップ1:どこが満杯なのかを確認する

SSH かシェルで、次の3つを順に見ます。

pvesm status          # ストレージごとの使用率
lvs -o +metadata_percent
df -h /               # root(local) 側の空き

lvs の出力で見るのは Data%(データ使用率)Meta%(メタデータ使用率) の2つです。

  • Data% が 100 に近い → 通常の容量不足。ステップ2へ
  • Meta% が 100 に近い → メタデータ領域の枯渇。データに空きがあってもプールが止まります。対処が違います(後述)
  • どちらも余裕がある → local-lvm の問題ではありません。df -h で root が満杯(ログやバックアップの溜まりすぎ)の可能性を見てください

Data% が 95% を超えていたら、すでに危険域とされています。LVM-thin は空きがなくなると書き込みエラーを返すので、余裕を持って対処する前提で進めます。

ステップ2:容量を食っている3つの犯人を探す

犯人1:スナップショット

ホームラボで一番多いのがこれだと思います。「アップデート前に念のため」と取ったスナップショットが、そのまま何か月も残っているパターンです。

スナップショットは差分を保持し続けるので、元の VM を使い込むほど太ります。 GUI の VM → Snapshots か、CLI で確認します。

qm listsnapshot 100
qm delsnapshot 100 before-update

削除はプールに空きがないと失敗することがあります。その場合は先に犯人2・3で空きを作ってから戻ってください。

犯人2:消し忘れた未使用ディスク(unused disk)

GUI で VM のディスクを「Detach(切り離し)」しただけだと、unused0 として 容量を占有したまま残ります。 「Remove」まで実行しないと消えません。削除した VM のディスクが孤児として残っていることもあります。

pvesm list local-lvm        # プール上の全ディスクを一覧
qm config 100 | grep unused # VM ごとの未使用ディスク

pvesm list に出てくる vm-XXX-disk-N のうち、qm config XXX にも pct config XXX にも出てこないものが孤児です。VMID が実在しないことを必ず確認してから、GUI の Remove か次のコマンドで消します。

pvesm free local-lvm:vm-100-disk-1

この操作は取り消せません。心配なら、消す前にそのディスクだけバックアップを取っておくと安全です。

犯人3:discard(TRIM)が無効で、消したはずの容量が返っていない

これが「原因が分からないまま増える」タイプの犯人です。ゲスト OS 内でファイルを削除しても、ホスト側の thin プールは「解放された」と知る手段がありません。 結果、ゲストでは 40% しか使っていないのに、ホスト側では 100% 近い、という乖離が起きます。

解放を伝えるには、ホストとゲストの両方の設定が必要とされています。

  1. ホスト側:VM → Hardware → ディスクを選び、SCSI Controller を VirtIO SCSI、ディスクの Discard にチェック(SSD emulation も入れておくと扱いやすいです)
  2. ゲスト側(Linux)sudo fstrim -av で即時解放。継続運用は sudo systemctl enable --now fstrim.timer(週次で実行されます)
  3. ゲスト側(Windows):「ドライブのデフラグと最適化」で対象ドライブを最適化(TRIM が発行されます)

Discard の設定変更は VM の停止・起動(リブートではなく一度シャットダウンしてから起動)で反映されます。手順としては後回しに見えますが、これを設定しないと同じ問題が数か月後にまた起きます。 空けた後に必ず入れておくことをお勧めします。

メタデータが枯渇していた場合

Meta% が 100% に近いときは、データ領域を空けても解決しません。メタデータ領域を拡張します。VG に空き(vgsVFree)があることが前提です。

vgs
lvextend --poolmetadatasize +1G pve/data

冒頭の Manual repair required! が出て、プールが有効化すらできない状態なら、修復が必要です。

lvconvert --repair pve/data

--repair作業用に VG の空き領域を必要とします。空きがないときは、後述の swap 削除などで先に VG を確保してください。この状態まで来ていたら、手を入れる前に重要な VM のバックアップを取れるか確認することを強くお勧めします。

それでも足りないとき:プール自体を広げる

vgsVFree に空きが残っていれば、プールを伸ばせます。

lvextend -l +100%FREE /dev/pve/data

VG に空きがない場合の選択肢は、現実的には次の2つだと思います。

1つめは swap LV の削除です。 メモリに十分な余裕があるホームラボなら、pve/swap(デフォルト 8GB 程度)を削除してその分をプールに回す方法が知られています。/etc/fstab の swap 行を無効化してから swapoff -alvremove /dev/pve/swaplvextend という流れです。メモリが逼迫しているホストでやると OOM のリスクが上がるので、空きメモリを確認してから判断してください。

2つめは物理的に SSD を足すことです。 ミニPCでも M.2 スロットが2つある機種や、2.5インチベイを持つ機種なら増設できます。増設したディスクを新しいストレージとして追加し、大きい VM のディスクだけそちらへ移動(GUI の Disk Action → Move Storage)すれば、local-lvm の逼迫は根本的に解消します。自宅サーバー用なら、容量単価と耐久性(TBW)のバランスで 1TB クラスが扱いやすいところです。

  • WD Blue SN5000 1TB:M.2 増設の定番クラス。ミニPCの空きスロット用に
  • Crucial P3 Plus 1TB:価格重視。VM 置き場を分離する目的なら十分とされています

なお、24時間稼働のサーバー用途では書き込み耐久(TBW)の値も確認してください。VM を常時動かすホストは、デスクトップ用途よりも書き込みが多くなります。

同じことを繰り返さないための3つの運用

  1. スナップショットを常設にしない:取ったら「いつ消すか」を決める。恒久的な保護はバックアップの仕事です
  2. バックアップの保存先を local にしないlocal(root LV)に貯めると今度は root が満杯になります。NAS か Proxmox Backup Server を保存先にして、保持世代数(Retention)を必ず設定します
  3. discard を全 VM のデフォルトにする:新規 VM を作るときの手順に組み込んでしまうのが確実です

まとめ

  • エラーの実体は LVM-thin プール pve/data の枯渇満杯のまま VM を起動しない(ゲストのファイルシステムが壊れる可能性があります)
  • local の ISO やバックアップを消しても local-lvm の空きは増えません。別の LV です
  • まず lvs -o +metadata_percentData%Meta% のどちらが詰まっているかを判別する
  • 容量の犯人は スナップショット / Detach しただけの未使用ディスク / discard 未設定の3つ
  • 孤児ディスクを消すときは、その VMID が実在しないことを確認してから。取り消せません
  • Meta% 枯渇は lvextend --poolmetadatasize、有効化できない状態は lvconvert --repair。どちらも VG に空きが必要
  • 再発防止は discard 有効化が本命。これを入れないと数か月後に同じ場所で止まります

一度この状態になると、原因を探している間に「とりあえず VM を起動して確かめたい」と思うはずです。そこを我慢して、空けてから起動する。この順番だけ守れば、Proxmox の local-lvm 満杯は復旧できるトラブルだと思います。


運営者が作った Excel テンプレートを BOOTH で配布しています。IT 資産管理台帳(無料 Lite 版あり) / IT 資格の学習管理シート

部長(本業: IT インフラ) 家でも同じことをして遊んでいます。記事は実機で試してから書き、失敗もそのまま載せます。