CloudStack⑭テンプレートの取得
昨日SSVMがインターネットと通信できるようになりました。
その後ＳＳＶＭを再起動したり、テンプレートをダウンロードしなおしたりしたのですが、取得ならず・・・
というわけで今日はテンプレートの取得をして、インスタンスを作成していきます。
まずは、ダウンロード後になにが起きたがために失敗しているのかログを見てみます。
ここでテンプレがダウンロードし始めていることがわかり、失敗した原因が次の行に書いてありました。
2014-05-27 11:26:31,995 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) ===START=== ＿＿＿＿ -- GET command=registerTemplate&name=CenrOS6.4(64bit)&displayText=CenrOS6.4(64bit)&url=http%3A%2F%2F202.228.225.58%2Fuserdata%2F4cc60439-0efb-443b-b57b-0b0a9e334cf8.qcow2&zoneid=35641eee-48e4-4328-bc2f-f21d2b86f72d&format=QCOW2&isextractable=true&passwordEnabled=true&osTypeId=44caf8f8-be0f-4481-8529-60e025ca9506&hypervisor=KVM&ispublic=true&isfeatured=true&response=json&sessionkey=Vv%2BxAMZERjak8BGqe2AU%2Fl2%2BjtI%3D&_=1401157591014
2014-05-27 11:26:32,041 WARN [storage.download.DownloadMonitorImpl] (catalina-exec-5:null) There is no secondary storage VM for secondary storage host nfs://＿＿＿＿/export/secondary
管理サーバーに行けないことが原因だそう。
ここでセカンダリストレージを外部と内部２つのアドレスで作っていたので、内部ＮＷ用のアドレスのものを消しました。
それからテンプレートを確認すると、ゾーン４のシステムテンプレとデフォルトテンプレートがなくなっていました。つまり内部アドレスが付与されているネットワークを使ってSSVMはnfsサーバーに行こうとしていたわけです。ファイアウォールによってはじかれてしまっていたので、今まで通信ができていなかったのですね・・・
上から通してあげることもできるのですが、下からの方が設定の箇所が少ないので内部ＮＷのルートをきちんと通してあげることにします。
ホストサーバーのトラフィックを設定しなおします。cloudbr0（上の×印のルート）からcloudbr1（下のルート）へ変更。
管理サーバーへのルート、ストレージへのルートの２つです。
これで解決なはずだったのですが、テンプレはどちらもダウンロード出来ずじまいでした。
とりあえず以前ブリッジの設定をし直したものを見たりしてみます。
そしてこのような設定も教わりました。root diskというのが何なのだかわからない。まあこちらも引き続き・・・
メモ
・ ERROR [cloud.cluster.ClusterManagerImpl] (main:null) Unable to ping management server at 125.6.174.38:9090 due to ConnectException
java.net.ConnectException: Connection refused
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:534)
・ 時間が経ったログはzipされていること、再現できるバグは良いバグ（原因が容易に特定可能だから）であることを初めてしりました。ログを見てもよく分からないことがあるのは、ログ自体をよく分かっていないことも原因なのだなと思いました。
CloudStack⑬NATの設定（2日目）
月曜日になりました。
今日こそＮＡＴを設定してテンプレを取得したいところです。
#iptables -t nat -A POSTROUTING -s ＳＳＶＭのリンクローカルアドレス（以後ＳＳＶＭ）-j SNAT --to 新しく作ったインターフェスのＩＰ（以後eth0:1）
# iptables -t nat -A POSTROUTING -s eth0:1 -j SNAT --to ＧＷ
#iptables -L -t nat
Chain PREROUTING (policy ACCEPT)target prot opt source destinatination
DNAT all -- anywhere ＳＳＶＭ to:eth0:1
DNAT all -- anywhere eth0:1 to:GW
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- SSVM anywhere to:eth0:1
SNAT all -- eth0:1 anywhere to:GW
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
マスカレードの設定
#iptables -t nat -A POSTROUTING -s eth0:1/24 -j MASQUERADE
今出来ているNATの設定
#iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT all -- anywhere SSVM to:eth0:1
DNAT all -- anywhere eth0:1 to:GW
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- SSVM anywhere to:eth0:1
SNAT all -- eth0:1 anywhere to:GW
MASQUERADE all -- 192.168.2.0/24 anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
こんなイメージ
ここでpingを飛ばして接続状況の確認をしてみた
05から eth0:1 GW ● ＳＳＶＭ ×
SSVMまでとどいていない・・・・つまりSSVMからはどこにもとどいていないことになる
せめてリンクローカルでつながっているはずのCPVMにはとどくだろうとおもっていたが、そちらにもとどかない
うーんもしかして別の間違いなのか、またはリンクローカルネットワークを機能させるには何かが必要でそれがないだけなのか、ただ単にＮＡＴの設定が不十分であることが原因なのか。３つ考えられるのだけれどな、どうしましょう。
#iptables -t nat -A POSTROUTING -s eth0:1/255.255.255.0 -j MASQUERADE
pingはとびません。
うん、困ったな。
どうしてなのか絵をかいて整理してみよう。
ここでクラウドブリッジに問題があることがわかる。
グローバルアドレスを付与されている方のクラウドブリッジを使って、新しくＩＰを取る。
#vi ifcfg-cloud0\:1
DEVICE="cloudbr0:1"
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
NM_CONTROLLED="yes"
ONBOOT=yes
TYPE="Ethernet"
IPADDR=＿＿＿＿
NETMASK=255.255.255.0
#service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
調べたときに使ったコマンド
tcpdump -i cloudbr1 -nn icmp
tcpdump -i cloudbr10 -nn icmp
tcpdump -i cloudbr0 -nn icmp
ifconfig -a |more
tcpdump -i eth0 arp
brctl show
tcpdump -i cloudbr0 -nn icmp
tcpdump -i cloudbr0 -nn arp
ls
ifconfig -a
ifdown eth0;1
CloudStack⑫NATの設定
システムVM起動まではできましたが、テンプレートの取得がうまくいっていません。
ＳＳＶＭはストレージに関する処理を行ってくれるところです。ISOやテンプレートのイメージをwebからダウンロードしたり、テンプレのコピー、スナップショットのバックアップをします。ですので、インターネットに接続できなければならないわけです。
ところが、私の行った設定ではSSVMにはローカルIPしか割り当てられておらず、お外へ出られなくなっています。というわけでこれからＮＡＴを設定して、テンプレをダウンロードできるように設定していきます。
行う設定のイメージは以下の図の通りです。
①NATの設定をするために、インターフェイスを新しく作成
②NATの設定を行う（青と赤のルートを作る）
①インターフェイスを管理サーバーに作ります
#ifconfig eth0:1 ＳＳＶＭリンクローカルアドレス/24
#ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr ＿＿＿＿
inet addr:＿＿＿＿ Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:17 Memory:de020000-de040000
イーサ０の設定をコピー
#cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:1
デバイスとＩ‘Ｐを書き換える
#vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
#ifup eth0:1
device eth0:1 is already a member of a bridge; can't enslave it to bridge cloudbr0.
#ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr ＿＿＿＿＿
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:17 Memory:de020000-de040000
ＩＰの情報かでてこない・・・
#service network restart
# /sbin/iptables -t nat -A PREROUTING -d ＿＿＿ -i eth0:1 -j DNAT --to 作ったインターフェスのアドレス
クラウドブリッジのところが変だなあ。どのように直せばよいのだろう。
というわけで、気を取り直してもう一度やってみた。
#ifconfig eth0:1 eth0:1に割り当てたいアドレス/24
#ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr ＿＿＿＿
inet addr:＿＿＿＿ Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:17 Memory:de020000-de040000
# /sbin/iptables -t nat -A PREROUTING -d 172.16.96.116 -i eth0:1 -j DNAT --to 作ったインターフェスのアドレス
#service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
#service iptables restart
iptables: Setting chains to policy ACCEPT: nat [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: [ OK ]
#service network restart
ＳＳＶＭからイーサ０１におくり、イーサ０１からＧＷにおくるルートをつくればいいのではないかと考えた。
以下前と後の比較
#iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT all -- anywhere ＳＳＶＭ to:192.168.2.254（作ったインターフェスのアドレス）
DNAT all -- anywhere ＳＳＶＭ to:192.168.2.254
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# /sbin/iptables -t nat -A PREROUTING -d 192.168.2.254 -i et
h0:1 -j DNAT --to ＧＷ
#iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT all -- anywhere ＳＳＶＭ to:192.168.2.254
DNAT all -- anywhere ＳＳＶＭ to:192.168.2.254
DNAT all -- anywhere 192.168.2.254 to:ＧＷ
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
#iptable save/restart
ＵＩで準備完了になっているか確認をするも変わらず。何がたりないのだろう。
ここで荒井さんにSNATの設定も必要だと聞く。
なぜSNATが必要なのかがわからなかったのでSNATをもう一度調べたところ、staticNATだと思っていたものが、sourceNATというものだと分かりました。
SNATを使うと、送信元アドレスを変換することができます。
→続く
ちなみにiptablesで不要になった部分の消し方は・・・
チェーンに番号を表示させて、
# sudo iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
1 SNAT all -- ＿＿＿＿ anywhere to:192.168.2.254
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
指定して消す
# sudo iptables -t nat -D POSTROUTING 1
確認すると
# sudo iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
なくなっています：）
参考
http://www.atmarkit.co.jp/ait/articles/0111/23/news003_2.html
http://aidemoire.hatenablog.com/entry/2013/10/04/184507
http://jehupc.exblog.jp/11784724/
http://jmgcomputer.blogspot.jp/2012/09/snatdnat.html
http://seesaawiki.jp/w/kaakichi7/d/ifconfig%A4%C7%A5%CD%A5%C3%A5%C8%A5%EF%A1%BC%A5%AF%A4%CE%C0%DF%C4%EA%A4%F2%A4%B9%A4%EB
http://itpro.nikkeibp.co.jp/article/COLUMN/20080715/310814/
CloudStack⑪システムＶＭ(３日目)
おはようございます。
今日はＳＳＶＭをenableにさせてインスタンスを作成します。
ホスト# cloud-setup-agent
Welcome to the CloudStack Agent Setup:
Please input the Management Server Hostname/IP-Address:[___]***
Failed to resolve ocdetdh05. Please input a valid hostname or IP-Address.
管理#vi /etc/idmapd.conf
[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
The default is the host's DNS domain name.
Domain =***
# The following is a comma-separated list of Kerberos realm
# names that should be considered to be equivalent to the
# local realm, such that <user>@REALM.A can be assumed to
# be the same user as <user>@REALM.B
# If not specified, the default local realm is the domain name,
# which defaults to the host's DNS domain name,
# translated to upper-case.
# Note that if this value is specified, the local realm name
# must be included in the list!
#Local-Realms =
[Mapping]
User = root
Group = root
#vi /etc/exports
/strage ____/255.255.255.0(rw,async,no_root_squash,no_all_squash)
システムの再起動を行いました。rpcbindもnfslockも初めて見ました。
どちらもrpcプロセスに関連するもので、前者はｒｐｃの動きをリッスンしているポートに流し、後者はサーバーにあるファイルのロックをNFSクライアントに許可しています。rpcとはNW上の異なるマシン間で処理を実行する手続きのことを指すそうです。ここでいうと、管理サーバーとホストサーバーの通信を担当してくれています。
#service rpcbind start
#chkconfig rpcbind on
#service nfslock start
#chkconfig nfslock on
#service nfs start
#chkconfig nfs on
ログの確認。
2014-05-20 11:12:09,180 DEBUG [cloud.server.StatsCollector] (StatsCollector-3:null) There is no secondary storage VM for secondary storage host nfs://____/export/secondary
ファイルを作って、マウントそのものが可能なのか確かめてみました。
#mount -t nfs ____:/export/cloud/secondary /mnt/secondary
mount.nfs: mount point /mnt/secondary does not exist
大丈夫ですね。
そして、セカンダリストレージの中にテンプレートが入っているかを見ました。
#cd /export
#ls
primary secondary
#cd /export/secondary
#ls
template
#cd /export/primary
#ls
2180b082-9b5b-4f4c-8d1a-3358c80fd15b s-1138-VM-patchdisk s-21-VM-patchdisk
8d99cb89-f94d-40d0-838e-da8a3c6de89f s-17-VM-patchdisk s-22-VM-patchdisk
a2f9e264-e2ff-4b72-9ff9-36049abb9a51 s-18-VM-patchdisk s-23-VM-patchdisk
b5aeb2e1-7929-432a-aa67-cf961f9d7588 s-19-VM-patchdisk s-24-VM-patchdisk
KVMHA s-20-VM-patchdisk v-2-VM-patchdisk
#vi /etc/export
内容を元に戻しました。
ホストを見ると止まっていたので強制接続、それでも動かなかったので削除して作り直しました。
その後システムＶＭを見ると、動いていました！やっと動きました。とてもとても良かったです； ；
さてお次はテンプレートです。こちらを確認をしたら状態がNoでした。
SSVMはホストにあるので、ホストサーバーからログインです。
# ssh -i /root/.ssh/id_rsa.cloud -p 3922 リンクローカルIP
The authenticity of host '[____]:3922 ([＿ＩＰ＿]:3922)' can't be established.
RSA key fingerprint is ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿.
Are you sure you want to continue connecting (yes/no)? yes
管理サーバーに届いているか→no
# ping ______
PING _____ (_____): 56 data bytes
64 bytes from 172.16.96.115: Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 5400 0000 0 0040 40 01 f902 ＿＿＿ ＿＿＿
bytes from 172.16.96.115: Destination Host Unreachable・・・・・
6 packets transmitted, 0 packets received, 100% packet loss
# cd /var/log/cloud
# ls -al
total 296
drwxr-xr-x 2 root root 4096 May 20 03:06 .
drwxr-xr-x 8 root root 4096 May 20 03:06 ..
-rw-r--r-- 1 root root 129889 May 20 03:40 cloud.out
-rw-r--r-- 1 root root 151683 May 20 03:40 systemvm.log
# cat systemvm.log
2014-05-20 03:06:21,964 INFO [utils.component.ComponentLocator] (main:) Unable to find components.xml
・
・
・
ホストに到達していないことを確認グローバル設定からホストサーバーのＩＰに変更→管理サーバーを再起動→ＳＳＶＭを削除
少し待っていたらstartingになり、また少し待つとenableになりました。
今までＳＳＶＭがなかなかできずにいたので、消してまた作れなくなってしまったらどうしようと心配でした。新しく作られて本当に良かった！
わくわくしながらテンプレを見に行きましたがNoのままでした。
あ、間違えた。違う作業をしていました。
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
____ ____ 255.255.255.255 UGH 0 0 0 eth1
____ ____ 255.255.255.224 UG 0 0 0 eth1
____ 0.0.0.0 255.255.255.0 U 0 0 0 eth2
____ 0.0.0.0 255.255.255.0 U 0 0 0 eth1
____ 0.0.0.0 255.255.255.0 U 0 0 0 eth3
____ 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 192.168.2.254 0.0.0.0 UG 0 0 0 eth2
↑グローバルIPと通信できていない
# cat /etc/resolv.conf
nameserver IP___
nameserver DNS1___
# ping www.google
ping: unknown host
↑DNSサーバと通信できていない
管理側からはpingでwww.google.comに飛びます。
ホスト側からインターネットに届かない理由はＳＳＶＭへのアドレスの割り当ての範囲を適当に決めてしまったからでした。
というわけで、これからＮＡＴの設定をしていきます。
参考
https://groups.google.com/forum/#!msg/cloudstack-ja/xuo0sSWkR_4/1PnLh3389xsJ
https://groups.google.com/forum/#!msg/cloudstack-ja/46h7-0EgCwE/SyTJdJUvPC0J
Wordpress⑧カスタマイズ
デフォルトの状態ではブログが見にくかったので変更しました：）
外観→テーマ編集→スタイルシート
スタイルシートの編集はパーミッションの設定をしてから行います。
# find / |grep style.css
/var/www/html/wordpress/wp-content/themes/esquire/style.css
/var/www/html/wordpress/wp-content/themes/sugar-and-spice/style.css
/var/www/html/wordpress/wp-content/themes/supernova/style.css・・・・・・・
# cd //var/www/html/wordpress/wp-content/themes/sugar-and-spice/style.css
# ls -la
-rw-r--r-- 1 root root 442 Apr 15 13:12 sidebar.php
-rw-r--r-- 1 root root 1618 Apr 15 13:12 single.php
-rw-r--r-- 1 root root 30148 Apr 15 13:12 style.css・・・・・・
# chmod 777 style-.css
①フォントと色を変える
変更箇所が太字です。上がABOUT ME、下が本文の箇所にあたります。
/* 01. Basic Styles & Typography
================================================== */
body {
font-size: 87.5%;
line-height: 1.5;
font-family: メイリオ, Meiryo, Osaka, “ヒラギノ角ゴ Pro W3″, “Hiragino Kaku Gothic Pro”, “ＭＳ Ｐゴシック”, “MS PGothic”, sans-serif;
color: #000000; /*#797979*/
-webkit-font-smoothing: antialiased; /* Fix for webkit rendering */
-webkit-text-size-adjust: 100%;
-ms-word-wrap: break-word;
word-wrap: break-word;
}
/* Typography */
h1, h2, h3, h4, h5, h6 {
color: #000000;
font-family: メイリオ, Meiryo, Osaka, “ヒラギノ角ゴ Pro W3″, “Hiragino Kaku Gothic Pro”, “ＭＳ Ｐゴシック”, “MS PGothic”, sans-serif; /*"Raleway", Arial, sans-serif;*/
font-weight: 800;
margin: 0.75em 0;
}
②背景
外観→背景→画像のアップロード→タイル
③もし反映されなかったら・・・
キャッシュを消去します。履歴→キャッシュ→すべて
変更前と比較をば。変更後もタイトルが薄いですね。
Cloudstack⑧仮想ルーターが出来ない（後編）
テンプレの登録をします。
ここでワードプレスのお引越しもとである環境にあるテンプレを使うことに。
方法は以下の通り。
ダウンロードしたいテンプレを探します。
クラウドスタックのＵＩ⇒テンプレート⇒ダウンロードしたいもの（今回はCentOS6.4）
この後にアドレスが出てくるので、アドレスをコピー。ダウンロードしたい環境で、テンプレートの登録をします。
ＵＲＬのところにさきほどコピーしたアドレスをはり、名前を入力。
ダウンロードをスタートさせ、タスクが完了したら、
# service management-server restart
テンプレがきちんと動いているかを確認
ところが・・・
↓
どうしてなのか調べてみた
・現象
デフォルトテンプレートのGUI(KVM)が表示されるが、
ダウンロードが完了しない。
準備完了 No
状態
・原因
SecondaryStorageVMから、download.
ネットワークおよびDNS設定が正しく設定されていない
まだネットワークが直っていなかったのですね。ここで、エージェントログを見ます。
# cd /var/log/cloud
tail -n 150 agent.log
cloudbr1が見つからずにいることがわかったのでもう一度設定しなおします。
ＳＳＶＭが通信できていないのもこれが原因と思われます。
なぜか分かりませんがＵＩからの設定ができなかったので、表と裏の両方を使っていることになっています。セカンダリストレージが表のアドレスで作れなかったので。
イメージはこんな感じ：）
ホスト側、管理サーバーがわの両方から設定を行う
# cd /etc/sysconfig/network-scripts
# vi ifcfg-eth0
・
・
・
①ホスト側
DEVICE="eth0"
BOOTPROTO=none
HWADDR=00:00:00:00:00:01
#NM_CONTROLLED="yes"
ONBOOT=yes
TYPE="Ethernet"
IPV6INIT=no
IPV6_AUTOCONF=no
IPADDR=1.1.1.1
BRIDGE=cloudbr1
NETMASK=255.255.255.0
（２）eth1
DEVICE="eth1"
BOOTPROTO=none
HWADDR=00:00:00:00:00:02
ONBOOT=yes
TYPE="Ethernet"
IPV6INIT=no
IPV6_AUTOCONF=no
IPADDR=1.1.1.2
BRIDGE=cloudbr1
NETMASK=255.255.255.0
（３）cloudbr0
DEVICE="cloudbr0"
BOOTPROTO=none
ONBOOT=yes
TYPE="Bridge"
IPADDR=1.1.1.1
NETMASK=255.255.255.0
GATEWAY=*.*.*.*
DNA1=*.*.*.*
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=5
STP=yes
（４）cloudbr1
DEVICE="cloudbr１"
BOOTPROTO=none
ONBOOT=yes
TYPE="Bridge"
IPADDR=1.1.1.2
NETMASK=255.255.255.0
GATEWAY=*.*.*.*
DNA1=*.*.*.*
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=5
STP=yes
# service network restart
②ホスト側
（１）eth0
DEVICE="eth0"
BOOTPROTO=none
HWADDR=00:00:00:00:00:03
ONBOOT=yes
TYPE="Ethernet"
IPV6INIT=no
IPV6_AUTOCONF=no
IPADDR=0.0.0.1
BRIDGE=cloudbr1
NETMASK=255.255.255.0
（２）eth1
DEVICE="eth0"
BOOTPROTO=none
HWADDR=00:00:00:00:00:04
ONBOOT=yes
TYPE="Ethernet"
IPV6INIT=no
IPV6_AUTOCONF=no
IPADDR=0.0.0.2
BRIDGE=cloudbr1
NETMASK=255.255.255.0
# service network restart
じつは最初に、管理サーバーのＭＡＣアドレスを間違えてホストサーバーのもので登録してしまいました。
管理サーバーでservice network restartをしたら、失敗してしまったのでそこで気づいて直したのですが、あろうことか直したものが間違っていました。自分のメモを見て、0(ゼロ)と0を見間違えているような気がしてきました・・・ そうして環境に入れなくなってしまったのです・・・
けれどもなぜでしょうか。今までも間違ったものを設定していたわけですし、環境に入れなくなるほどの間違いだとは思えません。
（クラウドスタックのネットワークをまだきちんと理解していないのでそう思ってしまう。）
分からないのであとで聞いてみます！
以上の作業によって、クラウドスタックのネットワークがきちんと動くようになります。（おそらく）
ＳＳＶＭがセカンダリストレージにテンプレやイメージをとりにいって、
システムＶＭが動くようになり、プライマリストレージにも書き込みにいけるようになります！
これでインスタンスを作る準備が整いました：）
参考
https://groups.google.com/forum/#!topic/cloudstack-ja/46h7-0EgCwE
http://www.slideshare.net/interto/1cloudstacｋ
docker① ドッカーってなに
４月のあたまに、近藤さんと前佛さんが時代はgithub、docker、nginxだと教えてくださしました。
帰宅途中にぐぐり、その3つの便利さはわかったのですが、何が凄いのかはいまいちピンと来ません・・・
そんなある日、まあ今日なのですが、会社の定例でdockerについてお話を伺う機会がありました。
自分なりの解釈にすぎませんが（つまり合っているかどうかが分からないということ！）、簡単にまとめてみます：）
■dockerとは？
ハイパーバイザーのはたらき ＋ 構成を組み易くするソフト
けれどもハイパーバイザーとは違う
jailともchrootコマンドとも違う
Ａｐのコンテナ実行環境
ＬＸＣ
技術要素：ＡＵＦＳ ファイルシステム ディスク容量を食わない 起動時間短縮
■コンテナとは？
ＯＳミドルウェアの実行環境
仮想マシンとは違った操作
開発環境 仮想マシンを立ち上げるのはdockerのほうが早い
■何が変わる？
・仮想マシンのようなものではなく ＨＷが見えない部分で仮想化ができる
・ＯＳのマシンイメージをつくることもできる
・サーバ活況構築の簡易化
・インフラ環境の抽象化：インフラ層が何でも良くなる（どのクラウドでもオッケー）
・同じコマンドを使って、移動先でも同じ動作が出来る
■どこかがおちたら自動で復旧はえきるのか？
マシン単位ではなく特定のアプリケーションで可能
■課題
ＨＷの管理は可能か：dockerの管理するところではない
リソース管理鍵：監視が必要
クラスタ全体の管理は自分で実装
物理マシン一台以上はdocker自身が実現できない←？
■その他
クラウド間をまたいでファイルを利用できるしくみがdocker、ではその利点は？：クラウド間のイメージ移行ができる；同じ環境で
coreＯＳ：dockerがデフォルトではいっている
クラウドごとに同じ環境が作れるようになる
イメージファイルを書き換える必要がない
クラウドや仮想化マシンは実は昔からあった、今回もそんな感じなのではないか：うーんそうとも言える
図式化すると、層がひとつなくなっていることが一目で分かります。ハイパーバイザーが要らないのか～。
ただ、これだけではコンテナのコンテナっぽさが伝わってきませんね。
具体例をだすと、
というかんじ。今まではデータベースをコピーして、apacheやphpはインストールしなおしていましたが、その手間が省けると。
なるほど、それなら便利さが分かります。
参考
http://qiita.com/curseoff/items/a9e64ad01d673abb6866
http://2013.8-p.info/japanese/06-22-docker.html
http://www.slideshare.net/nekoruri/20140328-docker-15min
http://www.infoq.com/jp/articles/docker-containers
