注意事項
- これは失敗した手順です。
- なのでやってはいけないやつです。
- あくまでも私の失敗したときの記録として残します。
何をやりたかったのか？
「KVMで作成したディスク(LVM)を500→200程度に切り詰めようとしたところ失敗した」。
環境
- ホスト
- Rocky Linux 8.6
- KVM
- ゲスト
- Rocy Linux 9.7
- シックボリュームで構築
1. ゲストOS内でのデータ整理
まず、ディスク容量を空けるために /home を削除・再作成し、使用量を削減しました。
- 状態: 物理ボリューム（PV）500GB に対し、中身の合計（Root+Home+Swap）を 170GB 程度まで圧縮。
2. データの「前詰め」作業（pvmove）
LVMの「末尾」にあるデータを物理的にディスクの「先頭」へ移動させました。
- コマンド:
sudo pvmove --alloc anywhere /dev/vda2 - 結果:
pvdisplay -mにて、使用中セグメントが 0 ～ 73153 PE（約180GB圏内）に固まり、それ以降がFREEになったことを確認。
3. PVリサイズの試行（pvresize）
管理情報を 180GB に書き換えようと試みました。
- コマンド:
sudo pvresize --setphysicalvolumesize 180G /dev/vda2- 結果:
cannot resize to 46079 extents as later ones are allocatedにより失敗。 - 考察: LVMの内部メタデータや、目に見えない微細なフラグが末尾に残っていた可能性。
4. ホスト側での物理コピー（dd による強行突破）
「データは前に寄せた」という事実に基づき、ホスト側から物理的に180GB 分だけを切り出す作戦を敢行。
- 手順:
- ホスト側で新LV（180GB）を作成。
ddコマンドで旧LVから 180GB 分を抽出コピー。lvrenameを使い、VMが参照するターゲットを 180GB の新ディスクにすり替え。
5. 最終結果
- 起動: 成功。
- ログイン: 失敗。
- 状況:
virsh console等で応答なし。 - 結論: LVMおよびファイルシステムの整合性において、180GB という境界線で「管理情報の断裂」が発生。
教訓
- LVMの末尾は聖域:
pvmoveでデータを寄せても、LVM自身の管理領域（Metadata Area）の整合性を保ったまま物理サイズを削るのは、OS稼働中や単純なddでは極めて困難である。 - 切り詰めるなら「外から」より「中から」: 今回のように外部から
ddで削る手法は、パーティションテーブルとLVMヘッダの整合性が 1 バイトでも狂うとシステム停止に直結する。
やはり、この手のリサイズは「新たにサーバを作成し（リサイズした上で）データを流し込む」という地道な主だが一番です。
