VMWare4のせいか
vmshrinkでディスクファイル（VMDKファイル）がうまく圧縮できない。
この時点で使用容量は４．４Gバイト。なのにVMDKファイルは１２Gバイトもある。
仕方が無いので、X-Window上のVMWare-Toolboxを使うことにする。
しかし、X-Windowは入れてない・・・。
まずはX-Windowをインストから、
# yum -y groupinstall “X Window System”
# yum -y groupinstall “Desktop”
# yum -y groupinstall “General Purpose Desktop”
このまま startx するとマウスもキーボードも使えなかったので日本語化パッチも入れる。
# yum -y groupinstall “Japanese Support”
# startx
やっと動く。
本体のCPUがAMD E350で論理CPU１個、メモリ５１２MBしか割り当ててないのに、初期のVistaよりちゃんと動く、X-Windowって、とっても凄いと思う。
だがVMWareToolboxの動作が心配なので、一旦X-Windowを終わり、前にインストしたVMwareTools-8.8.1-528969.tar.gzをインストしなおす。
# ./vmware-install.pl
いっぱい応答入力が必要だが、全部[ENTER]で済ませる。
ここまでで使用容量は５．３Gバイトまで増量。環境整備で０．９Gバイトも増えた。
再起動した後に# startx。
メニュー⇒アプリケーション⇒システムツール⇒Terminalを起動。
中でVMツールをバックグラウンドで起動する。
# su –
# /usr/bin/vmware-toolbox & （必ずバックグラウンドで起動すること。）
で、やっとVMWare-Toolboxの画面が出たら、先のTerminalのウインドウを必ず閉じる。
※閉じないとサービス終了待ちのプログレスバーが何時までも終わらなくなる。shrinkタブを選択し、『 / 』を選択して下の【shrink】ボタンを押す。
確認メッセージで【Yes】を押す。
プログレスバーが長いので圧縮処理かと思ったら、ネットワークサービスを止めた後に、Nulデータを書き込んでいるらしい。
そのせいか、/rootディスクがいっぱいです、とかメッセージが出る時もあるが、当然【Ignore】だ。
先のプログレスバーが１００％（バーに隠れて見えないけど）になったら、shrinkしますか？で【Yes】を押してからが、本当のshrink処理が始まる。
そして長い長い処理が始まる。
終わったらちゃんとメッセージが出る。
でも、まだ９Gバイトまでしか圧縮できない。あと４Gバイトくらい圧縮できるハズなんだが・・・
すぐには思いつかなかったが、CentOS6は標準でディスクを２つのパーテーションに分ける。
１つ目は、ブートローダやカーネルが入っていて「/Boot」にマウントしているブート可能なパーテーション。
２つ目は、LinuxのLVMファイルで、
この中身は15Gバイトの「/」ファイルシステムと3.9Gバイトのスワップファイルだった。
# lvscan
ACTIVE ‘/dev/vg_******/lv_root’ [15.54 GiB] inherit
ACTIVE ‘/dev/vg_******/lv_swap’ [3.97 GiB] inherit
このスワップファイルは普通空のままだが、何かの原因でメモリ不足になると、とりあえず後回しにするデータが書き込まれる。実は、vmshrinkは「/」ファイルシステムの未使用部分にNulデータを書き込み、VMToolのディスク圧縮機能が働くようにしている様で、スワップパーテーションなんて眼中に無いようだ。
しかし、バックアップなどを簡単にするため、VLMにスワップファイルを入れることが多い、そうなると一度メモリ不足に陥ったサーバーでは、スワップファイルが最大まで実体化するので、このスワップデータ分がちゃんと圧縮できなくなるのだ。
ではどうすればよいのか？
一旦PowerOffし、VMWareでスワップ用のVMDKファイルを作り、2番目のディスクとして追加する。
起動後にスワップ用のVMDKファイルの中をスワップ形式でフォーマットし、再起動すればカーネルがSWAPパーテーションを勝手に認識するハズだったが、lvscanしてみると変化が無かったのでちゃんと開放した方がよさそうだ。
LVの情報を再確認。
# lvdisplay /dev/vg_******/lv_swap
— Logical volume —
LV Name /dev/vg_******/lv_swap
VG Name vg_******
LV UUID ******- ******- ******- ******- ******
LV Write Access read/write
LV Status available
# open 0
LV Size 3.97 GiB
Current LE 1016
Segments 1
Allocation inherit
Read ahead sectors auto
– currently set to 256
Block device 253:1
LVを削除。
# lvremove /dev/vg_******/lv_swap
Do you really want to remove active logical volume lv_swap? [y/n]: y
Logical volume “lv_swap” successfully removed
削除後の情報を確認。
# lvdisplay
— Logical volume —
LV Name /dev/vg_******/lv_root
VG Name vg_******
LV UUID ******- ******- ******- ******- ******
LV Write Access read/write
LV Status available
# open 1
LV Size 15.54 GiB
Current LE 3978
Segments 1
Allocation inherit
Read ahead sectors auto
– currently set to 256
Block device 253:0
再び、X-WindowのDiskUtilityで見ると消したパーテーションがチャント消えていた。
再起動した後、VMWare-Toolboxのshrinkを再び実行すると、VMDKファイルは５．３６Gバイトまで圧縮された。
本来は「/」を容量いっぱいに拡張した方がいいのだろうが管理用の領域が増えるだけなのでこのままにしておく。
VMDKファイルが半分未満になったせいか、ブログの動きも速くなったかな。
しかし、唐突に
No root device found.
Boot has failed.sleeping forever.
になる。
再起動すると１００％再現する。
色々やってみたら、
１．スワップ領域を減らした場合は
swapoff /dev/vg_******/lv_swap
lvreduce -L -128M /dev/vg_******/lv_swap
resize2fs /dev/vg_******/lv_swap
再起動しても問題ない。
２．スワップ領域を削除し、
swapoff /dev/vg_******/lv_swap
lvremove /dev/vg_******/lv_swap
再起動すると、
No root device found.
Boot has failed.sleeping forever.
になった。
/etc/fstabからスワップの設定を削除し再起動した後にスワップ領域を削除しても同じだった。
インスト時に作成されたスワップ領域を削除すると、起動時にroot deviceが見つからなくなるようだ。
これはカーネルがLVMをどう検索してるのか調べてみないと直らないなぁ。
あ、スワップ領域を消した跡を/ に割り当てるなら、
lvextend -l +100%FREE /dev/vg_******/lv_root
resize2fs /dev/vg_******/lv_root
でいいらしい。