OpenStack

2011年02月13日

このエントリーをはてなブックマークに追加

エラーメッセージ

▼検証環境

  • Ubuntu-10.04 Server
  • lp:nova Branched 515 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • novaが起動しているものとする

▼screen window 3番(compute)の出力より

libvir: Domain Config error : internal error no supported architecture for os type 'hvm'
ERROR:root:Uncaught exception
Traceback (most recent call last):
  File "/home/openstack/nova/nova/exception.py", line 83, in _wrap
    return f(*args, **kw)
  File "/home/openstack/nova/nova/virt/libvirt_conn.py", line 355, in spawn
    self._conn.createXML(xml, 0)
  File "/usr/lib/python2.6/dist-packages/libvirt.py", line 1289, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error no supported architecture for os type 'hvm'
ERROR:root:instance instance-1308883741: Failed to spawn
Traceback (most recent call last):
  File "/home/openstack/nova/nova/compute/manager.py", line 146, in run_instance
    self.driver.spawn(instance_ref)
  File "/home/openstack/nova/nova/exception.py", line 89, in _wrap
    raise Error(str(e))
Error: internal error no supported architecture for os type 'hvm'
libvir: QEMU error : Domain not found: no domain with matching name 'instance-1308883741'

エラーメッセージからは推測し辛い内容なので困った。

原因と対応方法

▼原因

  • 未対応ハイパーバイザを指定していた事
  • 具体的には、kvm未対応環境でkvmを指定していた

▼対応方法

  • nova起動時に、対応しているハイパーバイザを指定

あと書き

  • 対応しているハイパーバイザをしっかり確認しておく事
  • kvmの場合は、kvm-okコマンドで確認可能



編集
@hansode at 18:10|PermalinkComments(0)TrackBack(0)

2011年02月12日

このエントリーをはてなブックマークに追加

デフォルトのネットワークは「10.0.0.0/8」

前回のVLAN-ID重複だけでなく、 同一ネットワーク内でnova環境を複数構築した場合、ネットワークが重複していると不便。そんな状況に遭遇した。
今回は、任意のVLAN-IDを指定する方法を検証する。

▼検証環境

  • Ubuntu 10.04 LTS Server
  • lp:nova Branched 515 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • novaが起動してないものとする

▼要件定義

  • インスタンス用ネットワーク「10.1.1.0/24」でnovaを起動する

nova.shを修正

▼バックアップを作成した上で修正

$ cd /home/openstack
$ cp -pi nova/contrib/nova.sh nova/contrib/nova.sh.0
$ vi nova/contrib/nova.sh
$ diff nova/contrib/nova.sh.0 nova/contrib/nova.sh

▼nova.sh修正内容

148c148
<     $NOVA_DIR/bin/nova-manage network create 10.0.0.0/8 1 32
---
>     $NOVA_DIR/bin/nova-manage network create 10.1.1.0/24 1 32

nova起動時に生成するネットワークを変更するだけ。
後はnovaを起動し、インスタンスに割り当てられるIPアドレスを確認して、「10.1.1.3」などになっていれば良い。




編集
@hansode at 21:25|PermalinkComments(0)TrackBack(0)

2011年02月09日

このエントリーをはてなブックマークに追加

デフォルトのVLAN-IDは「100」

同一ネットワーク内でnova環境を複数構築した場合、VLAN-IDが重複していると不便。そんな状況に遭遇した。
今回は、任意のVLAN-IDを指定する方法を検証する。

▼検証環境

  • Ubuntu 10.04 LTS Server
  • lp:nova Branched 649 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • novaが起動してないものとする

▼要件定義

  • VLAN-ID「201」でnovaを起動する

『答えはソースにあり』

ドキュメントを読んでもVLAN-IDを指定する方法が見当たらない。
結局、ソースコードを読んで設定方法を知る事になる。

▼/home/openstack/nova/nova/network/manager.pyより

19  """
20  Network Hosts are responsible for allocating ips and setting up network.
21
22  There are multiple backend drivers that handle specific types of networking
23  topologies.  All of the network commands are issued to a subclass of
24  :class:`NetworkManager`.
25
26  **Related Flags**
27
28  :network_driver:  Driver to use for network creation
29  :flat_network_bridge:  Bridge device for simple network instances
30  :flat_interface:  FlatDhcp will bridge into this interface if set
31  :flat_network_dns:  Dns for simple network
32  :flat_network_dhcp_start:  Dhcp start for FlatDhcp
33  :vlan_start:  First VLAN for private networks
34  :vpn_ip:  Public IP for the cloudpipe VPN servers
35  :vpn_start:  First Vpn port for private networks
36  :cnt_vpn_clients:  Number of addresses reserved for vpn clients
37  :network_size:  Number of addresses in each private subnet
38  :floating_range:  Floating IP address block
39  :fixed_range:  Fixed IP address block
40  :date_dhcp_on_disassociate:  Whether to update dhcp when fixed_ip
41                               is disassociated
42  :fixed_ip_disassociate_timeout:  Seconds after which a deallocated ip
43                                   is disassociated
44
45  """

ネットワーク設定で指定可能オプションが何か分かる。
このうち、VLAN-IDに関する設定項目は「vlan_start」。

これらを指定する方法が、nova.shには存在しない。
そこで、nova.shで指定可能可能にする為の改良をする。

nova.shを修正

▼バックアップを作成した上で修正

$ cd /home/openstack
$ cp -pi nova/contrib/nova.sh nova/contrib/nova.sh.0
$ vi nova/contrib/nova.sh
$ diff nova/contrib/nova.sh.0 nova/contrib/nova.sh

▼nova.sh修正内容

29a30
> VLAN_ID=${VLAN_ID:-100}
118a120
> --vlan_start=${VLAN_ID}

実装内容は下記の通り。

  • nova.shのシェル変数として「VLAN_ID」を追加
  • nova.confに「--vlan_start=${VLAN_ID}」を追記指定

VLAN-IDを指定してnova起動

今回はVLAN-ID「201」でnovaを起動する。

▼novaを起動

$ cd /home/openstack
$ sudo LIBVIRT_TYPE=kvm VLAN_ID=201 ./nova/contrib/nova.sh run

▼インスタンスを起動

実際にインスタンスを起動してみないとブリッジとVLAN状況が分からない。

# euca-add-keypair mykey > mykey.pem
# euca-run-instances -t m1.tiny -k mykey ami-tty     

▼ブリッジ状況確認

# brctl show
bridge name     bridge id               STP enabled     interfaces
br201           8000.001d09649996       no              vlan201

ブリッジに仮想NICが追加されているのが分かる。
この時点では、ブリッジインターフェース名が「br201」と言うだけでVLAN状況が分からない。

▼VLAN状況確認

# cat /proc/net/vlan/vlan201
vlan201  VID: 201        REORDER_HDR: 1  dev->priv_flags: 1
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted            8
       total bytes transmitted          736
            total headroom inc            0
           total encap on xmit            0
Device: eth0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:

これで、VLAN-IDは「201」である事が分かった。
VLAN-ID指定に成功した。


あと書き

『ソースがドキュメント』




編集
@hansode at 22:35|PermalinkComments(0)TrackBack(0)

2011年01月21日

このエントリーをはてなブックマークに追加

novaのハイパーバイザはqemuだけじゃない

The nova.virt.libvirt_conn Moduleを参照すると分かる通り、
nova(libvirt)は複数のハイパーバイザ(KVM, QEMU, UML, and XEN)をサポートしている。

今回は、kvmを選択してnovaを起動してみる。
※novaのデフォルトハイパーバイザはqemu。

▼検証環境

  • Ubuntu 10.04 LTS Server
  • lp:nova Branched 515 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • novaが起動してないものとする

▼要件定義

  • ハイパーバイザとしてkvmを指定

事前確認

▼kvm-okコマンドで確認

$ kvm-ok
INFO: Your CPU supports KVM extensions
INFO: /dev/kvm exists
KVM acceleration can be used

KVMを利用可能である事が分かる。

作業内容

▼nova.shのシェル変数「LIBVIRT_TYPE」を設定

$ cd /home/openstack/
$ sudo LIBVIRT_TYPE=kvm ./nova/contrib/nova.sh run

実際にeuca-run-instanceコマンドを実行し、
インスタンスがkvmコマンドにより起動している事を確認出来れば良い。

例えばkvmを使うことが確実な場合、
nova.shの2行目にでも「LIBVIRT_TYPE=kvm」を追記しておけば良い。

あと書き

defaultのqemuではパフォーマンスが出なくて悩んでいる人には、
ハイパーバイザ切り替えによる対応がオススメ。


参考ページ




編集
@hansode at 19:35|PermalinkComments(0)TrackBack(0)

2011年01月17日

このエントリーをはてなブックマークに追加

UEC Ubuntu

novaインストール時に登録されるサンプルイメージは最小構成。
その為、作業環境用インスタンスとしては不十分だ。

今回はUbuntuがクラウド用に提供しているUEC Ubuntuイメージを登録する。
例えばclud-initが既に設定されているので、メタデータサーバからキーペアを取得し、登録まで行ってくれる環境が整っている。

▼検証環境

  • Ubuntu 10.04 LTS Server
  • lp:nova Branched 515 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • 「nova.sh install」実行後、「nova.sh run」によりnova起動中であるものとする
  • 「nova.sh run」により起動したscreen外の作業であるものとする
  • novaにユーザー登録済み
    • 登録ユーザー名「hansode」
    • 登録プロジェクト名「nagasode」
  • 登録済みnovaユーザー用novarcをsource済み
  • テストイメージ http://c2477062.cdn.cloudfiles.rackspacecloud.com/images.tgz登録済み
  • イメージ登録先バケット名は「mybucket」

▼要件定義

  • Ubuntu 10.04.1 LTSのマシンイメージを登録する

作業内容

事前確認

事前に状態を確認

▼tarballを取得

$ cd /tmp
$ wget http://uec-images.ubuntu.com/releases/10.04/release/ubuntu-10.04-server-uec-amd64.tar.gz

▼UCE用ツールでイメージを登録

$ uec-publish-tarball ubuntu-10.04-server-uec-amd64.tar.gz mybucket x86_64
Mon Jan 17 12:52:43 JST 2011: ====== extracting image ======
Warning: no ramdisk found, assuming '--ramdisk none'
kernel : lucid-server-uec-amd64-vmlinuz-virtual
ramdisk: none
image  : lucid-server-uec-amd64.img
Mon Jan 17 12:52:52 JST 2011: ====== bundle/upload kernel ======
Mon Jan 17 12:52:54 JST 2011: ====== bundle/upload image ======
Mon Jan 17 12:53:45 JST 2011: ====== done ======
emi="ami-pvrj77zy"; eri="none"; eki="ami-dol0muwk";

uec-publish-tarbllコマンドを実行するだけで一連の作業を行ってくれる。
実に簡単な作業。

▼登録したイメージを起動確認

$ euca-run-instances -t m1.tiny -k mykey ami-pvrj77zy
RESERVATION     r-kruw5cbd      nagasode
INSTANCE        i-3mqsjy        ami-pvrj77zy                    scheduling      mykey (nagasode, None)  0               m1.tiny 2011-01-17 03:59:14.274365

$ euca-describe-instances
RESERVATION     r-kruw5cbd      nagasode
INSTANCE        i-3mqsjy        ami-pvrj77zy    10.0.0.5        10.0.0.5        running mykey (nagasode, hatake)        0               m1.tiny 2011-01-17 03:59:14.274365

runningになるまで3分程待つ

▼SSH接続

$ ssh -i /tmp/mykey.pem ubuntu@10.0.0.5
$ exit

SSH公開鍵認証によるログインが出来れば良い。
もしも何か問題があるようであれば、instances/ディレクトリ配下のconsole.logファイルを確認。

▼インスタンスを停止

$ euca-terminate-instances i-3mqsjy

これ以降、UCE Ubuntuを種イメージとして環境構築して行けば良い。


参考ページ




編集
@hansode at 13:28|PermalinkComments(0)TrackBack(0)
このエントリーをはてなブックマークに追加

euca2oolsを使わずにイメージ操作

通常のイメージ登録手順ではなく、
euca-bundle-imageなど、euca2oolsを使わずにイメージ操作を行えればデバッグしやすい。
そんな気まぐれから作業着手。やってみると、実に簡単な事だった。

▼検証環境

  • Ubuntu 10.04 LTS Server
  • lp:nova Branched 515 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • 「nova.sh install」実行後、「nova.sh run」によりnova起動中であるものとする
  • 「nova.sh run」により起動したscreen外の作業であるものとする
  • novaにユーザー登録済み
    • 登録ユーザー名「hansode」
    • 登録プロジェクト名「nagasode」
  • 登録済みnovaユーザー用novarcをsource済み
  • テストイメージ http://c2477062.cdn.cloudfiles.rackspacecloud.com/images.tgz登録済み
  • イメージ登録先バケット名は「mybucket」

作業内容

事前確認

事前に状態を確認

▼euca2oolsによる確認

$ euca-describe-images
IMAGE   aki-lucid       nebula/lucid-kernel     admin   available       public          x86_64  kernel
IMAGE   ami-a2mf2p5k    mybucket/kernel.manifest.xml    nagasode        available       private         x86_64  kernel  true
IMAGE   ami-2tjg8b0b    mybucket/ramdisk.manifest.xml   nagasode        available       private         x86_64  ramdisk         true
IMAGE   ami-v9rkyd66    mybucket/machine.manifest.xml   nagasode        available       private         x86_64  machine ami-a2mf2p5k    ami-2tjg8b0b
IMAGE   ari-lucid       nebula/lucid-ramdisk    admin   available       public          x86_64  ramdisk
IMAGE   ami-tiny        nebula/tiny     vishvananda     available       public          x86_64  machine aki-lucid       ari-lucid

▼ファイルシステムを確認

$ cd /home/openstack/nova/images
$ ls -la
total 32
drwxr-xr-x 8    501 staff  4096 2011-01-14 13:06 .
drwxr-xr-x 5 ubuntu ubuntu 4096 2011-01-13 22:50 ..
drwxr-xr-x 2    501 staff  4096 2011-01-13 22:49 aki-lucid
drwxr-xr-x 2 root   root   4096 2011-01-14 13:02 ami-2tjg8b0b
drwxr-xr-x 2 root   root   4096 2011-01-14 13:02 ami-a2mf2p5k
drwxr-xr-x 2    501 staff  4096 2011-01-13 22:49 ami-tiny
drwxr-xr-x 2 root   root   4096 2011-01-14 13:06 ami-v9rkyd66
drwxr-xr-x 2    501 staff  4096 2010-09-15 07:30 ari-lucid
イメージディレクトリ操作

▼AMIをローカルコピー

$ cd /home/openstack/nova/images
$ sudo cp -pir ami-tiny ami-foo

$ euca-describe-images
IMAGE   aki-lucid       nebula/lucid-kernel     admin   available       public          x86_64  kernel
IMAGE   ami-a2mf2p5k    mybucket/kernel.manifest.xml    nagasode        available       private         x86_64  kernel  true
IMAGE   ami-2tjg8b0b    mybucket/ramdisk.manifest.xml   nagasode        available       private         x86_64  ramdisk         true
IMAGE   ami-v9rkyd66    mybucket/machine.manifest.xml   nagasode        available       private         x86_64  machine ami-a2mf2p5k    ami-2tjg8b0b
IMAGE   ari-lucid       nebula/lucid-ramdisk    admin   available       public          x86_64  ramdisk
IMAGE   ami-tiny        nebula/tiny     vishvananda     available       public          x86_64  machine aki-lucid       ari-lucid
IMAGE   ami-tiny        nebula/tiny     vishvananda     available       public          x86_64  machine aki-lucid       ari-lucid

ami-tinyが2つ出現した。
おや?イメージ管理用マスターデータは、DBではなく、ファイルシステム?

▼イメージのメタ情報を修正

$ sudo vi ami-foo/info.json
$ diff ami-tiny/info.json ami-foo/info.json
2c2
<     "imageId": "ami-tiny",
---
>     "imageId": "ami-foo",
5c5
<     "imageLocation": "nebula/tiny",
---
>     "imageLocation": "nebula/foo",

$ euca-describe-images
IMAGE   aki-lucid       nebula/lucid-kernel     admin   available       public          x86_64  kernel
IMAGE   ami-a2mf2p5k    mybucket/kernel.manifest.xml    nagasode        available       private         x86_64  kernel  true
IMAGE   ami-2tjg8b0b    mybucket/ramdisk.manifest.xml   nagasode        available       private         x86_64  ramdisk         true
IMAGE   ami-v9rkyd66    mybucket/machine.manifest.xml   nagasode        available       private         x86_64  machine ami-a2mf2p5k    ami-2tjg8b0b
IMAGE   ari-lucid       nebula/lucid-ramdisk    admin   available       public          x86_64  ramdisk
IMAGE   ami-tiny        nebula/tiny     vishvananda     available       public          x86_64  machine aki-lucid       ari-lucid
IMAGE   ami-foo nebula/foo      vishvananda     available       public          x86_64  machine aki-lucid       ari-lucid

IDとlocationが変化した。
どうやらイメージ管理は、DBにデータが格納されている訳ではない様だ。

▼インスタンスを起動停止確認

$ euca-run-instances -t m1.tiny -k mykey ami-foo
RESERVATION     r-8m017ai3      nagasode
INSTANCE        i-opzh6x        ami-foo                 scheduling      mykey (nagasode, None)  0               m1.tiny 2011-01-17 02:17:50.606933
$ euca-describe-instances
RESERVATION     r-8m017ai3      nagasode
INSTANCE        i-opzh6x        ami-foo 10.0.0.3        10.0.0.3        running mykey (nagasode, hatake)        0               m1.tiny 2011-01-17 02:17:50.606933

$ ssh -i mykey.pem root@10.0.0.3
# exit

$ euca-terminate-instances i-opzh6x

無事に起動・停止する事を確認出来た。


あと書き

イメージの内容に合わせて、imageとinfo.jsonを作成・修正すれば、
euca2oolsを使わずにイメージ操作可能と言う事が分かった。

euca2ools非依存によるメリットをまとめると、

  • bundle, upload, registerする手間を省ける。
  • bundleする必要がないので、直接「image」を修正可能。
  • publicイメージであれば、ユーザー用バケットは不要

良い子はeuca2oolsを使いましょう。




編集
@hansode at 12:10|PermalinkComments(0)TrackBack(0)

2011年01月14日

このエントリーをはてなブックマークに追加

独自VMイメージ登録後の状態確認

今回は、前回の作業で登録したバケットとイメージの場所を確認して行く。

▼検証環境

  • Ubuntu 10.04 LTS Server
  • lp:nova Branched 515 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • 「nova.sh install」実行後、「nova.sh run」によりnova起動中であるものとする
  • 「nova.sh run」により起動したscreen外の作業であるものとする
  • novaにユーザー登録済み
    • 登録ユーザー名「hansode」
    • 登録プロジェクト名「nagasode」
  • 登録済みnovaユーザー用novarcをsource済み
  • テストイメージ http://c2477062.cdn.cloudfiles.rackspacecloud.com/images.tgz登録済み
  • イメージ登録先バケット名は「mybucket」

作業内容

事前確認

OpenStackインストール先ディレクトリ配下を事前確認しておく。

▼/home/openstack/nova/配下を確認

$ ls -la /home/openstack/nova/
total 192
drwxr-xr-x 17 ubuntu ubuntu  4096 2011-01-14 15:44 .
drwxr-xr-x  5 ubuntu ubuntu  4096 2011-01-13 22:50 ..
-rw-r--r--  1 ubuntu ubuntu  1521 2011-01-13 22:44 Authors
drwxr-xr-x  2 ubuntu ubuntu  4096 2011-01-13 22:49 bin
drwxr-xr-x  3 root   root    4096 2011-01-14 12:59 buckets
-rwxr-xr-x  1 ubuntu ubuntu   787 2011-01-13 22:44 builddeb.sh
drwxr-xr-x  6 ubuntu ubuntu  4096 2011-01-13 22:44 .bzr
-rw-r--r--  1 ubuntu ubuntu   181 2011-01-13 22:44 .bzrignore
drwxr-xr-x  3 ubuntu ubuntu  4096 2011-01-13 22:44 bzrplugins
drwxr-xr-x  6 ubuntu ubuntu  4096 2011-01-13 22:51 CA
drwxr-xr-x  3 ubuntu ubuntu  4096 2011-01-13 22:44 contrib
drwxr-xr-x  5 ubuntu ubuntu  4096 2011-01-13 22:44 doc
drwxr-xr-x  2 ubuntu ubuntu  4096 2011-01-13 22:44 etc
-rw-r--r--  1 ubuntu ubuntu   125 2011-01-13 22:44 .gitignore
-rw-r--r--  1 ubuntu ubuntu  1345 2011-01-13 22:44 HACKING
lrwxrwxrwx  1 root   root      22 2011-01-13 22:50 images -> /home/openstack/images
drwxr-xr-x  3 root   root    4096 2011-01-14 13:12 instances
drwxr-xr-x  2 root   root    4096 2011-01-13 22:50 keys
-rw-r--r--  1 ubuntu ubuntu 10143 2011-01-13 22:44 LICENSE
-rw-r--r--  1 ubuntu ubuntu  1490 2011-01-13 22:44 .mailmap
-rw-r--r--  1 ubuntu ubuntu  1008 2011-01-13 22:44 MANIFEST.in
drwxr-xr-x  2 root   root    4096 2011-01-14 13:12 networks
drwxr-xr-x 14 ubuntu ubuntu  4096 2011-01-13 22:50 nova
-rw-r--r--  1 root   root     781 2011-01-13 22:50 novarc
-rw-r--r--  1 root   root   50176 2011-01-14 15:44 nova.sqlite
drwxr-xr-x  3 ubuntu ubuntu  4096 2011-01-13 22:44 plugins
-rw-r--r--  1 ubuntu ubuntu   829 2011-01-13 22:44 pylintrc
-rw-r--r--  1 ubuntu ubuntu   836 2011-01-13 22:44 README
-rw-r--r--  1 ubuntu ubuntu  2167 2011-01-13 22:44 run_tests.py
-rwxr-xr-x  1 ubuntu ubuntu  2178 2011-01-13 22:44 run_tests.sh
-rw-r--r--  1 ubuntu ubuntu   135 2011-01-13 22:44 setup.cfg
-rw-r--r--  1 ubuntu ubuntu  2714 2011-01-13 22:44 setup.py
drwxr-xr-x  2 ubuntu ubuntu  4096 2011-01-13 22:44 smoketests
drwxr-xr-x  2 ubuntu ubuntu  4096 2011-01-13 22:44 tools

これを元に調査を進める。

バケットの場所

/home/openstack/nova/配下に「buckets」と言うディレクトリを確認出来る。
これは、ディレクトリオーナーとタイムスタンプから判断する限り、uploadした時に作成されたと推測出来る。

▼/home/openstack/nova/buckets/を確認

$ ls -la /home/openstack/nova/buckets/
total 16
drwxr-xr-x  3 root   root   4096 2011-01-14 12:59 .
drwxr-xr-x 17 ubuntu ubuntu 4096 2011-01-14 15:49 ..
drwxr-xr-x  2 root   root   4096 2011-01-14 13:04 mybucket
-rw-r--r--  1 root   root     23 2011-01-14 12:59 mybucket.json

「mybucke」tディレクトリと、「mybucket.json」ファイルを確認。

▼/home/openstack/nova/buckets/mybucket.jsonを確認

$ file /home/openstack/nova/buckets/mybucket.json
/home/openstack/nova/buckets/mybucket.json: ASCII text, with no line terminators
$ cat /home/openstack/nova/buckets/mybucket.json
{"ownerId": "nagasode"}

「mybucket」のメタ情報を確認出来る。

▼/home/openstack/nova/buckets/mybucket/を確認

$ ls -la /home/openstack/nova/buckets/mybucket/
total 57236
drwxr-xr-x 2 root root     4096 2011-01-14 13:04 .
drwxr-xr-x 3 root root     4096 2011-01-14 12:59 ..
-rw-r--r-- 1 root root     2130 2011-01-14 12:59 kernel.manifest.xml
-rw-r--r-- 1 root root  4055072 2011-01-14 12:59 kernel.part.0
-rw-r--r-- 1 root root     2707 2011-01-14 13:06 machine.manifest.xml
-rw-r--r-- 1 root root 10485760 2011-01-14 13:06 machine.part.0
-rw-r--r-- 1 root root 10485760 2011-01-14 13:06 machine.part.1
-rw-r--r-- 1 root root 10485760 2011-01-14 13:06 machine.part.2
-rw-r--r-- 1 root root 10485760 2011-01-14 13:06 machine.part.3
-rw-r--r-- 1 root root  8711312 2011-01-14 13:06 machine.part.4
-rw-r--r-- 1 root root     2133 2011-01-14 13:02 ramdisk.manifest.xml
-rw-r--r-- 1 root root  3872704 2011-01-14 13:02 ramdisk.part.0

euca-upload-bundleでアップロードしたファイルを確認出来る。

登録イメージ保存先

/home/openstack/nova/配下に、「images」が存在している。
これは、images.tgz伸長時にも一度確認している。

▼/home/openstack/nova/images/を確認

$ ls -la /home/openstack/nova/images/
total 32
drwxr-xr-x 8    501 staff  4096 2011-01-14 13:06 .
drwxr-xr-x 5 ubuntu ubuntu 4096 2011-01-13 22:50 ..
drwxr-xr-x 2    501 staff  4096 2011-01-13 22:49 aki-lucid
drwxr-xr-x 2 root   root   4096 2011-01-14 13:02 ami-2tjg8b0b
drwxr-xr-x 2 root   root   4096 2011-01-14 13:02 ami-a2mf2p5k
drwxr-xr-x 2    501 staff  4096 2011-01-13 22:49 ami-tiny
drwxr-xr-x 2 root   root   4096 2011-01-14 13:06 ami-v9rkyd66
drwxr-xr-x 2    501 staff  4096 2010-09-15 07:30 ari-lucid

euca-registerにより登録したイメージIDのディレクトリが作成されている。

▼AMI用ディレクトリ/home/openstack/nova/images/ami-v9rkyd66/を確認

登録したAMIは「ami-v9rkyd66」だったので、ami-v9rkyd66を確認。

$ ls -la /home/openstack/nova/images/ami-v9rkyd66/
total 153612
drwxr-xr-x 2 root   root        4096 2011-01-14 13:06 .
drwxr-xr-x 8    501 staff       4096 2011-01-14 13:06 ..
-rw-r--r-- 1 ubuntu ubuntu 157286400 2010-09-15 07:35 image
-rw-r--r-- 1 root   root         258 2011-01-14 13:06 info.json

イメージ実態「image」と、イメージのメタ情報「info.json」を確認出来る。

▼メタ情報/home/openstack/nova/images/ami-v9rkyd66/info.jsonを確認

$ cat /home/openstack/nova/images/ami-v9rkyd66/info.json
{
 "imageOwnerId": "nagasode",
 "isPublic": false,
 "imageId": "ami-v9rkyd66",
 "imageState": "available",
 "architecture": "x86_64",
 "imageLocation": "mybucket/machine.manifest.xml",
 "kernelId": "ami-a2mf2p5k",
 "ramdiskId": "ami-2tjg8b0b",
 "imageType": "machine"
}

※実際は1行で見づらい為、ここでは見やすく整形。

インスタンスデータ

/home/openstack/nova/配下に、「instances」が存在している。
これは、bucketsと同様に、ディレクトリオーナーとタイムスタンプから判断する限り、インスタンスを初めて起動した時に作成されたと推測出来る。

▼/home/openstack/nova/instances/を確認

$ ls -la /home/openstack/nova/instances/
total 12
drwxr-xr-x  3 root   root   4096 2011-01-14 13:12 .
drwxr-xr-x 17 ubuntu ubuntu 4096 2011-01-14 16:03 ..
drwxrwxrwx  2 root   root   4096 2011-01-14 13:13 instance-1510165515

インスタンスIDと同じディレクトリを確認出来る。
停止しても、そのまま残っているようだ。

▼インスタンスID用/home/openstack/nova/instances/instance-1510165515/を確認

$ ls -la /home/openstack/nova/instances/instance-1510165515/
total 11300884
drwxrwxrwx 2 root root        4096 2011-01-14 13:13 .
drwxr-xr-x 3 root root        4096 2011-01-14 13:12 ..
-rw-r----- 1 root root       18171 2011-01-14 13:16 console.log
-rw-r--r-- 1 root root 32212286976 2011-01-14 13:20 disk
-rw-r--r-- 1 root root 10737418240 2011-01-14 13:13 disk-raw
-rw-r--r-- 1 root root     4093568 2011-01-14 13:12 kernel
-rw-r--r-- 1 root root        1413 2011-01-14 13:12 libvirt.xml
-rw-r--r-- 1 root root     3885852 2011-01-14 13:12 ramdisk

マシンイメージ用の各種ファイルを確認できる。

▼インスタンスID用/home/openstack/nova/instances/instance-1510165515/配下のファイル種類を確認


$ sudo file /home/openstack/nova/instances/instance-1510165515/*
/home/openstack/nova/instances/instance-1510165515/console.log: ASCII English text, with CRLF, CR line terminators
/home/openstack/nova/instances/instance-1510165515/disk:        x86 boot sector; partition 1: ID=0x83, starthead 1, startsector 63, 20971520 sectors; partition 2: ID=0x83, starthead 3, startsector 20971583, 41943040 sectors, code offset 0xb8
/home/openstack/nova/instances/instance-1510165515/disk-raw:    Linux rev 1.0 ext2 filesystem data, UUID=08a8ef16-2d4b-4b2a-85d5-ac1f3234a84c
/home/openstack/nova/instances/instance-1510165515/kernel:      Linux kernel x86 boot executable bzImage, version 2.6.32-22-server (buildd@yellow, RO-rootFS, root_dev 0x801, swap_dev 0x3, Normal VGA
/home/openstack/nova/instances/instance-1510165515/libvirt.xml: ASCII HTML document text
/home/openstack/nova/instances/instance-1510165515/ramdisk:     gzip compressed data, from Unix, last modified: Wed Jun 16 12:07:58 2010

ファイル名から推測可能でありつつも、それぞれの内容が明らかになった。

▼仮想マシンイメージの実態/home/openstack/nova/instances/instance-1510165515/diskのパーティションテーブルを確認

$ fdisk -l /home/openstack/nova/instances/instance-1510165515/disk
You must set cylinders.
You can do this from the extra functions menu.

Disk /home/openstack/nova/instances/instance-1510165515/disk: 0 MB, 0 bytes
4 heads, 32 sectors/track, 0 cylinders
Units = cylinders of 128 * 512 = 65536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d846a

                                                  Device Boot      Start         End      Blocks   Id  System
/home/openstack/nova/instances/instance-1510165515/disk1               1      163841    10485760   83  Linux
Partition 1 has different physical/logical endings:
     phys=(1023, 3, 32) logical=(163840, 1, 31)
/home/openstack/nova/instances/instance-1510165515/disk2          163841      491521    20971520   83  Linux
Partition 2 has different physical/logical beginnings (non-Linux?):
     phys=(1023, 3, 32) logical=(163840, 1, 32)
Partition 2 has different physical/logical endings:
     phys=(1023, 3, 32) logical=(491520, 1, 31)

なるほど。
マシンイメージ実態の調査は別エントリで行なう事にする。


まとめ

今回の調査で分かった保存先と内容は下記の通り。

▼バケット

  • /home/openstack/nova/buckets/
    • (バケット名).json ... バケットのメタ情報
    • (バケット名)/ ... バケット実態ディレクトリ
      • manifest.xmlファイル
      • イメージのパーツ群

▼イメージ

  • /home/openstack/nova/images/
    • (イメージID)/
      • image ... イメージ実態
      • info.json ... imageのメタ情報

▼インスタンス

  • /home/openstack/nova/instances/
      (インスタンスID)/
      • console.log ... 起動時のコンソールログ
      • disk ... マシンイメージディスク実態
      • disk-raw ... AMI(種マシンイメージ)
      • kernel ... AKI(カーネル)
      • libvirt.xml ... libvirt用設定ファイル
      • ramdisk ... ARI(ramdisk)



編集
@hansode at 16:50|PermalinkComments(0)TrackBack(0)
このエントリーをはてなブックマークに追加

独自VMイメージを登録

複数VMを起動可能状態にしなければ面白みが無い。
サンプルイメージを利用して独自VMイメージを登録してみる事にする。

▼検証環境

  • Ubuntu 10.04 LTS Server
  • lp:nova Branched 515 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • 「nova.sh install」実行後、「nova.sh run」によりnova起動中であるものとする
  • 「nova.sh run」により起動したscreen外の作業であるものとする
  • novaにユーザー登録済み
    • 登録ユーザー名「hansode」
    • 登録プロジェクト名「nagasode」
  • 登録済みnovaユーザー用novarcをsource済み

▼要件定義

作業内容

▼登録済みイメージを確認

$ euca-describe-images
IMAGE   aki-lucid       nebula/lucid-kernel     admin   available       public x86_64   kernel
IMAGE   ari-lucid       nebula/lucid-ramdisk    admin   available       public x86_64   ramdisk
IMAGE   ami-tiny        nebula/tiny     vishvananda     available       public x86_64   machine aki-lucid       ari-lucid

登録作業前の登録済みイメージ状況を確認。

▼テストイメージをダウンロード

$ cd /tmp
$ wget http://c2477062.cdn.cloudfiles.rackspacecloud.com/images.tgz

ここで/tmpへ移動しているのは、nova.sh install時にダウンロードされたimages.tgzを上書きしない為。

▼テストイメージを伸長

$ tar zxvf images.tgz
images/
images/aki-lucid/
images/ami-tiny/
images/ari-lucid/
images/ari-lucid/image
images/ari-lucid/info.json
images/ami-tiny/image
images/ami-tiny/info.json
images/aki-lucid/image
images/aki-lucid/info.json

▼kernelイメージをバンドル

$ euca-bundle-image -i images/aki-lucid/image -p kernel --kernel true
Checking image
Tarring image
Encrypting image
Splitting image...
Part: kernel.part.0
Generating manifest /tmp/kernel.manifest.xml

▼ramdiskイメージをバンドル

$ euca-bundle-image -i images/ari-lucid/image -p ramdisk --ramdisk true
Checking image
Tarring image
Encrypting image
Splitting image...
Part: ramdisk.part.0
Generating manifest /tmp/ramdisk.manifest.xml

▼bundle済みkernelイメージをアップロード

$ euca-upload-bundle -m /tmp/kernel.manifest.xml -b mybucket
Checking bucket: mybucket
Creating bucket: mybucket
Uploading manifest file
Uploading part: kernel.part.0
Uploaded image as mybucket/kernel.manifest.xml

バケット名「mybucket」を指定。

ここで、もしもバケットが存在しない場合は、バケットを作ってからアップロードされる。
バケット作成作業は自動的に行われるので事前に作成しておく必要はない。

▼bundle済みramdiskイメージをアップロード

$ euca-upload-bundle -m /tmp/ramdisk.manifest.xml -b mybucket
Checking bucket: mybucket
Uploading manifest file
Uploading part: ramdisk.part.0
Uploaded image as mybucket/ramdisk.manifest.xml

▼アップロード済みkernelを登録

$ out=$(euca-register mybucket/kernel.manifest.xml)
$ [ $? -eq 0 ] && kernel=$(echo $out | awk -- '{ print $2 }') || echo $out

失敗時はエラーメッセージが出力される。
成功時はシェル変数「$kernel」にAKIが設定される。

▼アップロード済みramdiskを登録

$ out=$(euca-register mybucket/ramdisk.manifest.xml)
$ [ $? -eq 0 ] && ramdisk=$(echo $out | awk -- '{ print $2 }') || echo $out

失敗時はエラーメッセージが出力される。
成功時はシェル変数「$ramdisk」にARIが設定される。

▼登録済kernelと登録済ramdiskを指定し、マシンイメージをバンドル

$ euca-bundle-image -i images/ami-tiny/image -p machine  --kernel $kernel --ramdisk $ramdisk
Checking image
Tarring image
Encrypting image
Splitting image...
Part: machine.part.0
Part: machine.part.1
Part: machine.part.2
Part: machine.part.3
Part: machine.part.4
Generating manifest /tmp/machine.manifest.xml

▼bundle済みマシンイメージをアップロード

$ euca-upload-bundle -m /tmp/machine.manifest.xml -b mybucket
Checking bucket: mybucket
Uploading manifest file
Uploading part: machine.part.0
Uploading part: machine.part.1
Uploading part: machine.part.2
Uploading part: machine.part.3
Uploading part: machine.part.4
Uploaded image as mybucket/machine.manifest.xml

▼アップロード済みマシンイメージを登録

$ out=$(euca-register mybucket/machine.manifest.xml)
$ [ $? -eq 0 ] && machine=$(echo $out | awk -- '{ print $2 }') || echo $out

失敗時はエラーメッセージが出力される。
成功時はシェル変数「$machine」にAMIが設定される。

▼登録されたイメージIDを確認

$ echo kernel: $kernel, ramdisk: $ramdisk, machine: $machine
kernel: ami-a2mf2p5k, ramdisk: ami-2tjg8b0b, machine: ami-v9rkyd66

▼APIに問い合せて、登録されたイメージIDを確認

$ euca-describe-images
IMAGE   aki-lucid       nebula/lucid-kernel     admin   available       public x86_64   kernel
IMAGE   ami-a2mf2p5k    mybucket/kernel.manifest.xml    nagasode        available       private         x86_64  kernel  true
IMAGE   ami-2tjg8b0b    mybucket/ramdisk.manifest.xml   nagasode        available       private         x86_64  ramdisk         true
IMAGE   ami-v9rkyd66    mybucket/machine.manifest.xml   nagasode        available       private         x86_64  machine ami-a2mf2p5k    ami-2tjg8b0b
IMAGE   ari-lucid       nebula/lucid-ramdisk    admin   available       public x86_64   ramdisk
IMAGE   ami-tiny        nebula/tiny     vishvananda     available       public x86_64   machine aki-lucid       ari-lucid

nagasodeプロジェクトのイメージを確認出来る。

▼キーペアを作成

$ euca-describe-keypairs

まだ何も無い事を確認。

$ euca-add-keypair mykey > mykey.pem
$ euca-describe-keypairs
KEYPAIR mykey   5d:3c:92:9d:d4:9e:45:6f:5d:25:ab:96:c7:93:b3:73

これでmykeyが登録された事を確認。

▼登録したAMI,AKI,ARIでインスタンスを起動

$ euca-run-instances $machine --kernel $kernel --ramdisk $ramdisk -k mykey
$ euca-describe-instances
RESERVATION     r-e2flz1xp      nagasode
INSTANCE        i-oz4363        ami-v9rkyd66    10.0.0.3        10.0.0.3       launching        mykey (nagasode, hatake)        0               m1.small       2011-01-14 04:12:33.739424

インスタンスIDが「i-oz4363」。
nagasodeプロジェクトのhansodeユーザーによるインスタンスを確認出来る。

▼ステータスが「running」になるまで待つ

裏の処理でイメージファイルのダウンロードと結合を行っているので、「runnning」になるまで3分ほど待たされる。
待ち時間はマシンスペックに依存。

$ euca-describe-instances
RESERVATION     r-e2flz1xp      nagasode
INSTANCE        i-oz4363        ami-v9rkyd66    10.0.0.3        10.0.0.3       running  mykey (nagasode, hatake)        0               m1.small        2011-01-14 04:12:33.739424

▼インスタンスにSSH接続

今回、対象インスタンスのIPアドレスは「10.0.0.3」。

$ chmod 600 mykey.pem
$ ssh -i ./mykey.pem root@10.0.0.3
--
-- This lightweight software stack was created with FastScale Stack Manager
-- For information on the FastScale Stack Manager product,
-- please visit www.fastscale.com
--
-bash-3.2# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:16:3E:3B:1D:CA
          inet addr:10.0.0.3  Bcast:10.0.0.31  Mask:255.255.255.224
          inet6 addr: fe80::16:3eff:fe3b:1dca/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:62 errors:0 dropped:0 overruns:0 frame:0
          TX packets:68 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9138 (8.9 KiB)  TX bytes:12248 (11.9 KiB)
          Interrupt:10 Base address:0x2000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.255.255.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

-bash-3.2# exit
logout
Connection to 10.0.0.3 closed.

▼インスタンスを停止

$ euca-terminate-instances i-oz4363
$ euca-describe-instances

停止命令後、インスタンスが無い事を確認。

これで独自VM生活を開始出来るようになった。


参考ページ




編集
@hansode at 13:30|PermalinkComments(0)TrackBack(0)

2011年01月13日

このエントリーをはてなブックマークに追加

動き出したnova環境を利用する

これまでの作業で確認用インスタンス起動までを確認出来ている。
いよいよnova環境をユーザーとして利用開始する為に、ユーザーを登録する。

▼検証環境

  • Ubuntu 10.04 LTS Server
  • lp:nova Branched 515 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • 「nova.sh install」実行後、「nova.sh run」によりnova起動中であるものとする
  • 「nova.sh run」により起動したscreen外の作業であるものとする

▼要件定義

  • 登録ユーザー名は「hansode」
  • 登録プロジェクト名は「nagasode」

作業内容

前提条件にあるように、「nova.sh run」により起動したscreen外で作業を行なう。

▼管理ユーザーを登録

ユーザー名は「hansode」とする

$ sudo /home/openstack/nova/bin/nova-manage user admin hansode
INFO:root:backend 
export EC2_ACCESS_KEY=65fff361-00e0-469f-a725-30b6969a2c0a
export EC2_SECRET_KEY=fb00a8d6-bfa9-4588-ada9-1334fac8711b

▼登録した管理ユーザー用のプロジェクトを登録

プロジェクト名は「nagasode」

$ sudo /home/openstack/nova/bin/nova-manage project create nagasode hansode
INFO:root:backend 

もしもエラーが出たら、引数の順番を逆にしている可能性を疑う。
引数の順番は「プロジェクト名」「ユーザー名」だ。

▼ユーザー/プロジェクト用クレデンシャルを取得

$ sudo /home/openstack/nova/bin/nova-manage project zipfile nagasode hansode
INFO:root:backend <module 'nova.db.sqlalchemy.api' from '/home/openstack/nova/nova/db/sqlalchemy/api.pyc'>
DEBUG:root:Running cmd (subprocess): openssl genrsa -out /tmp/tmpo6B_EO/temp.key 1024
DEBUG:root:Running cmd (subprocess): openssl req -new -key /tmp/tmpo6B_EO/temp.key -out /tmp/tmpo6B_EO/temp.csr -batch -subj /C=US/ST=California/L=MountainView/O=AnsoLabs/OU=NovaDev/CN=nagasode-hansode-2011-01-13T13:51:22Z
DEBUG:root:Flags path: /home/openstack/nova/nova/..//CA
DEBUG:root:Running cmd (subprocess): openssl ca -batch -out /tmp/tmp34Owek/outbound.csr -config ./openssl.cnf -infiles /tmp/tmp34Owek/inbound.csr
DEBUG:root:Running cmd (subprocess): openssl x509 -in /tmp/tmp34Owek/outbound.csr -serial -noout
WARNING:root:No vpn data for project nagasode

成功すると、カレントディレクトリに「nova.zip」が生成される。

$ ls -la nova.zip
-rw-r--r-- 1 root root 5667 2011-01-13 22:51 nova.zip

▼nova.zipを伸長

unzipコマンドがないので、unzipをインストール

$ sudo apt-get install -y unzip
$ unzip nova.zip
Archive:  nova.zip
 extracting: novarc
 extracting: pk.pem
 extracting: cert.pem
 extracting: cacert.pem

novarcと3つのpemが、カレントディレクトリに伸長される。

▼novarcの内容確認

$ cat ./novarc
NOVA_KEY_DIR=$(pushd $(dirname $BASH_SOURCE)>/dev/null; pwd; popd>/dev/null)
export EC2_ACCESS_KEY="65fff361-00e0-469f-a725-30b6969a2c0a:nagasode"
export EC2_SECRET_KEY="fb00a8d6-bfa9-4588-ada9-1334fac8711b"
export EC2_URL="http://192.0.2.30:8773/services/Cloud"
export S3_URL="http://192.0.2.30:3333"
export EC2_USER_ID=42 # nova does not use user id, but bundling requires it
export EC2_PRIVATE_KEY=${NOVA_KEY_DIR}/pk.pem
export EC2_CERT=${NOVA_KEY_DIR}/cert.pem
export NOVA_CERT=${NOVA_KEY_DIR}/cacert.pem
export EUCALYPTUS_CERT=${NOVA_CERT} # euca-bundle-image seems to require this set
alias ec2-bundle-image="ec2-bundle-image --cert ${EC2_CERT} --privatekey ${EC2_PRIVATE_KEY} --user 42 --ec2cert ${NOVA_CERT}"
alias ec2-upload-bundle="ec2-upload-bundle -a ${EC2_ACCESS_KEY} -s ${EC2_SECRET_KEY} --url ${S3_URL} --ec2cert ${NOVA_CERT}"

EC2_URLとS3_URLの値に注目する。

novaが起動しているサーバのIPアドレスであれば良い。上記例では「192.0.2.30」。
しかし、これが「10.0.0.1」の場合、novaが起動していない事になる。
その場合は、novaの起動を要確認の事。

▼rcファイルを読み込む

$ . ./noavrc

これにより、必要な環境変数がシェルに設定さる。
一時的な物であるため、必要であれば、.bash_profile等にnovarcをsourceする設定を書いておくと良い。

▼APIへの問い合せ確認

登録したユーザーでAPIへ問い合せしてみる。

$ euca-describe-images
IMAGE   aki-lucid       nebula/lucid-kernel     admin   available       public x86_64   kernel
IMAGE   ari-lucid       nebula/lucid-ramdisk    admin   available       public x86_64   ramdisk
IMAGE   ami-tiny        nebula/tiny     vishvananda     available       public x86_64   machine aki-lucid       ari-lucid

上記の様にeuca-describe-imagesコマンドでイメージ一覧取得に成功すれば、APIの認証に成功している事にもなる。

これでユーザー登録までが完了した。


参考ページ




編集
@hansode at 23:25|PermalinkComments(0)TrackBack(0)
このエントリーをはてなブックマークに追加

nova.sh install時にダウンロードされる「images.tgz」

自作マシンイメージを登録する前に、nova環境構築後の状況を確認しておく。

▼検証環境

  • Ubuntu 10.04 LTS Server
  • lp:nova Branched 515 revision(s)

▼前提条件

  • OpenStackインストール先は「/home/openstack」であるものとする
  • 「nova.sh install」実行後、「nova.sh run」によりnova起動中であるものとする

調査結果

▼images.tgzの中身を確認

# cd /home/openstack
# tar ztvpf images.tgz
drwxr-xr-x vishvananda/staff 0 2010-09-15 07:31 images/
drwxr-xr-x vishvananda/staff 0 2010-09-15 07:31 images/aki-lucid/
drwxr-xr-x vishvananda/staff 0 2010-09-15 07:38 images/ami-tiny/
drwxr-xr-x vishvananda/staff 0 2010-09-15 07:30 images/ari-lucid/
-rw-r--r-- vishvananda/staff 3885852 2010-09-15 07:30 images/ari-lucid/image
-rw-r--r-- vishvananda/staff     213 2010-09-15 07:30 images/ari-lucid/info.json
-rw-r--r-- vishvananda/staff 157286400 2010-09-15 07:35 images/ami-tiny/image
-rw-r--r-- vishvananda/staff       267 2010-09-15 07:31 images/ami-tiny/info.json
-rw-r--r-- vishvananda/staff   4093568 2010-09-15 07:31 images/aki-lucid/image
-rw-r--r-- vishvananda/staff       211 2010-09-15 07:31 images/aki-lucid/info.json

『(イメージ種類)-(image名)/{image,info.json}』となっているのが分かる。

▼イメージ登録先

/home/openstack/配下に伸長されているので、伸長先と中身を確認。

# cd /home/openstack
# ls -la images/*/*
-rw-r--r-- 1 501 staff   4093568 2010-09-15 07:31 images/aki-lucid/image
-rw-r--r-- 1 501 staff       211 2010-09-15 07:31 images/aki-lucid/info.json
-rw-r--r-- 1 501 staff 157286400 2010-09-15 07:35 images/ami-tiny/image
-rw-r--r-- 1 501 staff       267 2010-09-15 07:31 images/ami-tiny/info.json
-rw-r--r-- 1 501 staff   3885852 2010-09-15 07:30 images/ari-lucid/image
-rw-r--r-- 1 501 staff       213 2010-09-15 07:30 images/ari-lucid/info.json

images.tgzの中身と同じものである事を確認。

▼イメージ一覧表示

# euca-describe-images
IMAGE   aki-lucid       nebula/lucid-kernel     admin   available       public          x86_64  kernel
IMAGE   ari-lucid       nebula/lucid-ramdisk    admin   available       public          x86_64  ramdisk
IMAGE   ami-tiny        nebula/tiny     vishvananda     available       public          x86_64  machine aki-lucid       ari-lucid

nova.sh installにより、AKI, ARI, AMIが1つずつ登録されているのが分かる。

▼info.jsonの中身を確認

# for i in images/*/info.json; do echo ... $i; cat $i; done
... images/aki-lucid/info.json
{
    "imageId": "aki-lucid",
    "imageLocation": "nebula/lucid-kernel",
    "imageOwnerId": "admin",
    "imageState": "available",
    "type": "kernel",
    "isPublic": true,
    "architecture": "x86_64"
}

... images/ami-tiny/info.json
{
    "imageId": "ami-tiny",
    "kernelId": "aki-lucid",
    "ramdiskId": "ari-lucid",
    "imageLocation": "nebula/tiny",
    "imageOwnerId": "vishvananda",
    "imageState": "available",
    "type": "machine",
    "isPublic": true,
    "architecture": "x86_64"
}

... images/ari-lucid/info.json
{
    "imageId": "ari-lucid",
    "imageLocation": "nebula/lucid-ramdisk",
    "imageOwnerId": "admin",
    "imageState": "available",
    "type": "ramdisk",
    "isPublic": true,
    "architecture": "x86_64"
}

なるほど。

info.jsonの中身を見る限りでは、
imageファイルを別物で置き換えると、見た目のIDは同じでも、実態は別物として扱えそうだ。
しかし、それをやるメリットは何だろう。

▼imageのファイル種類を確認

# file images/*/image
images/aki-lucid/image: Linux kernel x86 boot executable bzImage, version 2.6.32-22-server (buildd@yellow, RO-rootFS, root_dev 0x801, swap_dev 0x3, Normal VGA
images/ami-tiny/image:  Linux rev 1.0 ext2 filesystem data, UUID=08a8ef16-2d4b-4b2a-85d5-ac1f3234a84c
images/ari-lucid/image: gzip compressed data, from Unix, last modified: Wed Jun 16 12:07:58 2010

ami-tiny/imageはext2だ。

▼マシンイメージの中身を確認

ループバックマウントして中身を覗いてみる。

# mount -o ro -o loop images/ami-tiny/image /mnt/
root@hatake:/home/openstack# ls -la /mnt/
total 32
drwxr-xr-x 17 root root  1024 2010-06-09 15:52 .
drwxr-xr-x 22 root root  4096 2011-01-13 15:25 ..
drwxr-xr-x  2 root root  1024 2010-09-14 10:30 bin
drwxr-xr-x  2 root root  1024 2010-06-09 06:39 boot
drwxr-xr-x  4 root root  1024 2010-06-09 07:25 dev
lrwxrwxrwx  1 root root    45 2010-06-09 15:52 drivers -> /lib/modules/2.6.31-17-server/kernel/drivers/
drwxr-xr-x 20 root root  1024 2010-06-09 15:53 etc
drwxr-xr-x  2 root root  1024 2010-06-09 06:39 home
drwxr-xr-x  2 root root  1024 2010-06-09 06:39 initrd
drwxr-xr-x  4 root root  2048 2010-06-09 06:39 lib
lrwxrwxrwx  1 root root    12 2010-06-09 06:39 linuxrc -> /bin/busybox
drwx------  2 root root 12288 2010-06-09 06:39 lost+found
drwxr-xr-x  2 root root  1024 2010-06-09 07:02 proc
drwxr-x---  3 root root  1024 2010-06-09 06:39 root
drwxr-xr-x  2 root root  1024 2010-06-09 06:39 sbin
drwxr-xr-x  2 root root  1024 2010-06-09 07:02 sys
drwxr-xr-t  2 root root  1024 2010-06-09 06:39 tmp
drwxr-xr-x  8 root root  1024 2010-06-09 06:39 usr
drwxr-xr-x 13 root root  1024 2010-06-09 06:39 var

# umount /mnt

なるほど。
ami-tiny/imageを種イメージとし、chrootを利用してパッケージ追加等可能である事が分かる。




編集
@hansode at 20:20|PermalinkComments(0)TrackBack(0)