VirtualBoxで仮想ディスクのサイズを減らしてみた(4)

(1)、(2)、(3)と続いたエントリも今回で最後です。

仮想ディスクの掃除が完了しましたので、ホストOSのコマンドラインからVirtualBox付属のVBoxManageコマンドを使って、仮想ディスクのファイルサイズを縮小します。

仮想ディスクはスナップショット毎に、.vdi形式の差分ファイルが生成されます。VBoxManageコマンドは差分ファイル単体を個別に指定してサイズを縮小できますが、指定できるのは常に単一ファイルです。したがって、仮想ディスクに関係するファイルを一括で指定して、まとめてサイズを縮小するようなことはできません。対象ファイルのファイル名は、仮想メディアマネージャを使って一つ一つ調べることになります。これが本来のやり方です。

しかし、Mac OS X版のVirtualBoxの仮想メディアマネージャは、複数の仮想マシンそれぞれにスナップショットがある場合に、仮想ディスクを正しくツリー表示できないようです。信頼できない情報を元に作業を続けたくはありません。

そこで今回は、コマンドラインからVBoxManageコマンドで仮想ディスクの全ファイルのリストを出力し、仮想マシン名とスナップショット名を元に対象ファイルを探す方法を紹介します。

VirtualBoxのスナップショット名は、複数の対象に同じ名前をつけられますので、今回は念のため、一意のIDであるUUIDを極力使うようにします。

なお、仮想マシンのある時点の状態を保存するスナップショットのUUIDと、そのスナップショットの時点での仮想ディスクの状態を表すUUIDは別物ですので注意してください。仮想マシンには仮想ディスクが複数接続されている事もありますので、スナップショットと同じUUIDはつけられません。

実際の手順はイカの通りです。

作業に慣れてくれば、直接Snapshotフォルダに移動して、ファイルの日付とサイズから対象ファイルを推測するような手抜きもできるのですが、読者の方々にとっては今回が初めての作業のはずですし、失敗した場合の被害も大きいので、多少面倒でも確実な方法を紹介します。

VirtualBoxで仮想ディスクのサイズを減らしてみた(3)

前回と前々回からの続きですので、先にそちらをご覧ください。

・空き領域をゼロクリアする。

swap領域のゼロクリアが完了しましたので、次は既にインストール済みのzerofreeコマンドを使ってディスクの空き領域をゼロクリアします。

zerofreeはext2/ext3ファイルシステムに対応したツールと紹介される事が多いので、ext4ファイルシステムには未対応という誤解もあるようですが、実際には作者であるR M Yorston氏のページにも記載があるように、ext4にも対応しています。

ただし、ext4への対応は、zerofreeが依存しているe2fslibsパッケージがext4にも対応していることが前提になります。今回はUbuntu 10.10のzerofreeパッケージを使用していますので、その点については問題はありません。

次に、zerofreeの実行対象となるパーティションは、マウントが解除されているか、読み込み専用でマウントされている必要があります。逆に言えば、元々マウントされていなかったパーティションをzerofreeを実行するためにわざわざ読み込み専用でマウントする必要はありません。

読み込み専用で再マウントが必要なのは、コマンドの実行のためにマウントを解除できないパーティションに対してzerofreeを実行したい場合です。この場合、事前にいくつかのサービスを停止しておかないと再マウントが失敗することがあります。

実際の作業はイカの通りです。

VirtualBoxで仮想ディスクのサイズを減らしてみた(2)

前回からの続きです。

・swap領域をゼロクリアする

不要なファイルの削除が終わったので、ここからはシングルユーザーモードに移行して作業を続けます。次に実行するのはswap領域のゼロクリアです。

仮想マシンのメモリに余裕があってswap領域をほとんど使っていないような場合でも、ゲストOSでシステムのハイバネートを実行していれば、メモリイメージがswap領域に書き込まれます。

一度swap領域に書き込まれた内容は、明示的に消去しない限りそのまま残っていますので、それをゼロクリアすることで仮想ディスクのサイズを減らすことが可能です。

ただし、正確に言えばここでゼロクリアするのはswap領域ではなく、swapパーティション（またはswapファイル）全体です。

swapパーティション全体をゼロクリアすれば、スーパーブロックやswapヘッダもその対象になりますが、そこにはパーティションのUUIDやラベルが記録されています。

最近のLinuxは使用するswap領域をUUIDやラベルで判断するようになっていますので、ゼロクリアした後に元のUUIDやラベルを付け直しておかないと、swap領域として使用されなくなる場合があります。

それを避けるため、手順としては、wipefsコマンドで調べたUUIDとラベルをあらかじめメモしておいて、パーティション/ファイル全体をddコマンドを使ってゼロクリアした後にmkswapコマンドでUUIDやラベルを含めてswap領域として初期化することになります。

swapヘッダには他にもページサイズやswapバージョン等が記録されていますが、ページサイズはカーネル次第ですし、最近のカーネルはバージョン1のswap領域しか利用できなくなったので、メモする必要はありません。

なお、複数のOSでswapパーティションを共有している場合や、パーティションのサイズだけを後から変更してパーティションテーブルに誤った情報が記録されているような場合、swapパーティション全体をゼロクリアすることで問題が発生することがあります。

VirtualBoxの仮想ディスクでそのような運用をしていることはあまり無いだろうとは思いますが、心当たりがある方は一応ご注意ください。

VirtualBoxで仮想ディスクのサイズを減らしてみた(1)

VirtualBoxの仮想ディスクは、容量を減らすために「可変サイズのストレージ」を選択していても、そのファイルサイズがゲストOSが実際に使用している容量以上のサイズになることがあります。

これは、ゲストOS上で仮想ディスクに一度作成したファイルを削除した場合、ゲストOSはファイルを削除したことで空き容量が増えたと報告しますが、仮想ディスクにはそのファイルのデータが残ったままになっているからです。

結果として、ゲストOS上でファイルの作成と削除を繰り返すと、ゲストOSが実際に使用している容量とは無関係に、仮想ディスクが最大サイズまで消費され続けるようなことになりかねません。

この問題を解決するために、仮想ディスクに記録されている削除されたファイルのデータ部分をゼロクリアで初期化してから、VirtualBoxのVBoxManageツールを使って仮想ディスクのファイルサイズを減らす方法がTipsとして知られています。

上記の話はVirtualBoxのマニュアルにも記載されているので、作業の手順自体は以前から知っていたのですが、実行する必要には迫られなかったので実際に試してみたことはありませんでした。

しかし最近になって、どこぞのVPSのバックアップの際にバックアップファイルのサイズを減らす必要が発生するんじゃないかなーという予感が何となくしてきた（予感なので根拠は特にありません）ので、その練習代わりにこの作業を試してみることにしました。

尚、今回作業を実行した環境は、

• ホストOS：Mac OS X 10.6.5
• ゲストOS：Ubuntu 10.10 Desktkop Edition
• 仮想化ソフトウェア：Oracle VM VirtualBox for Mac OS X Ver.3.2.12 r68302

という構成です。

ホストOSはWindowsであっても、作業手順はあまり変わらないと思いますが、ゲストOSはUbuntuのバージョンが変わっただけでも手順が変わってくることがありますので、実際に試してみようと考えていらっしゃる方はご注意ください。

仮想化ソフトウェアであるVirtualBoxの方は、バージョンが多少違っていても問題ありません……と言いたいところなのですが、VBoxManageツールのコマンドは結構コロコロ変わりますので、バージョンが異なる場合はマニュアルで確認しておくことをオススメします。

実際の作業はイカの通りです。

さくらのVPSでカスタムOSインストールを試してみた(2)

昨日のエントリで書いた、さくらのVPSのVNCコンソールがMac OS XではGoogle Chromeでだけ起動しなかった件が気になったので、OSをBoot CampのWindows XP SP3に変えて確認してみたところ、

• Google Chrome 6.0.472.63 …… VNCコンソールが起動
• Internet Explorer 8.0.6001.18702 …… VNCコンソールが起動
• Firefox 3.6.10 …… VNCコンソールが起動
• Safari 5.0.2 (7533.1.8.5) …… VNCコンソールが起動

という結果になり、4種類のWebブラウザ全てでVNCコンソールが起動しました。
Mac OS X版のGoogle ChromeでJava絡みの設定をいじった記憶は特にないのですが、もしかすると我が家のiMacだけの現象なのかもしれません。

今日のエントリも昨日のエントリの続きで、さくらのVPSのカスタムOSインストールで気がついた事のメモです。
使えるようになったばかりの機能なので混み合ってるかとも思ったのですが、VNCコンソールの動作は予想していたよりも安定しているようです。

おかげで、何か問題が無いか探そうとすると重箱の隅をつつかざるを得ませんでした。
以前の「VirtualBoxでさくらのVPSのテスト環境を作ってみたシリーズ」よりもかなりショボいエントリになっていますが、どうかご了承ください。m(__)m