LVM（PV/VG/LV）の概要
LVM（論理ボリュームマネージャ）は、物理ディスクを抽象化して柔軟に容量を扱う仕組みです。物理ディスクやパーティションを「物理ボリューム（PV）」として登録し、複数のPVをまとめて「ボリュームグループ（VG）」という容量プールを作ります。そのプールから必要なサイズを切り出したものが「論理ボリューム（LV）」で、ここにファイルシステムを作って使います。pvcreate→vgcreate→lvcreate の順に構成し、後から容量を拡張できるのが最大の利点です。
ここまで見てきた「ディスクを fdisk でパーティションに区切り、mkfs でファイルシステムを作って使う」という素朴な方法を、しばらく運用していくと、ある不便にぶつかる。
一度決めたパーティションのサイズを、後から変えるのが難しいことだ。たとえば /home の領域がいっぱいになったとき、隣のパーティションを削って広げる、といった操作は、従来のパーティションでは非常にやりにくく、データの退避が必要になることもある。
この「固定的で柔軟性に欠ける」という弱点を、どう乗り越えるのか。その答えが、LVM(Logical Volume Manager、論理ボリュームマネージャ)だ。
🧊 LVM は、何を1枚挟むのか
LVM の本質は、物理ディスクと、実際に使うファイルシステムとの間に「抽象化の層」を1枚挟むことにある。
ディスクを直接区切って使うのではなく、いったん容量を大きなプール(共有の貯水池)にまとめ、そこから必要なぶんだけ自由なサイズで切り出して使う、というイメージだ。
この仕組みは3つの層で構成される。一番下が物理ボリューム(PV：Physical Volume)で、これは物理ディスクやパーティションをLVM用に初期化したものだ。複数の PV を束ねて作る容量プールがボリュームグループ(VG：Volume Group)で、いわば貯水池にあたる。
そして、その VG のプールから必要なサイズを切り出して作る利用単位が論理ボリューム(LV：Logical Volume)で、ここに mkfs でファイルシステムを作って、通常のパーティションと同じようにマウントして使う。
下から PV → VG → LV と積み上がる、と覚えてほしい。では、この3層を実際にどう組み上げるのか。
⛏ 3つのコマンドを、どの順で叩くのか
LVM は、この3層に対応する3つのコマンドを、下の層から順に実行して構築する。
まず、使いたいディスク(ここでは /dev/sdb と /dev/sdc の2台とする)を物理ボリュームとして初期化する。pvcreate /dev/sdb /dev/sdc のように実行すると、これらが LVM の土台である PV になる。ディスク全体ではなく、あらかじめ fdisk で切ったパーティション(/dev/sdb1 など)を対象に pvcreate しても構わない。
作成した PV は pvs(または pvdisplay)で一覧確認でき、各PVの容量とどのVGに属しているかが分かる。
次に、これらの PV を束ねてボリュームグループ(容量プール)を作る。vgcreate datavg /dev/sdb /dev/sdc のように、VG の名前(ここでは datavg)に続けて束ねたい PV を並べる。これで /dev/sdb と /dev/sdc の容量を合算した1つのプール datavg ができあがる。
プールの状態は vgs や vgdisplay で確認でき、合計容量と空き容量が分かる。VG という1つのプールにまとめてしまうので、もとが2台のディスクであることを意識せずに容量を扱えるのがポイントだ。
残るは、このプールから「使う分」を切り出す最後の一手だ。lvcreate -L 10G -n data datavg のように、-L で切り出すサイズ(10ギガ)、-n でボリューム名(data)、最後にどのVGから切り出すか(datavg)を指定する。
作成された LV は /dev/datavg/data という名前(デバイスとしては /dev/mapper/datavg-data)でアクセスでき、ここに mkfs.ext4 /dev/datavg/data としてファイルシステムを作り、mount で任意のマウントポイントに繋げば、ようやく普段どおりファイルを置けるようになる。
lsblk で見ると、ディスクの下に lvm という種別の層が挟まっている様子が確認できる。作った LV は lvs や lvdisplay で一覧できる。手間をかけてこの3層を組んだ見返りは、次に明らかになる。
📈 LVM を組むと、後から何ができるのか
LVM を使う最大の理由が、運用を止めずに容量を後から拡張できることだ。
LV が手狭になってきたら、VG のプールにまだ空きがある限り、lvextend -L +5G /dev/datavg/data のようにサイズを5ギガ増やせる。さらに VG 自体の容量が足りなくなったら、新しいディスクを pvcreate して vgextend datavg /dev/sdd のように VG へ追加するだけで、プール全体を広げられる。
拡張した LV のファイルシステムも、ext4 なら resize2fs、xfs なら xfs_growfs で、多くの場合マウントしたまま(オンラインで)広げられる。
従来の固定パーティションでは退避と作り直しが必要だった容量変更が、コマンド数本で、しかもサービスを止めずに行える――これがLVMが広く使われる理由だ。だが、この柔軟さには代償もある。
⚠ 便利さの裏で、何に気をつけるのか
便利な反面、注意も必要だ。LVM は構成が一段複雑になるぶん、「いまどのディスクがどのVGに属し、どのLVがどこにマウントされているか」を見失いやすくなる。
pvs・vgs・lvs の3点セットで全体像を定期的に確認する習慣をつけよう。
また、pvcreate や vgcreate の対象を間違えれば、既存データを失う点はこれまでのストレージ操作と同じで、実行前の lsblk・blkid による確認は欠かせない。
なお、拡張は容易だが、LVの縮小(lvreduce)はファイルシステムを先に縮める必要があり、手順を誤るとデータ破損につながるため、縮小は拡張よりずっと慎重に行うべき操作だと覚えておいてほしい。
組込みやサーバ用途では、将来の容量増加を見越して最初からLVMで構成しておくと、後の運用が大きく楽になる。