イメージの要件

Linux

Linux イメージが OpenStack クラウドで全機能を利用する場合、いくつかの要件があります。これらのいくつかは cloud-init をインストールすることにより、要件を満たせます。イメージを作成する前に、使用する OpenStack の機能をイメージがきちんとサポートするために、このセクションを確認してください。

• 起動時のディスクパーティション設定およびルートパーティションのサイズ変更 (cloud-init)

• MAC アドレス情報の組み込みなし

• SSH サーバーの実行

• ファイアウォールの無効化

• SSH 公開鍵を使用したインスタンスへのアクセス (cloud-init)

• ユーザーデータと他のメタデータの処理 (cloud-init)

• Linux カーネルの準仮想化 Xen サポート (Linux カーネルバージョン < 3.0 の Xen ハイパーバイザーのみ)

起動時のディスクパーティション設定およびルートパーティションのサイズ変更 (cloud-init)

Linux イメージの作成時、ディスクをパーティション化する方法を決める必要があります。パーティション方法の選択により、以下のセクションに記載されているとおり、リサイズ機能に影響を与える可能性があります。

仮想マシンイメージのディスク容量は、イメージの初期作成時に決められます。しかしながら、OpenStack により、別のフレーバーを指定して、インスタンスを別の容量で起動できます。例えば、イメージが 5GB ディスクで作成し、インスタンスを m1.small のフレーバーで起動した場合、仮想マシンインスタンスはデフォルトで 20 GB の主ディスクを持ちます。インスタンスのディスクが容量拡張された場合、単に最後に 0 が書き込まれます。

イメージは、ユーザーにより要求された容量になるよう、起動時にパーティションをリサイズできる必要があります。そうでなければ、インスタンスのディスク容量がイメージ作成時のディスク容量を超えるフレーバーと関連づけられている場合、インスタンスの起動後、追加のストレージにアクセスできるよう、手動でリサイズする必要があります。

Xen: ext3/ext4 パーティション 1 つ (LVM なし)

OpenStack XenAPI ドライバーを使用する場合、Compute のサービスは、インスタンスの起動時にパーティションとファイルシステムを自動的に調整します。以下の条件がすべて満たされる場合、自動リサイズが実行されます。

• auto_disk_config=True が、イメージレジストリーにあるイメージのプロパティとして設定されている。

• イメージのディスクが 1 つのパーティションを持ちます。

• 1 つのパーティションのファイルシステムが ext3 または ext4 です。

そのため、Xen を使用する場合、イメージの作成時に、(LVM により管理されていない) ext3 / ext4 パーティションを作成することを推奨します。それ以外の場合、このまま読み進んでください。

cloud-init/cloud-tools ありの非 Xen : ext3/ext4 パーティション 1 つ (LVM なし)

イメージのこれらの項目を設定する必要があります。

• イメージのパーティションテーブルは、イメージの元々の容量を記載しています。

• イメージのファイルシステムは、イメージの元々の容量になっています。

そして、ブート中に以下を実行する必要があります。

• 追加領域を認識させるためにパーティションテーブルを変更します。

  • LVM を使用してない場合、既存のルートパーティションをこの追加領域を含むまで拡張するために、テーブルを変更する必要があります。

  • LVM を使用している場合、新規 LVM 項目をパーティションテーブルに追加し、新規 LVM 物理ボリュームを作成し、それをボリュームグループに追加し、ルートボリュームの論理パーティションを拡張できます。

• ルートボリュームのファイルシステムをリサイズします。

Depending on your distribution, the simplest way to support this is to install in your image:

• the cloud-init package,

• the cloud-utils package, which, on Ubuntu and Debian, also contains the growpart tool for extending partitions,

• Fedora、 CentOS 7、 RHEL 7 の場合、 cloud-utils-growpart パッケージ。このパッケージに含まれる growpart ツールでパーティションを拡張できます。

• Ubuntu、Debian の場合、 cloud-initramfs-growroot パッケージ。最初に起動するルートパーティションの容量を変更できます。

これらのパッケージをインストールすると、このイメージは、起動時にルートパーティションの容量変更を実行できるようになります。例えば、 /etc/rc.local にあります。

cloud-initramfs-tools をインストールできない場合、Robert Plestenjak 氏が linux-rootfs-resize という GitHub プロジェクトを行っています。これには、イメージを起動時にリサイズできるよう、 growpart を使用することにより、ラムディスクを更新するスクリプトが含まれます。

If you can install the cloud-init and cloud-utils packages, we recommend that when you create your images, you create a single ext3 or ext4 partition (not managed by LVM).

cloud-init/cloud-tools なしの非 Xen: LVM

ゲスト内に cloud-init と cloud-tools をインストールできず、リサイズをサポートしたい場合、パーティションテーブルを変更するために、イメージが起動時に実行するスクリプトを書く必要があります。この場合、パーティションを管理するために、LVM を使用することを推奨します。Linux カーネルの制限 (執筆時点) により、現在マウントされているローディスクのパーティションテーブルを変更できませんが、LVM の場合は実行できます。

スクリプトは以下のようなことを実行する必要があります。

1. ディスクの追加領域を利用可能かどうかを検知します。例えば、 parted /dev/sda --script "print free" の出力を解析します。

2. この追加領域を用いて新規 LVM パーティションを作成します。例えば、 parted /dev/sda --script "mkpart lvm ..." 。

3. 新規物理ボリュームを作成します。例えば、 pvcreate /dev/sda6 。

4. この物理パーティションを用いてボリュームグループを拡張します。例えば、 vgextend vg00 /dev/sda6 。

5. ルートパーティションを含む論理ボリュームを合計容量に拡張します。例えば、 lvextend /dev/mapper/node-root /dev/sda6 。

6. ルートファイルシステムをリサイズします。例えば、 resize2fs /dev/mapper/node-root 。

お使いのイメージが、 /boot が LVM により管理されていないという要件がある古い Linux ディストリビューションでなければ、 /boot パーティションは必要ありません。

MAC アドレス情報の組み込みなし

ネットワーク永続化ルールにより、インスタンスのネットワークインターフェースが eth0 以外のインターフェースとして起動するため、イメージでそのルールを削除する必要があります。これは、最初にインストールしたときに、ネットワークインターフェースカードの MAC が記録されるため、インスタンスの起動ごとに別の MAC アドレスになるためです。以下のファイルを変更します。

• /etc/udev/rules.d/70-persistent-net.rules を空のファイルに置き換えます。これは、MAC アドレスなどのネットワークの永続的ルールを含みます。

• /lib/udev/rules.d/75-persistent-net-generator.rules を空のファイルに置き換えます。これは上述のファイルを生成します。

• Fedora 系イメージにおいて /etc/sysconfig/network-scripts/ifcfg-eth0 から HWADDR 行を削除します。

注釈

ネットワーク永続化ルールのファイルを削除すると、起動時に udev カーネル の警告が出るかもしれません。そのため、これらを空ファイルで置き換えることを推奨します。

SSH サーバーの動作確認

イメージの中に SSH サーバーをインストールし、起動時に開始するよう設定する必要があります。そうでなければ、OpenStack 内に起動したインスタンスに SSH 接続できません。このパッケージは、一般的に openssh-server という名前です。

ファイアウォールの無効化

一般的に、イメージ内のファイアウォールを無効化し、インスタンスへのアクセスを制限するために OpenStack のセキュリティーグループを使用することを推奨します。その理由は、インスタンスにインストールされたファイアウォールは、インスタンスに接続できない場合に、ネットワークの問題のトラブルシューティングが難しくなるからです。

SSH 公開鍵を使用したインスタンスへのアクセス (cloud-init)

ユーザーが OpenStack で動作する仮想マシンにアクセスする一般的な方法は、公開鍵認証を使用した SSH です。このために、仮想マシンイメージは、OpenStack メタデータサービスやコンフィグドライブから SSH 公開鍵を起動時にダウンロードするよう設定する必要があります。

XenAPI エージェントと cloud-init が両方ともイメージに存在する場合、 cloud-init が SSH 鍵インジェクションを処理します。イメージが cloud_init_installed プロパティーを持つとき、システムは cloud-init が存在すると仮定します。

cloud-init を使用した公開鍵の取得

The cloud-init package automatically fetches the public key from the metadata server and places the key in an account. The account varies by distribution. On Ubuntu-based virtual machines, the account is called ubuntu, on Fedora-based virtual machines, the account is called fedora, and on CentOS-based virtual machines, the account is called centos.

You can change the name of the account used by cloud-init by editing the /etc/cloud/cloud.cfg file and adding a line with a different user. For example, to configure cloud-init to put the key in an account named admin, use the following syntax in the configuration file:

users:
  - name: admin
    (...)

公開鍵の取得のためのカスタムスクリプトの書き込み

ゲスト内に cloud-init をインストールできない場合、したくない場合は、公開鍵を取得し、ユーザーアカウントに追加するために、カスタムスクリプトを作成できます。

SSH 公開鍵を取得し、root アカウントに追加するために、 /etc/rc.local ファイルを編集し、 touch /var/lock/subsys/local 行の前に以下の行を追加します。このコードは rackerjoe oz-image-build CentOS 6 template から引用しました。

if [ ! -d /root/.ssh ]; then
  mkdir -p /root/.ssh
  chmod 700 /root/.ssh
fi

# Fetch public key using HTTP
ATTEMPTS=30
FAILED=0
while [ ! -f /root/.ssh/authorized_keys ]; do
  curl -f http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/metadata-key 2>/dev/null
  if [ $? -eq 0 ]; then
    cat /tmp/metadata-key >> /root/.ssh/authorized_keys
    chmod 0600 /root/.ssh/authorized_keys
    restorecon /root/.ssh/authorized_keys
    rm -f /tmp/metadata-key
    echo "Successfully retrieved public key from instance metadata"
    echo "*****************"
    echo "AUTHORIZED KEYS"
    echo "*****************"
    cat /root/.ssh/authorized_keys
    echo "*****************"
  else
    FAILED=`expr $FAILED + 1`
    if [ $FAILED -ge $ATTEMPTS ]; then
      echo "Failed to retrieve public key from instance metadata after $FAILED attempts, quitting"
      break
    fi
    echo "Could not retrieve public key from instance metadata (attempt #$FAILED/$ATTEMPTS), retrying in 5 seconds..."
    sleep 5
  fi
done

注釈

いくつかの VNC クライアントは、 : (コロン) を ; (セミコロン) に、 _ (アンダースコア) を - (ハイフン) に置き換えます。VNC セッション経由でファイルを編集する場合、http: が http; ではないこと、authorized_keys が authorized-keys ではないことを確認してください。

ユーザーデータと他のメタデータの処理 (cloud-init)

In addition to the ssh public key, an image might need additional information from OpenStack, such as to povide user data to instances, that the user submitted when requesting the image. For example, you might want to set the host name of the instance when it is booted. Or, you might wish to configure your image so that it executes user data content as a script on boot.

メタデータサービス、または、 コンフィグドライブへのメタデータの保存 により、この情報にアクセスできます。OpenStack メタデータサービスは、Amazon EC2 メタデータサービスの 2009-04-04 版と互換性があるので、ユーザーデータの取得に関する詳細は Using Instance Metadata にある Amazon EC2 ドキュメントを参照してください。

この類の機能をサポートする最も簡単な方法は、イメージ内に cloud-init パッケージをインストールすることです。これは、デフォルトでユーザーデータを実行可能スクリプトとして取り扱い、ホスト名を設定します。

イメージがブートログをコンソールに書き込むことの確認

You must configure the image so that the kernel writes the boot log to the ttyS0 device. In particular, the console=tty0 console=ttyS0,115200n8 arguments must be passed to the kernel on boot.

お使いのイメージがブートローダーとして grub2 を使用している場合、grub 設定ファイルに設定行があります。例えば、 /boot/grub/grub.cfg が以下のようになっているでしょう。

linux /boot/vmlinuz-3.2.0-49-virtual root=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro console=tty0 console=ttyS0,115200n8

If console=tty0 console=ttyS0,115200n8 does not appear, you must modify your grub configuration. In general, you should not update the grub.cfg directly, since it is automatically generated. Instead, you should edit the /etc/default/grub file and modify the value of the GRUB_CMDLINE_LINUX_DEFAULT variable:

GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"

次に grub 設定を更新します。Ubuntu などの Debian 系のオペレーティングシステムの場合、このコマンドを実行します。

# update-grub

RHEL、CentOS などの Fedora 系の場合、openSUSE の場合、このコマンドを実行します。

# grub2-mkconfig -o /boot/grub2/grub.cfg

カーネルの準仮想化 Xen サポート (Xen ハイパーバイザーのみ)

Linux カーネル 3.0 以前は、Linux カーネルのメインラインブランチが準仮想化 Xen 仮想マシンインスタンス (Xen は DomU ゲストと呼びます) をサポートしていません。Xen を準仮想化で実行している場合、Linux カーネル 3.0 以前の古い Linux ディストリビューションのイメージを作成したければ、そのイメージが Xen サポート付きでコンパイルされたカーネルを起動する必要があります。

イメージキャッシュの管理

nova.conf ファイルにあるオプションを使用して、未使用のイメージを /var/lib/nova/instances/_base/ に保存するかどうか、どの期間保存するかを制御します。インスタンスのライブマイグレーションを設定した場合、すべてのコンピュートノードは 1 つの /var/lib/nova/instances/ ディレクトリを共有します。

OpenStack における libvirt イメージの詳細は、 Pádraig Brady 氏の The life of an OpenStack libvirt image を参照してください。

イメージキャッシュ管理の設定オプション

設定オプション=規定値	(型) 説明
preallocate_images=none	(文字列型) 仮想マシンイメージの事前割り当てのモード: なし ストレージの事前プロビジョニングがありません。 space ストレージはインスタンスの起動時に完全に割り当てられます。 $instance_dir/ のイメージが fallocated され、十分な空き領域が利用できるかをすぐに判断します。また、動作中の割り当てを避け、ブロック割り当てのより良い局所性により、仮想マシン I/O パフォーマンスを改善するでしょう。
remove_unused_base_images=True	(論理型) 未使用のイメージが削除されるかどうかです。True (真) に設定した場合、ベースイメージが削除される間隔は、以下の 2 つの設定で設定されます。False (偽) に設定した場合、ベースイメージは Compute により削除されません。
remove_unused_original_minimum_age_seconds=86400	(整数型) この時間内は、未使用かつ容量変更のないベースイメージが削除されません。デフォルトは 86400 秒 (24 時間) です。
remove_unused_resized_minimum_age_seconds=3600	(整数型) この時間内は、未使用かつ容量変更のあるベースイメージが削除されません。デフォルトは 3600 秒 (1 時間) です。

この設定が、稼働中のインスタンスの削除にどのような影響を与えるかを確認する場合、イメージが保存されているディレクトリを確認してください。

# ls -lash /var/lib/nova/instances/_base/

/var/log/compute/compute.log ファイルで識別子を検索します。

2012-02-18 04:24:17 41389 WARNING nova.virt.libvirt.imagecache [-] Unknown base file: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3_20
2012-02-18 04:24:17 41389 INFO nova.virt.libvirt.imagecache [-] Removable base files: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3 /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3_20
2012-02-18 04:24:17 41389 INFO nova.virt.libvirt.imagecache [-] Removing base file: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3

remove_unused_original_minimum_age_seconds のデフォルト時間は 86400 秒 (24 時間) なので、ベースイメージが削除されたことを確認するために、その時間待つことができます。または、 nova.conf ファイルにより短い時間を設定します。 nova.conf ファイルの設定を変更した後、すべての nova サービスを再起動してください。