注意事項

  • これは失敗した手順です。
  • なのでやってはいけないやつです。
  • あくまでも私の失敗したときの記録として残します。

何をやりたかったのか？

「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 分だけを切り出す作戦を敢行。

  • 手順:
  1. ホスト側で新LV（180GB）を作成。
  2. dd コマンドで旧LVから 180GB 分を抽出コピー。
  3. lvrename を使い、VMが参照するターゲットを 180GB の新ディスクにすり替え。

5. 最終結果

  • 起動: 成功。
  • ログイン: 失敗。
  • 状況: virsh console 等で応答なし。
  • 結論: LVMおよびファイルシステムの整合性において、180GB という境界線で「管理情報の断裂」が発生。

教訓

  • LVMの末尾は聖域: pvmove でデータを寄せても、LVM自身の管理領域（Metadata Area）の整合性を保ったまま物理サイズを削るのは、OS稼働中や単純な dd では極めて困難である。
  • 切り詰めるなら「外から」より「中から」: 今回のように外部から dd で削る手法は、パーティションテーブルとLVMヘッダの整合性が 1 バイトでも狂うとシステム停止に直結する。

やはり、この手のリサイズは「新たにサーバを作成し（リサイズした上で）データを流し込む」という地道な主だが一番です。