EBSボリュームを拡張しようとしたら、LVMという仕組みでディスクが管理されてて、「なにこれ？」となったことありませんか？

正直、AWS環境だとあまり見かけない構成ですが、オンプレからリフトアンドシフトの移行案件などで、たまに出くわすことがあるようです。

今回は、LVMで管理されたEBSボリュームの拡張手順と、実際にやってみた検証ログをまとめてみました。

LVMってそもそも何？

一言でいうと、複数のディスクを合体させて、一つのデカい仮想ディスクみたいに見せかける技術です。これを使うと、後からディスクを追加して容量を増やしたり、柔軟なディスク管理ができるようになります。

LVMにはいくつか専門用語が出てきます。

  • 物理ボリューム (PV): ディスクそのものやパーティションのこと。LVMで使うための初期化をした状態。
  • ボリュームグループ (VG): 物理ボリューム(PV)をいくつか束ねた、大きなディスクのプールみたいなもの。
  • 論理ボリューム (LV): ボリュームグループ(VG)というプールから、実際にOSが使う分だけ切り出した領域。

LVMなEBSの拡張フロー

流れはとしてこんな感じです。物理的なディスクからファイルシステムまで、下から上へ順番にサイズを伝達していくイメージです。

  1. EBSボリューム拡張: まずはAWSコンソールで物理的な容量を増やす。
  2. 物理ボリューム(PV)拡張: OSに「ディスクが大きくなった」と教える (pvresize)。
  3. 論理ボリューム(LV)拡張: VG内の空き容量を使ってLVを広げる (lvextend)。
  4. ファイルシステム拡張: 最後にファイルシステムに「使える領域が増えた」と教える (xfs_growfs など)。

※パーティションがある構成の場合は、手順2の前に growpart コマンドでパーティション自体の拡張が必要です。

やってみた！LVM設定から拡張までの全手順

実際にEC2インスタンスを立てて、LVMの設定からEBS拡張までやってみます。
今回は検証のため新規にLVMを構築しましたが、既存環境でも手順は同じです。

1. EC2準備とEBSアタッチ

まず、Amazon Linux 2023 のEC2インスタンスを用意し、追加で100GBのEBSボリュームをアタッチしました。

lsblk でパーティションの有無を確認します。
/dev/nvme1n1 として100GBのディスクが見えています。

[ec2-user@~]$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0    8G  0 disk 
├─nvme0n1p1   259:1    0    8G  0 part /
...
nvme1n1       259:4    0  100G  0 disk

2. LVMの初期設定

ここから、アタッチした /dev/nvme1n1 をLVMで使えるように設定していきます。

▼ lvm2パッケージをインストール

[ec2-user@~]$ sudo dnf install lvm2 -y

▼ PV (物理ボリューム) を作成

[ec2-user@~]$ sudo pvcreate /dev/nvme1n1
  Physical volume "/dev/nvme1n1" successfully created.

# 確認
[ec2-user@~]$ sudo pvs
  PV             VG   Fmt  Attr PSize   PFree  
  /dev/nvme1n1        lvm2 ---  100.00g 100.00g

▼ VG (ボリュームグループ) を作成 (vg01という名前で)

[ec2-user@~]$ sudo vgcreate vg01 /dev/nvme1n1
  Volume group "vg01" successfully created

# 確認
[ec2-user@~]$ sudo vgs
  VG   #PV #LV #SN Attr   VSize    VFree   
  vg01   1   0   0 wz--n- <100.00g <100.00g

▼ LV (論理ボリューム) を作成 (lv01という名前で、VGの全領域を使用)

[ec2-user@~]$ sudo lvcreate -l 100%FREE -n lv01 vg01
  Logical volume "lv01" created.

# 確認
[ec2-user@~]$ sudo lvs
  LV   VG   Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv01 vg01 -wi-a----- <100.00g

3. ファイルシステム作成とマウント

LVMで領域を切り出せたので、ファイルシステム（今回はXFS）を作成してマウントします。

▼ XFSファイルシステムを作成

[ec2-user@~]$ sudo mkfs.xfs /dev/vg01/lv01
meta-data=/dev/vg01/lv01         isize=512    agcount=4, agsize=6553584 blks
...

▼ /var ディレクトリにマウント

[ec2-user@~]$ sudo mount -t xfs /dev/vg01/lv01 /var

# マウントされたことを確認
[ec2-user@~]$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
...
nvme1n1       259:4    0  100G  0 disk 
└─vg01-lv01   253:0    0  100G  0 lvm  /var

これで準備完了です！

4. EBSボリュームの拡張

まず、AWSコンソールでEBSボリュームのサイズを 100GB → 200GB に変更します。

変更後、EC2インスタンスで lsblk を見ると…

[ec2-user@~]$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
...
nvme1n1       259:4    0  200G  0 disk   <-- ディスクは200Gになった
└─vg01-lv01   253:0    0  100G  0 lvm  /var  <-- でもLVMはまだ100Gのまま

ディスク(nvme1n1)は200GBになりましたが、LVM(vg01-lv01)は100GBのまま。これを順番に広げていきます。

5. LVMとファイルシステムの拡張

▼ PV (物理ボリューム) を拡張
pvresize で、物理ディスクのサイズ変更をLVMに認識させます。

[ec2-user@~]$ sudo pvresize /dev/nvme1n1
  Physical volume "/dev/nvme1n1" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized

# 確認。PFree(空き)が100GB増えた！
[ec2-user@~]$ sudo pvs
  PV             VG   Fmt  Attr PSize    PFree  
  /dev/nvme1n1   vg01 lvm2 a--  <200.00g 100.00g

▼ LV (論理ボリューム) を拡張
lvextend で、VG内の空き容量をすべて使ってLVを広げます。

[ec2-user@~]$ sudo lvextend -l +100%FREE /dev/vg01/lv01
  Size of logical volume vg01/lv01 changed from <100.00 GiB to <200.00 GiB.
  Logical volume vg01/lv01 successfully resized.

# 確認。LSizeが200GBになった！
[ec2-user@~]$ sudo lvs
  LV   VG   Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv01 vg01 -wi-ao---- <200.00g

この時点で lsblk を見ると、LVMのサイズも200GBになっています。

[ec2-user@~]$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
...
nvme1n1       259:4    0  200G  0 disk 
└─vg01-lv01   253:0    0  200G  0 lvm  /var  <-- 200Gになった！

▼ 最後の仕上げ！ファイルシステムを拡張
df コマンドで見ると、まだファイルシステムは100GBのままです。

[ec2-user@~]$ df -hT
Filesystem            Type   Size  Used Avail Use% Mounted on
...
/dev/mapper/vg01-lv01 xfs    100G  747M  100G   1% /var

xfs_growfs コマンドで、ファイルシステムをLVの最大サイズまで広げます。

[ec2-user@~]$ sudo xfs_growfs -d /var
data blocks changed from 26213376 to 52427776

# 再度確認
[ec2-user@~]$ df -hT
Filesystem            Type   Size  Used Avail Use% Mounted on
...
/dev/mapper/vg01-lv01 xfs    200G  1.5G  199G   1% /var

これで、OSからも200GBとして認識されるようになりました！拡張作業は完了です。

AWS特有の「デバイス名」問題

LVMと直接は関係ありませんが、少し困ったのでまとめておきます。
AWSで地味にハマるのが、デバイス名の違いです。マネジメントコンソールで表示されるデバイス名（例: /dev/sdf）と、EC2インスタンス内で lsblk を叩いた時の名前（例: /dev/nvme1n1）が違うことがあります。

これはインスタンスの世代によって変わるのが原因です。

  • Nitro世代 (新しい): T3, M5, C5 など。NVMeデバイスとして認識され、/dev/nvme0n1, /dev/nvme1n1 … と表示される。
  • Xen世代 (古い): T2, M4, C4 など。/dev/xvda, /dev/xvdf … と表示される。
コンソールでの表示 Nitro世代の lsblk Xen世代の lsblk
/dev/sda1 (ルート) /dev/nvme0n1p1 /dev/xvda1
/dev/sdf /dev/nvme1n1 /dev/xvdf
/dev/sdg /dev/nvme2n1 /dev/xvdg

どのディスクがどれに対応するのか分からなくなったら、lsblk -o +SERIAL コマンドを使いましょう。シリアルナンバー（ボリュームID）が表示されるので、コンソールの情報と突き合わせて特定できます。

[root@~]# lsblk -o +SERIAL
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS SERIAL
nvme0n1     259:0    0   15G  0 disk             volabcdefg1234567890  <-- コレ
├─nvme0n1p1 259:2    0    1M  0 part
...
nvme1n1     259:1    0  185G  0 disk             volabcdefg1234567890  <-- コレ
└─vg01-lv01 253:0    0  185G  0 lvm  /var

まとめ

今のAWS環境ではシンプルでクラウドネイティブな解決策がたくさんあり、LVMを新規で導入する機会は減っているかと思います。

  • EBSなら数クリックで容量変更できる
  • 複数サーバーでファイル共有したいなら EFS
  • 大容量データを置きたいなら S3

ただ、オンプレミス環境から移行したシステムをメンテナンスする際や、RAID0構成でパフォーマンスアップさせたくてLVMを導入するなど、LVMと向き合わないといけない場面もまだまだあるかと思います。。そんな時に、この記事が誰かの助けになれば嬉しいです！

参考

LVM パーティションで EBS ボリュームを拡張する方法を教えてください
https://repost.aws/ja/knowledge-center/ebs-extend-volume-lvm-partitions

LVM を使用して EBS ボリュームのパーティションに論理ボリュームを作成する方法を教えてください
https://repost.aws/ja/knowledge-center/create-lv-on-ebs-partition

Amazon EBS および RAID の構成
https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/raid-config.html