VMDK仮想ハードディスクをAmazon EC2のAMI形式に変換する方法【QEMUとAMIツール活用ガイド】

まずは、Amazon Elastic Compute Cloud(EC2)について簡単にご紹介しましょう。Amazon EC2は、世界中のユーザーに対して即座に拡張・縮小できるコンピューティング能力を提供するために設計されたWebサービスです。Amazonの大規模データセンター内に構築された巨大な仮想化グリッドであり、必要な人に必要な分だけCPUパワーとディスク容量をオンデマンドで提供します。ユーザーがやるべきことは支払いだけ。しかも、そのコストは決して高くありません。

Amazonは非常に手頃な価格でこのサービスを提供しており、自前でインフラを購入・維持するコストと比較しても十分に割に合います。一般のホームユーザーにとってはすぐに必要となるものではないかもしれませんが、柔軟な需要を持つ中小企業にとっては、ハードウェアに縛られない自由という魅力は間違いなく大きいでしょう。

このアイデアを気に入る人もいれば、嫌う人もいるでしょう。個人的には素晴らしいプロジェクトだと考えています。特に、AmazonクラウドがLinuxベースであり主にLinuxをサポートしている点は、Linux市場の成長に絶好の機会をもたらします。Mark Shuttleworth氏が、今後のUbuntuリリースにAmazon連携機能を組み込む意向について批判を受けたこともありましたが、これは賢明な一歩だと思います。デスクトップとWebのニーズが融合する今、クラウドでしか得られない「エーテルのような」柔軟性が求められているのです。

家庭での利用について

家庭環境では、従来型の仮想化で提供される範囲以上のものが必要になることはほとんどありません。しかし、「リビングに16GB RAM搭載のデータベースサーバーを置くコスト」を考え始めたら、Amazonの利用を検討するタイミングかもしれません。

もしそうなったら、Amazon EC2の使い方を知っておく必要があります。完全なチュートリアルは本記事の範囲を超えますので、詳細は公式ドキュメントをご参照ください。

ここでは、その全体像の中でも、おそらくホームユーザーが最も直面する重要な部分——Amazon仮想マシンイメージの作成——に絞って解説します。具体的には、VMware製品が使用する自作の仮想ハードディスクを、EC2で利用可能なAmazon互換イメージへ変換する方法をご紹介します。

最初からAmazonイメージを作成したり、既存のテンプレートを使えばいいのでは?

もっともな質問です!Amazonでは、ゼロからイメージを作成することも、SUSEやUbuntu、RedHatなどの既存テンプレートを出発点として利用することもできます。しかし、イメージの作成はやや複雑ですし、既存テンプレートが必ずしも望みどおりとは限りません。例えば、特別にカスタム設定したディストリビューションを実行したい場合や、自分以外の誰にも公開されていないプライベートなデジタル署名付きイメージを使用したい場合もあるでしょう。完全なコントロールを求めるなら、他人にイメージ作成を任せるわけにはいきません。

目標:自宅でイメージを作成し、Amazonへアップロードする

本チュートリアルでは、非常に具体的かつ重要なテーマに焦点を絞ります。独自の証明書を持つプライベートイメージを用意したい。自宅で、自分のペースと費用で、帯域幅や長時間の設定作業にお金を無駄にせずに作成したい。準備が整ったら、それを変換してAmazon Simple Storage Service(S3)と呼ばれるAmazonストレージへアップロードする——これがゴールです。

注意: 本チュートリアルの手順を実際に活用するには、有効なAmazon EC2アカウントが必要です。さらに、チュートリアルを完遂するにはLinux環境が必須です。ここで使用する一部のツールはLinux専用だからです。Amazon自体がLinux上で動いていることを考えれば、驚くことではありませんね。

最初の疑問:何から変換するのか?

これも良い質問です。デスクトップ向けの仮想化フォーマットは数多く存在しますが、自宅で仮想化を行っているなら、VMware製品のいずれかを使っている可能性が高いでしょう。VMwareは仮想ハードディスクに.vmdk形式を使用します。これがソース形式となり、Amazon Machine Image(AMI)へ変換したい対象です。

ただし、VMDK仮想ディスクをAMIへ直接変換することはできません。何をすべきかをお見せするために、このチュートリアルを執筆しました。それでは始めましょう。

ステップ1:必要なものをすべて揃える

作業を始める前に、あわてて変換作業に取り掛かる前に考慮すべき、非常に重要なポイントがいくつか(かなり多く)あります。

また、読み進める前に理解していただきたいのは、Amazon EC2プロジェクトはまだ発展途上であるという点です。そのため、ここで述べる推奨事項は、将来のセットアップには部分的にしか当てはまらないかもしれませんし、まったく当てはまらない可能性もあります。通常であれば自分の調査結果を控えめに述べることはありませんが、今回は繊細な変数があまりに多いため、成功を保証することはできません。とはいえ、この小さな告白に気落ちしないでください。さあ、ついてきてください。

Amazon側の一般的な要件(VMwareに関係なく)

Xen要件

変換してAmazon上で使用するためには、ディストリビューションを「Xen対応」にする必要があります。これはどういう意味でしょうか?Amazonの仮想インフラはXenと呼ばれるオープンソースのハイパーバイザーを基盤としています。XenはVMwareやKVMなどと同種の仮想化技術です。Amazonの仮想マシンがこのプラットフォーム上で動作するには、特定のカーネルとカーネルモジュールが必要となります。適切なXenカーネルをダウンロードし、展開し、Xenモジュールをインストールし、GRUBメニューを更新する必要があるのです。

より詳しく説明すると、お使いのディストリビューションの公式サイトやソフトウェアリポジトリにアクセスし、バージョンに合致するカーネルをダウンロードします。アーカイブを展開し、含まれるファイルを/bootと/libに配置します。次のステップは、関連するモジュールファイルの作成です:

depmod -F /boot/System.map-<kernel>-xenU -a <kernel>-xenU

ここで「kernel」は、お使いのバージョン(uname -rで確認できます)に一致させます。

完了したら、/lib/modules/<kernel>-xenUディレクトリ配下にモジュールが存在することを確認してください。最後に、GRUBのmenu.lst設定ファイルを更新し、Xenカーネルのエントリ(スタンザ)を追加します。このエントリがデフォルトで起動されるようにしてください。GRUBについて詳しくは、筆者の詳細なチュートリアルをご覧ください。

パーティショニング要件

これも厄介なポイントです。Amazonの仮想マシンには、非常に特定のパーティション構成が求められます。/etc/fstabは以下のようになっている必要があります:

/dev/sda1   /          ext3   defaults       1   1
none        /dev/pts   devpts gid=5,mode=620 0   0
none        /dev/shm   tmpfs  defaults       0   0
none        /proc      proc   defaults       0   0
none        /sys       sysfs  defaults       0   0

独自のswapや/mntマウントポイントを使用している場合は、/etc/fstabから削除してください。インスタンス実行時にはAmazon自身の設定が使用されます。

一般的に、仮想マシンがどのような構成であるべきかについての詳細は、公式の「Creating an AMI」ドキュメントを読むことをおすすめします。膨大な情報量に圧倒されないでください。ほとんどの項目は今回のテストケースには関係ありません。注目すべきは、カーネルモジュール、パーティション構成、ネットワーク設定の3点です。

デフォルトランレベルとサービス

さらに、Amazonマシンに実際に接続できるようにするには、ファイアウォールサービスを無効化するか、SSHの着信接続を許可するよう設定し、もちろんSSHサービスをデフォルトランレベルで有効にしておく必要があります。SSHはデフォルトでTCPポート22を使用します。

ランレベルについて言えば、Xenマシンは通常、未使用のランレベル4で起動します。そこで、/etc/inittabファイルを編集し、ランレベル4の行をコメント解除してデフォルトランレベルに設定する必要があります。次に、関連するサービスを有効化します。残念ながら、おすすめの「魔法のセット」はありません。

同様に、現時点ではAmazon上でX(GUI)を実行することはできないため、ランレベル5は論外です。異なるランレベルでサービスを設定する方法については、筆者のLinuxサービスチュートリアルを参考にしてください。

ネットワークインターフェース

ネットワークデバイスがDHCP経由でIPアドレスを取得するよう設定し、IPv6プロトコルを無効化する必要もあります。多くの場合、これらはデフォルト設定なので、苦労することはないでしょう。

追加の重要な注意点

VMware製品では、データの書き込みに応じて成長する「動的拡張イメージ」を作成できます。つまり、40GBの仮想ディスクでも、700MBのデータしか含んでいなければ実サイズは700MB程度です。逆に、サイズを事前割り当てすることも可能で、その場合はディスクがフルの40GBまで確保されます。ディスク容量を節約するため、多くのユーザーは前者の動的ディスクを選択するでしょう。

しかし、VMDKをRAWに変換する際、動的拡張によるメリットは失われます。ディスクイメージは実際のサイズまで膨らみます。仮想マシン作成時にはディスクサイズに注意を払ってください。

第二に、Amazonが現在サポートしているイメージサイズは最大10GBまでです。つまり、VMDKは10GBを超えてはなりません。超えるとAMIを作成できず、以下のエラーが表示されます:

ERROR: the specified image file <something>.raw is too large

第三に、LinuxマシンにJavaとRubyがインストールされている必要があります。そして、本チュートリアルのステップ3ではLinuxマシンが必須です。作業に取り掛かる前に、これらの要件をすべて満たしていることを確認してください。

ステップ2:VMDKをRAWに変換する

必要なものが揃ったところで、変換にはQEMUを使用します。QEMUはWindowsとLinuxの両方で利用可能な、非常に強力な万能エミュレータ/イメージユーティリティで、VMDKファイルをRAW形式へ変換できます。

筆者は以前、VMware Playerに関する記事で、QEMUを仮想ハードディスク作成のための優れたツールとして紹介しました。変換をはじめとする他のディスク関連タスクにも使用できます。

さて、VMwareディスクをRAW形式へ変換します。本質的には、これはディスクイメージからVMwareの高度なアルゴリズムを剥がし、セクター単位の素のディスクイメージへ展開することを意味します。

QEMUはこれを見事にこなします。実際、あらゆる種類の変換にQEMUを利用できますが、現時点で関心があるのはvmdk → rawです。変換するには、対象の.vmdkファイルを特定し、以下のqemu-imgコマンドを実行するだけです:

qemu-img convert -O raw source.vmdk target.raw

処理が完了するまで待ちましょう。マシンのスペックとイメージサイズによっては、かなり時間がかかることがあります。

ステップ3:AMIツールでイメージをバンドルする

AmazonはEC2サービス向けに2種類のツール群を提供しています。ひとつはAPIツールセットで、EC2サービスのクライアントインターフェースです。もうひとつはAMIツールセットで、AMIの作成・バンドル・Amazon S3へのアップロードに使用されるコマンドラインユーティリティのコレクションです。

必要なのはAMIツールの方です。ダウンロードして展開してください。できればホームディレクトリ内が良いでしょう。次に、以下のような長く退屈な変換コマンドを実行します:

./ec2-bundle-image -i <image> -r <arch> -c <cert> ->
-> -k <key> --user <user id>

各オプションを解説します:

• -i <image> — RAWファイルを指定します。
• -r <arch> — 仮想マシンのアーキテクチャ(i386、x86_64など)を指定します。
• -c <cert> — Amazonから受け取った証明書を指定します。ec2-bundle-imageコマンドは証明書へのパス末尾にスラッシュを許可しないため、ホームディレクトリまたはコマンド実行ディレクトリと同じ場所に置いておくべきです。理由は不明ですが、仕様なのです。スラッシュを付けると、次のようなエラーが出ます:

--prefix has invalid value 'cert.pem':'/' character not allowed.

• -k <key> — プライベートキーを指定します。証明書と同じルールが適用されます。
• --user <user id> — AmazonのユーザーIDを指定します。

前提条件

しかし、これだけでは不十分です。コマンドを一字一句正確に入力しても、ec2-bundle-imageは文句を言ってきます。例えばこんな具合に:

ec2-bundle-image: line 3: EC2_HOME: Neither of EC2_AMITOOL or EC2_HOME environment variables are set

これは、ユーティリティを使用する前にいくつかの環境変数をエクスポートする必要があることを意味します。

BASHの場合

Bashではexportコマンドを使用します:

export EC_HOME=<path>
export EC_AMITOOL_HOME=<path>

TCSHの場合

TCSHはexportをサポートしていません。代わりにsetenvを使用します:

setenv EC_HOME <path>
setenv EC_AMITOOL_HOME <path>

パスは以下に対応させてください:

• EC_HOME — ホームディレクトリ、あるいはその中のec2サブディレクトリが妥当です。/tmpファイルシステムは使用しないでください。安全でないワールド読み取り可能なディレクトリとして警告される可能性があります。
• EC_AMITOOL_HOME — AMIツールを展開したディレクトリ。

他の変数もexport/setenvしたくなるかもしれませんが、手入力は面倒です。効率化のため、すべての変数と値を記載したファイルを作成し、AMIツールを実行する際にsourceで読み込むのがおすすめです:

source file-containing-all-exports

さあ、準備完了です。長い変換コマンドでEnterキーを押して、待ちましょう。しばらくすると、プロセスは正常に完了するはずです。「はず」と強調したのは、動作させるためには一連の繊細な準備を完了させる必要があるからです。

VMDK → RAW → AMIの変換に成功していれば、ファイルをアップロードする準備が整っています。変換成功の目安は、/tmpディレクトリ内にファイル一覧とXMLマニフェストファイルが生成されることです。これがデフォルトの出力ディレクトリです。

これで実際の変換プロセスは完了です。次のステップはアップロードですが、これは本記事の範囲外です。また別の機会に取り上げましょう。Amazonは今後も定着していくでしょうから、Dedoimedoでもこのテーマに関する記事をさらに公開していく予定です。

まとめ

ご覧のとおり、この作業は決して簡単ではありませんが、十分に管理可能であり、時間・帯域幅・ひいてはお金を大幅に節約できます。イメージを変換できることで、Amazon EC2サービス固有のニーズを超えた自由が手に入ります。VMware Converterを活用する方法はすでに紹介しましたが、QEMUもまた、仮想化ニーズを強化できる強力なツールのひとつです。

ただし、満たすべきルールはかなり多くあります。特にAMIツール関連では、イメージサイズを大きくしすぎないこと、証明書とプライベートキーのパスに末尾スラッシュを使わないこと、環境変数をきちんとエクスポートすること、そしてAmazonツールを「安全でない」ディレクトリに置かないことが挙げられます。それでは、クラウドの上を楽しく歩きましょう。

続編の記事では、強力なSUSE Build Serviceの優れたコンポーネントであるKiwiについて取り上げ、カスタムディストリビューションや物理マシンのインストールからXenイメージ、さらにはAMIイメージを作成する方法を解説します。VMware Converterに匹敵し、それ以上の機能を提供するものです。そのために、Image CreatorとProduct Creatorを実際に触ってみます。さらに、SUSE Studioやその他のエキサイティングで革新的なコンセプト、アイデア、プロジェクトについても語っていく予定です。

Markus、AMIのチュートリアルについて尋ねていたよね?ほら、これだ。楽しんでくれ。

それでは、また。