2.3LVM の設定と管理

パーティションを直接ファイルシステムにすると、後から容量を柔軟に増減させるのが困難です。LVMは物理ディスクの制約を1段抽象化し、稼働中のシステムでもボリュームの拡張・縮小・複数ディスクにまたがる統合を可能にする、実運用で欠かせない仕組みです。

2.3.1LVMの3階層構造

• 物理ボリューム（PV）＝LVMが使う最下層の実体（パーティションやディスク丸ごと）。pv系コマンドで扱う：pvcreate（PVとして初期化）・pvdisplay（詳細表示）・pvs（一覧を簡潔表示）・pvremove（PV解除）。
• ボリュームグループ（VG）＝複数のPVをまとめてプールした中間層。vg系コマンドで扱う：vgcreate（PVからVG作成）・vgextend（PV追加でVG拡大）・vgreduce（PV除去）・vgdisplay／vgs（表示）。
• 論理ボリューム（LV）＝VGというプールから必要な分だけ切り出す、実際にファイルシステムを作る対象。lv系コマンドで扱う：lvcreate（VGから作成）・lvextend（拡大）・lvreduce（縮小）・lvremove（削除）・lvdisplay／lvs（表示）。

2.3.2lvm コマンドと lvm.conf

• lvm＝PV/VG/LVすべてのサブコマンド（pvcreate等）を単一の対話的シェル/統合フロントエンドとしても呼び出せるコマンド（lvm pvcreate ...のように使う、あるいはlvm単体で対話モードに入る）。
• lvm.conf＝LVM全体の動作を制御する設定ファイル（デバイスのスキャン対象・フィルタ、ロギング、バックアップ先等）。通常は既定値のままで運用でき、特殊な絞り込み（特定デバイスのみLVM対象にする等）で編集する。

LVMの真価は「容量が足りなくなったら止めずに増やせる」運用性にあります。典型的な拡張シナリオを追いましょう。まずディスクを1台追加し、パーティションを切ったらpvcreate /dev/sdc1でPV化します。次に既存のVG（例vg_data）へこのPVを組み込むのがvgextend vg_data /dev/sdc1＝VGの拡大です。この時点でプール（VG）の空き容量は増えましたが、実際に使っているLV（例/dev/vg_data/lv_home）はまだ元のサイズのままなので、lvextend -L +20G /dev/vg_data/lv_homeのようにLV自体を拡張します。ここで見落としがちな最後の一手が、ファイルシステム側の拡張です。LVMがブロックデバイスの容量を増やしても、その上のext4やXFSは「自分のサイズはまだ元のまま」と認識しているため、resize2fs（ext系）やxfs_growfs（XFS。マウントしたまま実行できる点がXFSの特徴）といったファイルシステム側のコマンドを別途実行しないと、増えた領域は使える状態になりません。逆に縮小は、LVの縮小（lvreduce）の前にファイルシステム側を縮小しておく必要があり、順序を誤るとデータ損失につながるため、拡張よりも慎重な手順が要求されます（ext4は拡張はマウントしたまま行える一方、縮小はアンマウント（オフライン）が必須で、XFSはそもそも縮小に対応していないという非対称性も実務上の重要な違いです）。

2.3.3この節のまとめ

• PV(pv*)→VG(vg*)→LV(lv*)の3階層。作成はpvcreate→vgcreate→lvcreateの順、拡張はvgextendでPV追加→lvextendでLV拡張
• LV拡張後は必ずファイルシステム側resize（resize2fs／xfs_growfs）も実行。縮小はファイルシステム側が先。全体設定はlvm.conf