ディスクを拡張する:LVM で止めずに広げる
本番サービスが動いたまま、仮想ディスクを Proxmox で hot-add し、ゲスト側で LVM を使って 8G から 15G へオンライン拡張します。クラウドの「ストレージを増やす」ボタンの裏側にある 2 層を、自分の手で通します。
| 所要時間 | 約 50 分 |
|---|---|
| 章タイプ | standard |
| 前提知識 | Part 1 Chapter 7(ユーザとパーミッション)・Part 3 Chapter 1(systemd サービス) |
| 使用機材 | 踏み台 workstation01 + 演習用サーバ learner01(Proxmox 管理操作あり) |
| 関連章 | 前: Chapter 4「sudo と SSH 鍵でアクセスを固める」/ 後: Chapter 6「パッチを当てる・配る」 |
「足りない」を、止めずに足す
本番サービスのディスクが満杯に近づいてきた ── 運用者ならいつか必ず直面するシナリオです。クラウドであれ、自社サーバであれ、「ディスク容量の枯渇」はサービス停止に直結する障害です。
Filesystem Size Used Avail Use% Mounted on /dev/mapper/ubuntu--vg-ubuntu--lv 15G 14G 512M 97% /
この状況でやりたいことはただ一つ:サービスを止めずにディスクを広げる。
Linux の標準的な解が LVM(Logical Volume Manager) です。「ディスクを仮想化する仕組み」とも言えるもので、サービスを動かしたまま、マウントしたまま、ファイルシステムを広げることができます。
この章は 2層跨ぎ が学習の核心です。
Proxmox 層 ── 仮想ディスク(thin disk)を稼働中の VM に追加する
↕ ゲスト OS がリブートなしに sdb として認識
ゲスト層 ── sdb を LVM に組み込み、LV を 8G から 15G へオンライン拡張する
クラウドの「ストレージを増やす」ボタン 1 つの裏側では、まさにこの 2 層が動いています。本章では 両層を自分の手で操作し、「増やす」という動詞が何を意味するかを腹落ちさせます。
この章を終えるとできること
容量管理の 4 動詞を手に覚えます。
読み取る
せず sdb を出す
8G→15G に伸ばす
クリーン状態に戻す
LVM のしくみを解きほぐす
1. LVM の 3 層構造:「柔らかいディスク」の仕組み
従来の Linux では /dev/sda を直接 mkfs してマウントするのが普通でした。この場合、一度確保した容量は簡単に変えられません。
LVM はブロックデバイスとファイルシステムの間に 3 層の抽象レイヤー を挟みます。
物理デバイス
/dev/sdb ← 実際の物理(or 仮想)ディスク
│
▼ pvcreate
┌─────────────────────────────────────────┐
│ PV (Physical Volume) │ ← 物理ボリューム
│ /dev/sdb を LVM で使えるよう登録した単位 │
└─────────────────────────────────────────┘
│ vgcreate labdata
▼
┌─────────────────────────────────────────┐
│ VG (Volume Group) │ ← ボリュームグループ
│ 1 つ以上の PV をまとめた「容量の束」 │
│ ここにディスクを追加すると VG が広がる │
└─────────────────────────────────────────┘
│ lvcreate -L 8G -n vol
▼
┌─────────────────────────────────────────┐
│ LV (Logical Volume) │ ← 論理ボリューム
│ VG から切り出した「柔らかいパーティション」│
│ lvextend で後から大きくできる │
└─────────────────────────────────────────┘
│ mkfs.ext4 / mount
▼
/mnt/lab ← ファイルシステム(ここにデータを置く)
| レイヤー | コマンド | 役割 |
|---|---|---|
| PV | pvcreate / pvdisplay | 物理デバイスを LVM に登録 |
| VG | vgcreate / vgdisplay | PV を束ねた容量プール |
| LV | lvcreate / lvdisplay / lvextend | 実際に使う「仮想パーティション」 |
2. 「2 層跨ぎ」の仕組み:Proxmox とゲスト OS がそれぞれ何を見るか
この章で行う演習は、1 台のサーバ内で完結しません。
┌──────────────────────────────────────────────────────────────┐ │ Proxmox ホスト │ │ │ │ local-lvm ストレージプール(thin-provisioned) │ │ ┌───────────────────────────────────────────────────────┐ │ │ │ thin disk: 16 GiB ← qm set でここに作る │ │ │ └───────────────────────────────────────────────────────┘ │ │ │ SCSI over virtio │ │ ▼ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ learner01 (VM) │ │ │ │ │ │ │ │ /dev/sdb ← ゲスト OS はこれしか見えない │ │ │ │ (Proxmox の thin disk が何 GB 確保されているかは │ │ │ │ ゲスト OS からは見えない。見えるのはデバイスだけ) │ │ │ └─────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────┘
Proxmox 層 では qm set コマンドでディスクを VM の設定に追加します。するとゲスト OS は再起動なしに /dev/sdb という新しいブロックデバイスとして認識します。これが online hot-add です。
ゲスト層 では、新しく見えた /dev/sdb を LVM に組み込み、ファイルシステムを作り、マウントします。
実機価値: クラウドの「ストレージ拡張」ボタンを押す裏側では、この 2 層が動いています。
sdbが突然現れる瞬間、lvextendとresize2fsの直後にdfの数字が変わる瞬間 ── これは実際にデバイスを足して伸ばす操作でしか体感できません。
3. オンライン拡張の仕組み:なぜマウントしたまま広げられるか
ファイルシステムを広げるには、まず土台のブロック領域(LV)を広げ、次にその上のファイルシステムを新しい境界まで伸ばす、という 2 段階が必要です。LVM を使うと前者(土台の拡張)が柔軟に行え、ext4 は後者をマウントしたまま実行できます。
# LV を広げる(論理ボリュームの境界を変更) sudo lvextend -L +7G /dev/labdata/vol # ext4 ファイルシステムを LV の新しい境界まで広げる sudo resize2fs /dev/labdata/vol
なぜマウントしたまま広げられるか: ext4 は online resize(オンライン拡張)に対応しており、resize2fs はマウント中でもブロック数を増やせます。これは LVM 固有の機能ではなく、土台のブロック領域さえ安全に広げられれば通常のパーティション上でも成立します。ただし LVM は「土台を後から柔軟に広げる」部分を容易にするため、オンライン拡張と非常に相性が良いのです。
ポイント:
lvextendだけでは LV の「器」が広がっただけで、ファイルシステムはまだ古いサイズのまま。resize2fsを忘れるとdfの数字は変わりません。
4. ITIL キャパシティ管理の型
この章で体験する一連の操作は、ITIL の「キャパシティ・性能管理」プラクティスの型に沿っています。
監視(df / lsblk)→ 逼迫検知(Use% が閾値超え)→ 容量拡張(lvextend + resize2fs)
↑ │
└───────────── 次回の監視サイクルへ ──────────────────────┘
本番環境では「監視アラート → 運用チームへのエスカレーション → 容量拡張作業 → 事後確認」という流れが標準的です。この章の演習はその「拡張作業」の部分を丸ごと手で通します。
試してみよう:ディスクを足して、止めずに広げる
仮想ディスクを Proxmox から追加し、ゲスト OS 内で LVM を構築、容量を逼迫させてからマウントしたまま 8G → 15G に拡張する一連の流れを通します。
| 項目 | 値 |
|---|---|
| 出発地点 | 踏み台 workstation01 |
| 演習対象 | learner01(ゲスト層の操作) |
| ゲスト操作ユーザー | ops(NOPASSWD sudo) |
| 追加ディスク容量 | 16 GiB(演習用。章末に撤去) |
| 所要時間 | 約 40 分(9 ステップ) |
lsblk / pvdisplay / vgdisplay で残っているレイヤーを確認し、残っているものから順に削除できます。STEP 01 · 現在の状態を確認する
workstation01 から learner01 に SSH 接続し、ディスクとファイルシステムの現状を把握します。
# workstation01 から learner01 へ接続 ssh ops@learner01 # ブロックデバイスを一覧表示 lsblk
表示イメージ(演習ディスク追加前・loop 省略):
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 32G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 2G 0 part /boot └─sda3 8:3 0 30G 0 part └─ubuntu--vg-ubuntu--lv 252:0 0 15G 0 lvm / sr0 11:0 1 1024M 0 rom
物理ディスクは sda だけで、演習用の sdb はまだありません。この環境の root(/)は最初から LVM 上にあります(sda3 の上に ubuntu-vg という VG が組まれ、そこから ubuntu-lv を切り出して / にしている)。この後の演習で作る labdata は、この ubuntu-vg とは別の2 つ目の VG になります(vgs を打つと 2 つ並びます)。
# ファイルシステムの使用状況を確認 df -h
前セッションの残骸チェック:
lsblkにlabdata-volが見えたり、dfに/mnt/labが出ている場合は、前回の演習をクリーンアップ途中で中断した名残です。先に STEP ⑨「章末クリーンアップ」の手順(該当するレイヤーから)を実行してsdaのみのクリーン状態に戻してから、STEP ① に戻ってください。
STEP 02 · Proxmox から演習ディスクを追加する
Proxmox ホストで実行します(workstation01 から別ターミナルを開いて ssh ops@<Proxmox管理IP> で接続)。<Proxmox管理IP> は受講環境の案内に記載された IP に読み替えてください。
# VMID を確認 qm list | grep learner01 # 例: 103 learner01 running 4096 ... (左端が VMID) # 稼働中の learner01 に 16 GiB ディスクを scsi1 として追加 qm set <VMID> --scsi1 local-lvm:16
成功すると以下のように出力されます:
update VM <VMID>: -scsi1 local-lvm:vm-<VMID>-disk-1,size=16G
ポイント:
--scsi1は SCSI バス上のスロット番号。sdaが scsi0 に対応するため、今回は scsi1 に追加します。VM は再起動不要でこのディスクを認識します。
📔 発展:Proxmox 層で thin pool を覗く(任意・クラウドでは見えない裏側)
Proxmox の
local-lvmは thin-provisioned(実際に書き込んだ分だけ物理容量を消費)です。「16 GiB のディスクを足した」「7 GiB のファイルを作った」といった操作が物理プールにどう表れるかを観察します。ここで大事なのは 測る対象です。プール全体(
pve/data)のdata_percentは他 VM の書き込みも合算した値なので、演習分だけを読み取れません。代わりに、今回追加した演習ディスクの thin LV 個別のData%を見ます。bash · Proxmox ホスト# ① 演習ディスク個別の実消費率(← これを見る) sudo lvs pve -o lv_name,lv_size,data_percent | grep vm-<VMID>-disk # ② 参考:プール全体(他 VM 込みの集計値。演習分は読めない) sudo lvs pve/data -o lv_name,data_percent,metadata_percent演習の各段階で演習ディスクの
Data%を測ると、次のように動きます(実機実測):
段階 ゲスト dfUse%演習ディスクの物理 Data%換算実消費 ディスクを追加した直後 (未マウント) 0.00% 0 構築+ fallocate -l 7G(予約)の後96% 1.20% ≒ 0.19 GiB 予約領域に 6 GiB を実書き込みした後 96% 38.70% ≒ 6.19 GiB 章末でこの LV を破棄した後 — 消滅(pool の Data%は演習前と同じ 27.01% に復帰)— (換算実消費 = 演習ディスクの仮想サイズ 16 GiB ×
Data%。例: 38.70% × 16 GiB ≒ 6.19 GiB。単位は 2 進の GiB で統一しています=fallocate/ddのGも GNU 系では GiB。)注意(3 行目は任意の追試): 表の 3 行目「6 GiB 実書き込み」は演習の必須手順ではありません。STEP ⑦ の
fallocateは容量を「予約」するだけで実データは書きません。この行を自分で再現したいときだけ、予約領域に実データを書きます:sudo dd if=/dev/zero of=/mnt/lab/fill.img bs=1M count=6144 conv=notrunc oflag=direct; sync(6 GiB を上書き)。その後に Data% を測り直すと、予約だけの 1.20% から 38.70% へ跳ねるのが見えます。読み取れることは 4 つです。
- 割り当て≠即消費: 16 GiB を確保しても、書き込む前は物理消費 0.00%。
- 構築・予約だけでは太らない: PV/VG/LV を作り、ext4 を作り、7 GiB を
fallocateで「予約」する ── ここまで全部やっても物理消費は 1.20%(≒0.19 GiB)にとどまります(この 1.20% にはmkfs等の構築分も含みます)。ゲストのdfは 96% に跳ね上がるのに、です。fallocateが確保するのは領域の「権利」(unwritten extent)で、データそのものは書かないからです。- 書いた分だけ太る: 予約領域に 6 GiB を実際に書き込むと
Data%は 38.70%(≒6.19 GiB)まで伸びます。このときゲストのdfは 96% のまま動きません。物理をいくら消費したかは、ゲストのdfでは決して見えず、Proxmox の物理層に降りて初めて見えます。- 破棄で返る: 章末で演習ディスク(Proxmox 側の thin LV)を
qm disk unlinkで破棄すると、pool のData%は演習前と同じ 27.01% へ戻ります。ブロックをプールへ返す契機は、ゲスト内のlvremoveではなくこの Proxmox 側の thin LV 破棄です。※厳密にはMeta%は 1.49→1.50 と微増するため「pool の使用データ量(Data%)が一致」という意味です。補足: 章末で演習ディスク(thin LV)そのものを破棄すれば、その LV が占めていたブロックは母体プールへ返却されます。一方、thin ディスクを残したまま中のファイルだけを削除した場合は、ゲスト側の
fstrimや Proxmox のdiscardオプションで初めて未使用ブロックが返却されます。両者は別物です。
STEP 03 · ゲストで新しいデバイスを確認する
learner01 のターミナルに戻り、ディスクが認識されたかを確認します。
lsblk
表示イメージ(ディスク追加直後・loop 省略):
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 32G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 2G 0 part /boot └─sda3 8:3 0 30G 0 part └─ubuntu--vg-ubuntu--lv 252:0 0 15G 0 lvm / sdb 8:16 0 16G 0 disk sr0 11:0 1 1024M 0 rom
sdb が現れました。Proxmox に追加した仮想ディスクが、リブートなしにゲスト OS に届いています。これが「2 層跨ぎ」の最初の瞬間です。
sdbが表示されない場合: まず数秒待ってlsblkを再実行してください。それでも出なければsudo udevadm settleを実行してから再確認します。
注意: デバイス名(
sdb)は環境により変わり得ます。以降のコマンドを打つ前にlsblkでサイズ(16G)とマウントが無いことを確認し、操作対象が今回追加した演習ディスクであることを必ず確かめてください。
STEP 04 · PV(物理ボリューム)を作成する
/dev/sdb を LVM の管理下に置きます。
# /dev/sdb を PV として初期化 sudo pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created.
# PV の情報を確認 sudo pvdisplay /dev/sdb
"/dev/sdb" is a new physical volume of "16.00 GiB" --- NEW Physical volume --- PV Name /dev/sdb VG Name PV Size 16.00 GiB ...
VG Name がまだ空なのは、次のステップで VG を作るためです。
STEP 05 · VG(ボリュームグループ)と LV(論理ボリューム)を作成する
PV をもとに VG を作り、そこから 8G の LV を切り出します。
# VG を作成(名前: labdata) sudo vgcreate labdata /dev/sdb
Volume group "labdata" successfully created
# LV を作成(名前: vol、サイズ: 8G) sudo lvcreate -L 8G -n vol labdata
Logical volume "vol" created.
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 32G 0 disk ├─sda3 8:3 0 30G 0 part │ └─ubuntu--vg-ubuntu--lv 252:0 0 15G 0 lvm / ... sdb 8:16 0 16G 0 disk └─labdata-vol 252:1 0 8G 0 lvm
sdb の下に labdata-vol が見えます。VG(labdata)から 8G の LV(vol)が切り出されました。残り 8G は VG 内に未使用領域として確保されており、後の拡張で使います。(デバイス番号 252:0 は OS が使っている root LV、252:1 が今回作った演習用 LV です。)
STEP 06 · ファイルシステムを作成してマウントする
LV は「器」に過ぎません。ファイルを置くには ext4 ファイルシステムを作り、マウントします。
# ext4 ファイルシステムを作成 sudo mkfs.ext4 /dev/labdata/vol
mke2fs 1.47.0 (5-Feb-2023) Creating filesystem with 2097152 4k blocks and 524288 inodes ... Writing superblocks and filesystem accounting information: done
# マウントポイントを作成してマウント sudo mkdir -p /mnt/lab sudo mount /dev/labdata/vol /mnt/lab # マウントを確認 df -h /mnt/lab
Filesystem Size Used Avail Use% Mounted on /dev/mapper/labdata-vol 7.8G 24K 7.4G 1% /mnt/lab
8G の LV ですが、ファイルシステムのメタデータ領域があるため実際に使えるのは 7.8G です。Use% 1% ── 空っぽの状態です。
STEP 07 · 容量逼迫を演出する
「8G では足りなくなった」状況を作り出します。fallocate コマンドでダミーファイルを作り、LV を意図的に埋めます。
# 7 GB のダミーファイルを作成(容量逼迫を演出) sudo fallocate -l 7G /mnt/lab/fill.img # 容量状況を確認 df -h /mnt/lab
Filesystem Size Used Avail Use% Mounted on /dev/mapper/labdata-vol 7.8G 7.1G 370M 96% /mnt/lab
Use% 96% まで跳ね上がりました。/mnt/lab にはあと 370 MB しか空きがありません。このまま運用すると、ログやデータが書けなくなりサービスに影響が出ます。
ITIL 的な読み方: 多くの環境では 90% 前後を閾値に置きますが、実際には使用率の増加速度や残りの絶対容量も見て設計します(同じ 96% でも 100GB 空いているか 300MB しかないかで緊急度は違います)。今回の 96% は多くの監視で警戒域です。この数字を
df -hで見つけた瞬間が「キャパシティ管理」の起点です。
STEP 08 · オンラインで LV を拡張する
マウントを解除せず、/mnt/lab を使えるまま LV を 8G → 15G に広げます。
# LV を 7G 拡張する(合計 15G になる) sudo lvextend -L +7G /dev/labdata/vol
Size of logical volume labdata/vol changed from 8.00 GiB (2048 extents) to 15.00 GiB (3840 extents). Logical volume labdata/vol successfully resized.
この時点で LV の「器」は 15G になりましたが、ファイルシステムはまだ 7.8G を認識したままです。
# ファイルシステムを LV の新しいサイズまで拡張する sudo resize2fs /dev/labdata/vol
resize2fs 1.47.0 (5-Feb-2023) Filesystem at /dev/labdata/vol is mounted on /mnt/lab; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 2 The filesystem on /dev/labdata/vol is now 3932160 (4k) blocks long.
on-line resizing required と表示されていることに注目してください。マウントしたままの拡張が行われています。
# 拡張後の容量を確認 df -h /mnt/lab
Filesystem Size Used Avail Use% Mounted on /dev/mapper/labdata-vol 15G 7.1G 7.0G 51% /mnt/lab
7.8G → 15G に広がりました。ダミーファイル 7G は /mnt/lab/fill.img に残ったまま、使用率は 96% → 51% に下がっています。サービスを一切止めることなく容量問題を解消しました。
lsblk | grep labdata
└─labdata-vol 252:1 0 15G 0 lvm /mnt/lab
df が 15G を示しています。マウントしたまま、サービスを止めることなく、LV を 8G から 15G に拡張しました。STEP 09 · 章末クリーンアップ:演習前のクリーン状態に戻す
この演習で作ったリソースを全て撤去し、learner01 をクリーン状態に復元します。
# マウントを解除する sudo umount /mnt/lab # LV を削除する(確認プロンプトが出たら y を入力) sudo lvremove /dev/labdata/vol # VG を削除する sudo vgremove labdata # PV を削除する sudo pvremove /dev/sdb # ゲスト側の状態を確認(labdata-vol が消えていること) lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 32G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 2G 0 part /boot └─sda3 8:3 0 30G 0 part └─ubuntu--vg-ubuntu--lv 252:0 0 15G 0 lvm / sdb 8:16 0 16G 0 disk sr0 11:0 1 1024M 0 rom
sdb は残っていますが、LVM の構造(labdata-vol)が消えていることを確認します。次に Proxmox ホスト に戻り、演習ディスクを VM 設定から削除します。
# VM 設定から scsi1 を削除 qm set <VMID> --delete scsi1 # どの unusedN に退避したか確認する qm config <VMID> | grep unused # 例: unused0: local-lvm:vm-<VMID>-disk-1 # 未使用ディスクを破棄する(上で確認した unusedN を指定) qm disk unlink <VMID> --idlist <unusedN>
# ゲスト側でも sdb が消えたことを確認 lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 32G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 2G 0 part /boot └─sda3 8:3 0 30G 0 part └─ubuntu--vg-ubuntu--lv 252:0 0 15G 0 lvm / sr0 11:0 1 1024M 0 rom
sdb が消えました。learner01 は演習前のクリーン状態に戻っています。
| 確認項目 | 期待値 |
|---|---|
learner01 の lsblk | sda のみ(sdb なし、labdata-vol なし) |
| Proxmox の VM 設定 | scsi1 なし・未使用ディスクなし |
/mnt/lab のマウント状態 | df に /mnt/lab が出ない |
詰まったら
- ハマりポイント: よくある詰まりと対処を以下に列挙しています
- AI に相談: 演習中の疑問を章の内容を踏まえて AI に聞けます
ハマりポイント
STEP ③ で sdb が出てこない
まず数秒待って lsblk を再実行してください。それでも出なければ sudo udevadm settle を実行してから再確認します(partprobe は既存パーティション表の再読込用で、hot-add の検出には必ずしも効きません)。
それでも出ない場合は Proxmox ホスト側で qm config <VMID> を確認し、scsi1 が設定されているかを確かめてください。
STEP ⑧ で lvextend の後に df が変わらない
lvextend だけでは LV という「器」のサイズが広がるだけで、その中にある ext4 ファイルシステムは古いブロック数のまま動き続けます。df -h /mnt/lab を確認しても数字は 7.8G のままで変化しません。
必ず sudo resize2fs /dev/labdata/vol を続けて実行してください。on-line resizing required が表示されれば正常です。
STEP ⑨ で umount が「デバイスがビジー」と言う
cd / で /mnt/lab の外に出てから再実行してください。自分のシェルが /mnt/lab 以下のディレクトリにいると「ビジー」になります。
cd / sudo umount /mnt/lab
それでもビジーの場合は lsof /mnt/lab でどのプロセスがマウントポイントを掴んでいるかを確認してください。
上記以外の詰まりと対処を一覧にまとめます。
| 起きたこと | 対処 |
|---|---|
⑤ vgcreate が「PV が見つからない」と言う | pvcreate /dev/sdb から再実行。pvdisplay で状態を確認 |
⑥ mount が「既にマウント済み/使用中」と言う | 前演習の残骸が /mnt/lab を掴んでいる可能性。mount | grep /mnt/lab で確認し、不要なら sudo umount /mnt/lab してから再実行(mkdir -p は冪等なので作り直し不要) |
⑧ resize2fs が「Bad magic number」と言う | mkfs.ext4 で作成した LV か確認。lsblk -f /dev/labdata/vol で fs タイプを確認 |
⑨ lvremove が失敗する | sudo umount /mnt/lab が済んでいるか確認 |
| ⑨ クリーンアップ途中でターミナルが落ちた | lsblk / pvdisplay / vgdisplay で残っているレイヤーを確認し、残っているものから順に削除 |
Proxmox Web UI の「ハードウェア」に scsi1 が残る | qm set <VMID> --delete scsi1 を Proxmox ホストで再実行 |
AI に相談
修了確認
この章で体験した LVM の仕組みとオンライン拡張の 2 ステップを確認します。
問 1 · LVM の 3 層構造
LVM を構成する PV・VG・LV それぞれの役割を 1 行ずつ説明してください。また、今回の演習で VG 内に 8G の LV を切り出したあと、残りの容量はどこにあり、何のために使えますか?
解答を見る
| 層 | 役割 |
|---|---|
| PV(Physical Volume) | 物理(または仮想)ディスクを LVM の管理下に登録した単位。pvcreate で作る |
| VG(Volume Group) | 1 つ以上の PV をまとめた容量プール。ここにディスクを追加することで後から容量を増やせる |
| LV(Logical Volume) | VG から切り出した仮想パーティション。mkfs してマウントする実体。lvextend で後から広げられる |
残り容量について: 16G の sdb から 8G の LV を切り出した場合、VG labdata 内に約 8G の「未割当領域(Free PE)」が残ります。この領域は lvextend コマンドで既存 LV を広げるために使えます(今回の lvextend -L +7G がその操作です)。また、新たに別の LV を作ることにも使えます。
# VG の空き容量を確認するコマンド sudo vgdisplay labdata | grep "Free"
問 2 · オンライン拡張の 2 ステップ
/mnt/lab がマウントされた状態で LV を 8G から 15G に拡張するには、lvextend の後にもう 1 つコマンドを実行する必要があります。それはどのコマンドですか? また、そのコマンドを実行しないとどうなりますか?
解答を見る
必要なコマンドは resize2fs です。
sudo lvextend -L +7G /dev/labdata/vol # LV の「器」を広げる sudo resize2fs /dev/labdata/vol # ext4 ファイルシステムを広げる
実行しなかった場合: lvextend だけでは LV という「器」のサイズが広がるだけで、その中にある ext4 ファイルシステムは古いブロック数のまま動き続けます。df -h /mnt/lab を確認しても数字は 7.8G のままで変化しません。
覚え方: lvextend = 「器を広げる」、resize2fs = 「中身の地図を更新する」。両方やって初めて「拡張完了」です。
段階ヒント(問 1・問 2 共通)
段階ヒント 1 段目:LVM は「下から作って上から壊す」
LVM の操作は順序を守れば迷いません。作る順序は PV → VG → LV → ファイルシステム → マウント。壊す順序はその逆(アンマウント → LV 削除 → VG 削除 → PV 削除)。詰まったら今どのレイヤーに自分がいるかを lsblk・pvdisplay・vgdisplay・lvdisplay で確認してみてください。
段階ヒント 2 段目:具体的なコマンド手順
# 構築フェーズ sudo pvcreate /dev/sdb sudo vgcreate labdata /dev/sdb sudo lvcreate -L 8G -n vol labdata sudo mkfs.ext4 /dev/labdata/vol sudo mkdir -p /mnt/lab sudo mount /dev/labdata/vol /mnt/lab df -h /mnt/lab # 7.8G / 1% # 逼迫演出 sudo fallocate -l 7G /mnt/lab/fill.img df -h /mnt/lab # 7.8G / 96% # 拡張フェーズ(マウントしたまま) sudo lvextend -L +7G /dev/labdata/vol # ↑ LV の「器」が 15G になる。ただし df はまだ変わらない。 sudo resize2fs /dev/labdata/vol df -h /mnt/lab # 15G / 51% ← 成功
よくある落とし穴: lvextend だけで終わると df は変わらない → 必ず resize2fs を続ける。
答えを見る(フルコマンド列)
# Proxmox ホスト qm set <VMID> --scsi1 local-lvm:16 # learner01(ops) lsblk # sdb を確認 sudo pvcreate /dev/sdb sudo vgcreate labdata /dev/sdb sudo lvcreate -L 8G -n vol labdata sudo mkfs.ext4 /dev/labdata/vol sudo mkdir -p /mnt/lab sudo mount /dev/labdata/vol /mnt/lab df -h /mnt/lab # 7.8G / 1% sudo fallocate -l 7G /mnt/lab/fill.img df -h /mnt/lab # 7.8G / 96% sudo lvextend -L +7G /dev/labdata/vol sudo resize2fs /dev/labdata/vol df -h /mnt/lab # 15G / 51% ← 成功 sudo umount /mnt/lab sudo lvremove /dev/labdata/vol # y sudo vgremove labdata sudo pvremove /dev/sdb lsblk # sdb のみ(LVM 構造なし) # Proxmox ホスト qm set <VMID> --delete scsi1 qm config <VMID> | grep unused qm disk unlink <VMID> --idlist <unusedN>
このフローで覚えること:
pvcreate→vgcreate→lvcreateの 3 ステップで「ディスクを LVM に組み込む」lvextendで「器を広げ」、resize2fsで「中身を広げる」。両方ないと完成しない- クリーンアップは「上から下へ」(アンマウント → LV → VG → PV)
次の章へ
この章では「ディスクの変化」を扱いました。次の Chapter 6 では「ソフトウェアの変化」を扱います。セキュリティパッチや機能更新を安全に適用し、それを複数台のサーバに展開する ── 実際の運用チームが毎月実施している作業を、本演習環境で end-to-end で体験します。
apt update / upgradeでセキュリティパッチを安全に当てる手順を学ぶ- 複数台のサーバへ同じパッチを展開する(ITIL 変更実現・リリース管理の型)
- パッチ後の動作確認と、問題が起きたときの切り戻し判断まで体験する
もっと知りたい方へ
/etc/fstabへの永続マウント: 今回はmountコマンドで一時的にマウントしましたが、再起動後も自動マウントするには/etc/fstabに追記します。blkid /dev/labdata/volで UUID を取得しUUID=... /mnt/lab ext4 defaults 0 2の形式で記述しますvgextendで VG を拡張する: VG に PV(新しいディスク)を追加して容量プールを広げる操作。本章では 1 本の sdb から操作しましたが、運用では複数ディスクを VG に追加するのが一般的ですxfs_growfs: ext4 ではなく XFS ファイルシステムを使う場合はresize2fsの代わりにxfs_growfs /mnt/labを使います(XFS はマウントした状態での拡張が前提)lvreduce: LV を小さくする操作。拡張とは逆で順序が命です。ext4 では ①アンマウント → ②resize2fsでファイルシステムを先に縮小 → ③lvreduceで LV を縮小、の順に行います(LV を先に縮めるとファイルシステムのデータ領域を削り取って壊れます)。オンライン拡張と違い、縮小はマウントしたままできません- root(
/)自身を広げる: この演習環境の/は 30G のパーティション(sda3)の上に組まれた 15G の LV(ubuntu-vg/ubuntu-lv)でした。VG(ubuntu-vg)に空きが残っていれば、sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lvの 1 コマンド(-rは resize2fs を同時実行)で root を停止せず広げられます(空きの有無はsudo vgdisplay ubuntu-vgのFree PE / Sizeで確認)。本章のlabdataと同じ原理が OS のルートにも効きます - Part 6 への伏線: 今回は「LV を消費・拡張する側」を扱いました。Part 6「ストレージと iSCSI」では「ストレージを提供する側」(iSCSI ターゲット・ZFS プール)を構築します。本章の LVM 知識が、ネットワーク越しのブロックデバイスを扱う際の土台になります