LVMで稼働中のボリュームを無停止拡張する｜PV追加からxfs_growfs完了まで

なぜオンライン拡張が求められるのか

ディスク使用率のアラートが深夜に上がり、翌朝の業務開始前に対処しなければならない——こうした場面は、Linuxサーバーを扱う現場では珍しくありません。従来であればサービスを止めてfsckをかけ、リサイズ後に再マウントするという手順が一般的でした。しかしLVMとjournaling対応ファイルシステム（ext4・XFS）の組み合わせが普及した現在、多くのケースでサービスを止めることなくボリュームを拡張できます。

本記事ではRHEL系・Debian系どちらでも通用する手順を軸に、PV（物理ボリューム）の追加からLV（論理ボリューム）の拡張、XFSファイルシステムへの反映（xfs_growfs）、そして拡張後の検証と切り戻し指針までを一連の運用シナリオとしてまとめます。なお2026年時点でのディストリビューション差分にも触れています。

拡張前に確認すべきこと

作業前の確認を怠ると、拡張中に予期しないエラーが出て手順が止まるケースがあります。以下の点を事前に押さえておきましょう。

• VGに空きPEが残っているか：vgdisplay で「Free PE / Size」を確認します。既存ディスクに未割り当て領域がある場合は、新ディスクを追加せずにそのまま拡張できます。
• ファイルシステムの種別：df -Th または lsblk -f でXFSかext4かを確認します。拡張コマンドが異なるため、混同すると失敗します。
• スナップショットやRAIDの有無：LVMスナップショットが存在する状態でのLV拡張は、スナップショット領域の枯渇リスクを高めます。MD RAIDの上にPVを作っている場合は、RAIDの状態（cat /proc/mdstat）も確認してください。
• カーネルとlvm2のバージョン：RHEL 9系ではlvm2の設定ファイルが /etc/lvm/lvm.conf から /etc/lvm/lvmlocal.conf への分離が進んでいます。また、Ubuntu 24.04 LTSではlvmetad が完全に廃止されており、旧来の手順書にある lvmetad 関連の記述は無視してかまいません。

PV追加とVG拡張の手順

新しいディスク（例：/dev/sdb）をサーバーに接続した状態を前提とします。クラウド環境であれば、追加ストレージをアタッチした後にカーネルへの認識を促す必要があります。

# ディスク認識を促す（物理サーバーの場合）
echo "- - -" > /sys/class/scsi_host/host0/scan

# 認識確認
lsblk

# パーティションを切らずにディスク全体をPVにする場合
pvcreate /dev/sdb

# PV作成の確認
pvdisplay /dev/sdb

# 既存のVGに追加
vgextend vg_data /dev/sdb

# VGの空き容量を確認
vgdisplay vg_data | grep -E "Free|VG Size"

クラウド環境（AWS EC2・GCPのCompute Engine・Azure VM）では、ストレージをアタッチするとほぼ自動でブロックデバイスが出現します。ただしデバイス名は環境によって /dev/xvdf や /dev/nvme1n1 など異なるため、lsblk で確認してから作業します。

パーティションを切るかどうかは運用ポリシー次第ですが、現場では「ディスク全体をPVにする」シンプルな構成が増えています。GPTパーティションを使いたい場合は gdisk または parted で 8e00（Linux LVM）タイプのパーティションを作成してから pvcreate を実行してください。

LV拡張とxfs_growfsによるファイルシステム反映

VGに空きができたら、対象のLVを拡張します。ここでのポイントは「LV拡張」と「ファイルシステム拡張」を混同しないことです。LVを拡張しただけでは、ファイルシステムはまだ旧サイズのままです。

# LVを100GB拡張する例（相対指定）
lvextend -L +100G /dev/vg_data/lv_app

# VGの空き全量を使い切る場合
lvextend -l +100%FREE /dev/vg_data/lv_app

# LV拡張の確認
lvdisplay /dev/vg_data/lv_app | grep "LV Size"

# XFSのオンラインリサイズ（マウントしたまま実行可能）
xfs_growfs /mnt/app

# ext4の場合はresize2fs（こちらもマウント中に実行可能）
# resize2fs /dev/vg_data/lv_app

xfs_growfs の引数はデバイスパスではなくマウントポイントである点に注意してください。デバイスパスを渡すとエラーになります（xfs_growfs: /dev/vg_data/lv_app is not a mounted XFS filesystem）。ext4の resize2fs はデバイスパスを引数に取るため、XFSとは逆になります。この違いを誤ると作業が止まるため、ファイルシステム種別の事前確認が重要です。

なお、RHEL 8以降では lvextend -r オプションを使うと、LV拡張とファイルシステムリサイズを1コマンドにまとめられます。内部的にXFSなら xfs_growfs、ext4なら resize2fs を自動判別して実行します。ただし本番環境では1ステップずつ確認しながら進める運用者も多く、自動化ツールに組み込む場合と手動運用の場合で使い分けるのが現実的です。

拡張後の検証と切り戻しの考え方

拡張が完了したら、必ず以下の手順で結果を確認します。

# ファイルシステムのサイズ反映を確認
df -h /mnt/app

# LVのサイズ確認
lvs /dev/vg_data/lv_app

# VGの残り容量確認
vgs vg_data

# XFSの詳細情報（ブロック数・アグリゲーション数）
xfs_info /mnt/app

df -h の出力でサイズが想定通りに増えていれば、ファイルシステムへの反映は完了しています。アプリケーションログにI/Oエラーが出ていないかも合わせて確認してください。

切り戻しについては、LVMの拡張操作は原則として縮小方向には戻せません。XFSはオンライン縮小に対応しておらず、ext4も縮小にはアンマウントが必要です。このため「間違えて大きくしすぎた」場合の即時切り戻しは困難です。現場での対策は以下の2点に集約されます。

• 拡張前にLVMスナップショットを取る：データボリュームが大きい場合は現実的でないこともありますが、設定ファイル主体のボリュームであれば有効です。
• クラウド環境ではスナップショットを活用する：AWS EBSやGCP Persistent DiskはOSレベルの操作前にスナップショットを取得できます。万一ファイルシステムが壊れた場合でも、スナップショットから新しいボリュームを復元できます。

ディスクが物理的に増えた（=PVが増えた）こと自体は問題なく、VGの空き容量が増えるだけなので、「PVを追加してVGを拡張したが、LV拡張はまだしていない」という状態に戻すことは実質的に可能です。LV拡張後のロールバックが難しい点を意識して、スナップショットのタイミングを計ることが重要です。

2026年の現行環境で押さえておきたい差分

2026年時点で主流となっているディストリビューションを使う場合、旧来の手順書と異なる点がいくつかあります。

RHEL 9 / AlmaLinux 9 / Rocky Linux 9：デフォルトファイルシステムがXFSのままですが、lvm2のバージョンが上がり、lvmdevices という新しいデバイス管理機構が導入されています。複数のシステムディスクが混在する環境では、/etc/lvm/devices/system.devices にPVが登録されていないと vgscan がディスクを見つけられないケースがあります。新しいPVを追加した後に認識されない場合は vgimportdevices -a を試してください。

Ubuntu 24.04 LTS：インストール時にLVMを選択するとデフォルトでext4が使われますが、手動構成でXFSにする運用も増えています。lvmetad が廃止されているため、PV追加後は pvscan --cache でキャッシュを更新する必要があります（サービスデーモン不要でコマンド単体で動作します）。

Btrfsを使う場合の注意：一部のディストリビューション（openSUSE Leap 15.6・Tumbleweed）ではBtrfsがデフォルトになっています。Btrfsはボリューム管理機能をOS側に内包しているため、LVMと組み合わせるメリットが薄く、むしろ二重管理になるリスクがあります。現場でBtrfsを使う場合は、LVMを介さずBtrfsのデバイス追加（btrfs device add）とリバランス（btrfs balance）で拡張するほうが整合性を保ちやすいです。本記事の手順はLVM前提のため、Btrfs環境には適用しないでください。

LVMによるオンライン拡張は枯れた技術ですが、ディストリビューションごとの細かい差分や、クラウド環境のデバイス命名規則など、現場で躓きやすいポイントは今も変化し続けています。手順を実行する前に必ず対象環境のOS・カーネル・lvm2バージョンを確認し、作業ログを残す習慣をつけることが安定運用の基本です。