前から気になっていたガラポンTVを購入した。
ガラポンTVは、
ワンセグ局全局を内蔵もしくは外付けHDDへ記録するサーバで
価格は最近はだいたい約4万円前後で販売されている。
Regzaサーバは地デジを記録するので内蔵4TBでせいぜい1週間が
いいところだが、このガラポンTVはワンセグなので
画像は荒くはなるが記録する時間は内蔵ストレージだけで2週間、
3TB HDDを増設すれば90日間録画することができる。
Regzaサーバは同一セグメント内で他デバイスで再生可能であるのに対し、
ガラポンTVはユニバーサルプラグアンドプレイ対応のルータを使っていれば
外部のインターネット回線経由で再生が可能である。
但し特殊なポートを通信に使用しているため、
プロクシ経由での視聴はポートフォワーディングなどを行わない限りできない。
ルータのWAN側がグローバルIPアドレスであれば、
DHCPでの割り当てであっても屋外からも視聴できる。
どうもガラポンTVがIPアドレス変更を認識すると
ガラポンTVサイトへ変更されたことを伝達するしくみになっているらしい。
なので
屋外から視聴する場合は一旦ガラポンTVサイトへログインしてから
自宅のガラポンTVへ接続するので、
DHCPであっても受信可能なのだとおもう。
Regzaは画像品質重視であるのに対して
ガラポンTVは記録期間重視で
iPhoneやAndroidなどのスマートフォン、
iPadなどのデバイスでも視聴可能だ。
#無料の専用アプリが用意されている
私の自宅はインターネットマンションで
ユニバーサルプラグアンドプレイ対応のルータ経由で
使用しているが、
こんな環境であっても屋外からLTE回線で
iPhoneでTVを見ることができる。
自宅では無線LANで同一セグメントにつないでいたiPad経由で設定を行ったが
ルータの設定変更などややこしいルーティング関連の設定は自動だった。
#ユニバーサルプラグアンドプレイでないルータとか一部のルータは
#個別せってし無くてはならない
時間も30分くらいかな。
#一番長いのがワンセグのチャンネル検索だったがそのほかはほとんど時間がかからなかった。
必要なのは同軸ケーブルとLANケーブル(両方同梱されていない)。
国内の動画サイトは海外からの利用が不可な場合が多いが
このガラポンTVを使えば海外常駐者でもブロードバンド環境さえあれば
いつでも日本のTVを視聴することができる、というのが宣伝文句だ。
でもインドに半年いたけど
国内にあるサーバまでは距離が遠すぎて
回線速度が確保できなかった。
ニコニコ動画は当時国内サーバしかなかったので
ぶつぶつきれてしまいほぼ使い物にならず
もっぱらyoutubeへアップされた番組をちょこちょこみていた。
回線品質の良い国なら使い物になるかな..
くらいで思っていたほうが良いと思う。
本音を言えばストレージをクラウド上においてほしいところなのだけど、
たぶんTV業界の既得権益ホルダーな人たちがやいのやいのいうから
できないのだとおもう。
もしそうなっちゃったら
「TVの電波、いらないんじゃないの?」ってなっちゃうからね。
..生きてる間は難しそうだなあ..
仕事上でわかったことのうち顧客に関わる情報が無い物、一般公開して差し障りのなさそうな事をたまーに投稿しています。 ちなみに、記事上に載せた私が書いたコードは、用途問わず再利用いただいてかまいませんが、保障は一切いたしませんので、あしからず。 ですます調の記事とである調の記事が混ざりますが..こちらも、あしからず。
Translate
2013年11月12日火曜日
2013年10月23日水曜日
CloudStack4.2.0をインストールしたら、システムVMがStartingのままになる
CloudStack4.2.0のdebパッケージが配置されていたので、
早速Ubuntu Server12.04LTSにインストールしてみた。
4.0/4.1/4.1.1/4.1.1-1と全く同じ手順でインストールを行い、
管理コンソールからいざ「ゾーンの有効化」をはじめると..
Secondary Storage VM、Console Proxy VM両方共「Starting」のままで
いくら待っても起動しない。
/var/log/cloudstack/management以下のログを見ると
Exceptionが発生していた。
システムVMが上がらない系の問題は
CloudStackインストールを試す人はぼぼかならず引っかかるが
その際の動きは微妙に違う。
多いのは起動→失敗→インスタンス作り直し→起動→失敗..を繰り返し
VMの名前の数字がどんどん上がっていくパターン。
#こっちはNFSのマウントオプションにミスが有ることが多い
今回はこれとは違うので、mountオプションの問題ではなさそうだ。
いろいろためしたがうまくいかない..
..で、ふと管理コンソールに「領域」という概念が増えていることに気づく。
もしかしたらVMのテンプレート自体がかわっとのかもしれない..
でInstall Guideを読んでみると..
4.5.9 Prepare the System VM Templateの記述で
cloud-install-sys-mount-tmpltコマンドの
KVMのテンプレートURLが
http://download.cloudstack.com/templates/acton/acton-systemvm-02062012.qcow2.bz
でなく
http://d21ifhcun6b1t2.cloudfront.net/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2
になっとる..
..気づくのに、1ヶ月かかった..
2013年10月8日火曜日
CloudStack4.2.0がやっとUbuntu Server12.04LTSでapt-getできるようになった
10月はじめに4.2.0がリリースされていたのだが、
何度かトライしたが、
Ubuntuのapt-getコマンドで取得できるような環境はまだできあがっていなかった。
しかたないのでdebファイルを直接入手してdpkg -iでインストールしていたが、
さきほどようやくapt-get/aptitudeできるようになった。
でも、ダウンロード速度が..遅すぎ..
cloudstack-managementなんて137MBしかないのに
1時間どころじゃない..
みんなやっているから?!
ソースから構築するのがスピード的には一番よさそうだ..
CloudStack4.2.0自体はまだしっかり試していないが、
管理コンソールに「アフィニティグループ」と「領域」の2つのメニューが増えていた。
領域はリージョンのことで、
別のDCにあるCloudStackを操作する時にサーバ指定を変えるなどかなと想像できるが..
アフィニティグループねえ..小集団で全員管理者とかかな?
もうちょっと調べてみるか..
p.s.
ちなみにインストールは4.1とほぼかわらないが
プライマリ指定のときゾーン全体にしてNFSサーバを登録するとエラーになるので
クラスタ指定でインストールすれば素直にセットアップがとおる。
ただし、ひっかかるのがSystem VMのテンプレートをダウンロードしてくる所。
URLが変わっているのだ。
それに気づかずに、4.1時代のテンプレートをセカンダリストレージにおいてしまうと、
例の「ゾーン有効化直後System VMが上がらない(ずーっと2つともStarting)」状態
に陥る。
何度かトライしたが、
Ubuntuのapt-getコマンドで取得できるような環境はまだできあがっていなかった。
しかたないのでdebファイルを直接入手してdpkg -iでインストールしていたが、
さきほどようやくapt-get/aptitudeできるようになった。
でも、ダウンロード速度が..遅すぎ..
cloudstack-managementなんて137MBしかないのに
1時間どころじゃない..
みんなやっているから?!
ソースから構築するのがスピード的には一番よさそうだ..
CloudStack4.2.0自体はまだしっかり試していないが、
管理コンソールに「アフィニティグループ」と「領域」の2つのメニューが増えていた。
領域はリージョンのことで、
別のDCにあるCloudStackを操作する時にサーバ指定を変えるなどかなと想像できるが..
アフィニティグループねえ..小集団で全員管理者とかかな?
もうちょっと調べてみるか..
p.s.
ちなみにインストールは4.1とほぼかわらないが
プライマリ指定のときゾーン全体にしてNFSサーバを登録するとエラーになるので
クラスタ指定でインストールすれば素直にセットアップがとおる。
ただし、ひっかかるのがSystem VMのテンプレートをダウンロードしてくる所。
URLが変わっているのだ。
それに気づかずに、4.1時代のテンプレートをセカンダリストレージにおいてしまうと、
例の「ゾーン有効化直後System VMが上がらない(ずーっと2つともStarting)」状態
に陥る。
# /usr/share/cloud-common/scripts/storage/secondary/cloud-
install-sys-tmplt -m /mnt/secondary -u
http://d21ifhcun6b1t2.cloudfront.net/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2
-h kvm-F
ご注意を。
2013年9月10日火曜日
CloudStackにおけるrealhostipの役割についてのwiki文書を翻訳してみる
コンソールProxy VMが使用しているrealhostip.com、
こっちでDNS設定していないのに勝手にDNS正引きして
コンソールを表示(したり、表示できなかったり)することを
疑問に思っていた。
CloudStack wiki をちょこちょこみていると
ふと
Role of realhostip in CloudStack
なるページを見つけた。
ので、ちょっと翻訳してみた。
正直ちょっとくせがあるので、正確に翻訳できたかは不明。
なので参照の際はくれくれもat your own riskでお願いします。
--------
CloudStackにおけるrealhostipの役割
どのようにrealhostip DNS名はCloudStack内で正確に処理されているのか、という質問を定期的にうけます。realhostip.comドメインは、異なるカスタマサイト内のすべてのCloudStackインストレーション間でHTTPS通信を動作させるために存在しますが、管理者無しでどうやってデプロイ環境の変更のためにSSL認証をロードしているのかを心配しているのです。
SSL認証はCloudStackシステムVMでHTTP接続を行う際に使用されています。例えば、コンソール proxy VM やセカンダリストレージVMなど、両方内部のHTTPサーバで使っています。
realhostip.com SSL認証は、すべての*.realhostip.com DNS名が認証を使用するとみなすワイルドカードアドレスでサインされています。各CloudStackカスタマは各々の環境を持つため、各カスタマの環境はそれぞれにシステムVMを保有し、各システムVMはそれぞれにIPアドレスを保有することになります。
異なるカスタマ間のすべてのインスタンスに適用するためある1つの認証を使用する場合、CloudStackによってホストされるダイナミックDNSサービスの提供する解決方法を漏らしてしまいますが、DDNSサービスは基本的に「xxx-xxx-xxx-xxx.realhostip.com to IP address xxx.xxx.xxx.xxx」というDNS名からIPアドレスまでのフォームに変換します。
CloudStackは各環境のIPアドレスをコントロールしているので、SSL認証が必要な時はいつでも、カスタマが環境を実行中であることは重要ではなく、そのようなDDNSサービスが有効なので、いつでも絶えず変更されるIPアドレス上でサフィックスがrealhostip.comであるドメインの割り当てが可能となります、これがすべてのCloudStack実行環境間である1つのSSL認証が一般的に適用可能とする我々のトリックです。
これらのケースの殆どでは、主な目的が(サイト認証の正確性ではなく)セキュアなコミュニケーションチャネルを確立することであるため、DNS名の醜さがエンドユーザに対して見せることはなありません、しかしながら、カスタマが面倒を見るケースもあり、それゆえ、コンソールproxy VMはユーザに対してユーザ自身のSSL証明書を使用するためのカスタマイズ可能な方法を提供します。
ケルビン
--------
そうかセキュアな通信をするためにSSL証明書が必要で、
証明書を作成するには何がしかのFQDNが必要になり、
それで*.realhost.comというワイルドカード証明書を作ったわけか。
で内部でDDNS機能を持たせてそこで名前解決させていた、と。
どうも文章がただしければ、こっちでSSL証明書やドメイン名はかえられるようだけど..
たしかにちょっとトリッキーな使い方してるなあ..
ご参考まで。
CloudStackにおけるドメイン、アカウント、ユーザ、そしてプロジェクトをどう使うか
CloudStackを本格的に使用する場合、ドメイン、アカウント、ユーザを作成しなくてはならないが、それらについてまず理解しておく必要がある。
そこで、以下のサイトを翻訳してみた。
Accounts, Domains, and Admin explained
以下、翻訳した文章である。
(参照の際はat your own riskでお願いします)
ここから--------
ドメインは複数のアカウントを保有する事ができます。各アカウントは複数のユーザを保有することができる。リソースの所有権はアカウントにひも付けされます。ユーザとは、丁度銀行口座において異なる利用者が銀行口座に対して参照権限をもつような、アカウントリソースへアクセススするための単なる同義語です。それぞれのユーザパスワードを持ちますが、同一の預金口座資金を使用します。CloudStack UIでアカウントやユーザを作成することで、より深く理解できるでしょう。
ここまで--------
アカウントは、いわゆるパーティパターンの"パーティ"に相当し、個人1名をあらわすことも部署などのグループを表すこともできる設計になっている。
ドメインもグループを表す論理単位なのだが、ドメイン間でのリソースが共用できないようなので、それこそクラウドビジネスでIaaSとしてCloudStackリソースを提供する際の契約単位とかに利用するため設計されたのだろう。
社内IaaSで他社が出てこない場合は、1つのドメインでも運用はできそうだが、ルートドメインにインスタンス数上限などのリソース制約が切れない以上、ルート以外に1つドメインは切っておいたほうが良い。
アカウント、ドメインも複数の人間が参加する組織や団体をあらわす論理単位だけど、CloudStackには"プロジェクト"という論理単位も存在する。
このプロジェクトについても理解しておく必要があるため、CloudStack wikiをさがしてみた。
するとQ&Aに以下のドキュメントを発見した。
Accounts, Domains, and Projects oh my!
以下、翻訳した文章である。
(こちらも、参照の際はat your own riskでお願いします)
ここから--------
ドメインは(会社や団体など)組織の単位とほぼ同じです。ドメインは、(一般的に)リソースを所有していませんが、しかしドメインはドメイン範囲内のすべてのアカウントに対しリソース制限を強制することができます。ドメインはプロジェクトやアカウントを収容することができます、しかしドメインは本当にドメイン自身だけでインスタンス、ボリューム、他のリソースなどを所有しません。ドメインは、インスタンス、ボリューム、ネットワーク、スナップショット、テンプレートなどのようなリソースを所有できるその他のもののための器(コンテナ)です。ドメインは親ドメインに対して一意でなくてはなりませんが、その他のドメインの子であるなら(同じドメイン名を)繰り返すことができます(ROOT/dom1/sub1とROOT/dom2/sub1は"sub1"が一意ではありませんがそれぞれの親が一意であるため使用することができます)。
ルートドメインは、すべてのドメインがルートドメインの子となるため、少々特殊です。ルートドメインの管理者アカウントは、すべての子ドメインに所属する(すべてのドメインの意、なぜならすべてのドメインはルート(ROOT)の子であるため)その他のリソースを(API経由で)操作する権限を保有しています。このためルートドメインの管理者アカウントは全体管理権限を保有することとなります。
本文書記述時点では、CloudStackはロールベースアクセス制御(RBAC)をサポートしていませんが、2つのレベルのパーミッション、管理者(admin)と利用者(user)が存在しています。アカウント名は1つのドメイン内で一意でなくてはなりませんが、すべてのドメインに対して一意でなくてもかまいません(joe@foo.tldとjoe@bar.tldは、"joe"が一意ではありませんが、foo.tldとbar.tldが一意ではないため、使用することができます)。
管理者アカウントはドメイン管理権限を保有しています。管理者アカウントは、ルート管理者により対象のドメインに対しドメイン制約(許可されるインスタンス数、ボリューム数など)を強制されていますが、多くの特権を保有しています。例えば、ドメイン管理者はドメイン内にアカウントを追加や、ユーザのAPIキーを生成する事ができます。自身のドメインのサブドメインを作成したり、ドメイン内のリソース利用状況をレポートする事もできます。
利用者アカウントは新規のリソース(インスタンス、ボリューム、スナップショットなど)を作成する権限を保有していますが、管理特権はとても少ないです。アカウントはAPIキーを生成できませんし、アカウントへユーザを追加することもできません、参照することだけは可能です。利用者アカウントが使用できるすべてのコマンドリストはAPIガイドを参照して下さい。
ユーザ名、パスワード、APIキーはアカウントに属します。Web UI からユーザ名とパスワードを用いて、(そしてもしAPIキーが生成されているのであれば、APIキーを用いて)ログインします。ユーザ名は所属するドメイン内で一意でなくてはなりません(foo.tldドメイン範囲内の2つのユーザは同じユーザ名を持つことはできません-2つのjoo@foo.tldユーザを持つことはできません)が、異なるドメインであれば可能です(joe@foo.tldとjoe@bar.tld)。ユーザはリソースを所有することはできません、所属するアカウントが所有するリソースへの操作やアクセスといった単純な使い方のみです。ユーザは個別のパーミッションを保有することができません、ユーザが所属するアカウントのパーミッションを受け継ぎます。
アカウントはリソースを所有します。アカウントはリソースを所有します、重要なので二度いいました。もしアカウントを削除したならば、所有していたすべてのリソース(インスタンス、ボリューム、スナップショットなど)は同様に削除されます。利用状況はアカウントレベルでも追跡されます。このため、課金やチャージバック目的のためにusageモジュールが有効である場合、アカウントレベルでのリソース使用状況のレポーティングが有効となります。
プロジェクトはアカウントに似ていますが、アカウントとは違い特別な一面を持っています。プロジェクトはリソースの制御を複数のアカウントで共有することができます。リソース自身(インスタンス、ボリューム、スナップショットなど)はプロジェクトにより所有され、同一ドメイン内の複数のアカウントによる操作が許可されます。このため、ある組織内の複数の部署で取り組んでいる共同業務があるのであれば、プロジェクトを作成し他のアカウント(組織内の部署)を招待することで共同業務への参加を促すことができます。プロジェクトでは1つのアカウントはプロジェクト管理権限を委任しなければなりません。プロジェクト管理者は、対象ドメイン内の他のアカウントを招待したりアクセスを取り消す権限があります。プロジェクト管理者のみが対象のプロジェクトの操作権限を保有し、その他の(対象プロジェクトにアクセス可能な)アカウントに対する権限(例えば、許可されているインスタンス数やボリューム数、スナップショット数など)を保有していません。プロジェクト管理者が1つだけである間は、対象のプロジェクトが所有しているがそれに参加している個々のアカウントではないプロジェクトによって作成されたすべてのリソースであるため、影響を及ぼさないでアカウント間で移動することができます。
ここまで--------
翻訳しているとき業務としてのプロジェクトとCloudStackの論理単位であるプロジェクトが混ざっていて読みにくい..
CloudStackの論理単位である"プロジェクト"は、ドメイン内の複数のアカウントでリソースを共有でき、しかもまだ参加していないアカウントを"招待"することができる。
なので、プロジェクトは実業務上のプロジェクトと同じ考え方で切るほうがよいだろう。
ただ、usage server を使う場合は、アカウントとプロジェクトという単位以外では使用状況が追跡できないということは、システム監査などがうるさい企業で使用する場合は1アカウント=人間1人にして、1アカウント=1ユーザを守って管理していったほうがよいかもしれない。
とすると1企業内で使用する場合の例として
とか..かな。
プロジェクト管理者のプロジェクトビューのダッシュボード画面にはアカウントタブがあり、このタブの中でプロジェクト管理者権限を他のアカウントへ渡したり、(既存の)アカウントをプロジェクトメンバとして追加したりできます。
ちなみに以下のタイプモデルは、CloudStack4.1.1の管理コンソールを眺めて個人的に書いたものです。
図の中のアカウントの役割の管理者は"admin"、一般利用者は"user"をあらわしています。また、プロジェクトでの役割のプロジェクト管理者は"Admin"、一般プロジェクトメンバは"Regular"をあらわしています。
役割を表す構造がすこしきもちわるいので、ひょっとしたら将来的には関係主体・関係主体ロールのパターンに変更になるかもしれませんね。となると画面仕様も変更になるかも..まあ、想像ですが..
この図も参照の際はat your own riskでお願いします。
そこで、以下のサイトを翻訳してみた。
Accounts, Domains, and Admin explained
以下、翻訳した文章である。
(参照の際はat your own riskでお願いします)
ここから--------
アカウント、ドメイン、管理者の説明
ドメインは複数のアカウントを保有する事ができます。各アカウントは複数のユーザを保有することができる。リソースの所有権はアカウントにひも付けされます。ユーザとは、丁度銀行口座において異なる利用者が銀行口座に対して参照権限をもつような、アカウントリソースへアクセススするための単なる同義語です。それぞれのユーザパスワードを持ちますが、同一の預金口座資金を使用します。CloudStack UIでアカウントやユーザを作成することで、より深く理解できるでしょう。
詳細
- 1つのユーザは1つのアカウントにのみ所属することができます。同じユーザが複数のアカウントに所属することはできません。
- どんなドメインレベルでアカウントを作成する場合でも、アカウントは、管理者(admin)と利用者(user)の2つのタイプがあります。もしアカウントが管理者(admin)の場合はそのドメインのドメイン管理者となります、そしてもしアカウントが利用者(user)である場合はそのドメインの一般ユーザとなります。
- ROOTレベルで作成された管理者(admin)はルート管理者(ROOT admin)と呼称されます。ROOTがトップドメインなので、ルート管理者はすべてのリソースに対する操作特権を保有することとなります。
- ユーザ名は所属するアカウントのドメイン内で一意となります。異なるドメイン(サブドメイン含む)であれば同じユーザ名が存在してもかまいません。
- ドメイン名はフルパスが一意であれば同じドメイン名をつけることができます(例:ROOT/d1の場合、ROOT/foo/d1やROOT/bar/d2)。
- リソースは、アカウント内の個々のユーザではなく、1つのアカウントの所属となります。課金やリソース制限などはゆーざごとではなくアカウントごとに管理されます。
- CloudStackは、管理者(admin)アカウント、ドメイン管理者(domain-admin)アカウント、ユーザアカウントの3つの異なるタイプのアカウントの作成を許しています。すべてのロール(管理者(admin)、ドメイン管理者(domain admin)、ユーザ(user))はアカウントレベルに割り当てられます。CloudStack UI上で作成してそれぞれの違いを理解して下さい。
- あるアカウントのすべてのユーザは同じ特権を保有します。1つのアカウントの役割ベースのユーザは存在しません。
- 同一ドメインに複数の管理者を保有することができます。すべてのドメインはROOTドメイン以下に作成されます。
ここまで--------
アカウントは、いわゆるパーティパターンの"パーティ"に相当し、個人1名をあらわすことも部署などのグループを表すこともできる設計になっている。
ドメインもグループを表す論理単位なのだが、ドメイン間でのリソースが共用できないようなので、それこそクラウドビジネスでIaaSとしてCloudStackリソースを提供する際の契約単位とかに利用するため設計されたのだろう。
社内IaaSで他社が出てこない場合は、1つのドメインでも運用はできそうだが、ルートドメインにインスタンス数上限などのリソース制約が切れない以上、ルート以外に1つドメインは切っておいたほうが良い。
アカウント、ドメインも複数の人間が参加する組織や団体をあらわす論理単位だけど、CloudStackには"プロジェクト"という論理単位も存在する。
このプロジェクトについても理解しておく必要があるため、CloudStack wikiをさがしてみた。
するとQ&Aに以下のドキュメントを発見した。
Accounts, Domains, and Projects oh my!
以下、翻訳した文章である。
(こちらも、参照の際はat your own riskでお願いします)
ここから--------
アカウント、ドメイン、そしてプロジェクト、なんとまあ!
ドメイン
ドメインは(会社や団体など)組織の単位とほぼ同じです。ドメインは、(一般的に)リソースを所有していませんが、しかしドメインはドメイン範囲内のすべてのアカウントに対しリソース制限を強制することができます。ドメインはプロジェクトやアカウントを収容することができます、しかしドメインは本当にドメイン自身だけでインスタンス、ボリューム、他のリソースなどを所有しません。ドメインは、インスタンス、ボリューム、ネットワーク、スナップショット、テンプレートなどのようなリソースを所有できるその他のもののための器(コンテナ)です。ドメインは親ドメインに対して一意でなくてはなりませんが、その他のドメインの子であるなら(同じドメイン名を)繰り返すことができます(ROOT/dom1/sub1とROOT/dom2/sub1は"sub1"が一意ではありませんがそれぞれの親が一意であるため使用することができます)。
ルート(ROOT)ドメイン
ルートドメインは、すべてのドメインがルートドメインの子となるため、少々特殊です。ルートドメインの管理者アカウントは、すべての子ドメインに所属する(すべてのドメインの意、なぜならすべてのドメインはルート(ROOT)の子であるため)その他のリソースを(API経由で)操作する権限を保有しています。このためルートドメインの管理者アカウントは全体管理権限を保有することとなります。
本文書記述時点では、CloudStackはロールベースアクセス制御(RBAC)をサポートしていませんが、2つのレベルのパーミッション、管理者(admin)と利用者(user)が存在しています。アカウント名は1つのドメイン内で一意でなくてはなりませんが、すべてのドメインに対して一意でなくてもかまいません(joe@foo.tldとjoe@bar.tldは、"joe"が一意ではありませんが、foo.tldとbar.tldが一意ではないため、使用することができます)。
管理者アカウント
管理者アカウントはドメイン管理権限を保有しています。管理者アカウントは、ルート管理者により対象のドメインに対しドメイン制約(許可されるインスタンス数、ボリューム数など)を強制されていますが、多くの特権を保有しています。例えば、ドメイン管理者はドメイン内にアカウントを追加や、ユーザのAPIキーを生成する事ができます。自身のドメインのサブドメインを作成したり、ドメイン内のリソース利用状況をレポートする事もできます。
利用者アカウント
利用者アカウントは新規のリソース(インスタンス、ボリューム、スナップショットなど)を作成する権限を保有していますが、管理特権はとても少ないです。アカウントはAPIキーを生成できませんし、アカウントへユーザを追加することもできません、参照することだけは可能です。利用者アカウントが使用できるすべてのコマンドリストはAPIガイドを参照して下さい。
ユーザ名、パスワード、APIキー
ユーザ名、パスワード、APIキーはアカウントに属します。Web UI からユーザ名とパスワードを用いて、(そしてもしAPIキーが生成されているのであれば、APIキーを用いて)ログインします。ユーザ名は所属するドメイン内で一意でなくてはなりません(foo.tldドメイン範囲内の2つのユーザは同じユーザ名を持つことはできません-2つのjoo@foo.tldユーザを持つことはできません)が、異なるドメインであれば可能です(joe@foo.tldとjoe@bar.tld)。ユーザはリソースを所有することはできません、所属するアカウントが所有するリソースへの操作やアクセスといった単純な使い方のみです。ユーザは個別のパーミッションを保有することができません、ユーザが所属するアカウントのパーミッションを受け継ぎます。
アカウントとリソース
アカウントはリソースを所有します。アカウントはリソースを所有します、重要なので二度いいました。もしアカウントを削除したならば、所有していたすべてのリソース(インスタンス、ボリューム、スナップショットなど)は同様に削除されます。利用状況はアカウントレベルでも追跡されます。このため、課金やチャージバック目的のためにusageモジュールが有効である場合、アカウントレベルでのリソース使用状況のレポーティングが有効となります。
プロジェクト
プロジェクトはアカウントに似ていますが、アカウントとは違い特別な一面を持っています。プロジェクトはリソースの制御を複数のアカウントで共有することができます。リソース自身(インスタンス、ボリューム、スナップショットなど)はプロジェクトにより所有され、同一ドメイン内の複数のアカウントによる操作が許可されます。このため、ある組織内の複数の部署で取り組んでいる共同業務があるのであれば、プロジェクトを作成し他のアカウント(組織内の部署)を招待することで共同業務への参加を促すことができます。プロジェクトでは1つのアカウントはプロジェクト管理権限を委任しなければなりません。プロジェクト管理者は、対象ドメイン内の他のアカウントを招待したりアクセスを取り消す権限があります。プロジェクト管理者のみが対象のプロジェクトの操作権限を保有し、その他の(対象プロジェクトにアクセス可能な)アカウントに対する権限(例えば、許可されているインスタンス数やボリューム数、スナップショット数など)を保有していません。プロジェクト管理者が1つだけである間は、対象のプロジェクトが所有しているがそれに参加している個々のアカウントではないプロジェクトによって作成されたすべてのリソースであるため、影響を及ぼさないでアカウント間で移動することができます。
ここまで--------
翻訳しているとき業務としてのプロジェクトとCloudStackの論理単位であるプロジェクトが混ざっていて読みにくい..
CloudStackの論理単位である"プロジェクト"は、ドメイン内の複数のアカウントでリソースを共有でき、しかもまだ参加していないアカウントを"招待"することができる。
なので、プロジェクトは実業務上のプロジェクトと同じ考え方で切るほうがよいだろう。
ただ、usage server を使う場合は、アカウントとプロジェクトという単位以外では使用状況が追跡できないということは、システム監査などがうるさい企業で使用する場合は1アカウント=人間1人にして、1アカウント=1ユーザを守って管理していったほうがよいかもしれない。
とすると1企業内で使用する場合の例として
| CloudStack 論理単位 | 実際の割り当て |
|---|---|
| ルート管理者 | CloudStack管理を担当する人 |
| ドメイン | 会社名で1つ切る |
| ドメイン管理者 | アカウントやリソース分配を管理する人 |
| アカウント | 社員1名 |
| ユーザ | 社員1名→LDAPユーザと対応 |
| プロジェクト | 社内の実プロジェクトと同じ単位、ドメイン管理者に作ってもらう |
| プロジェクト管理者 | 実プロジェクトの責任者アカウント、1名のみ。社員1名に紐付けないアカウントでも、責任者となる社員1名に割り当てても良い |
とか..かな。
プロジェクト管理者のプロジェクトビューのダッシュボード画面にはアカウントタブがあり、このタブの中でプロジェクト管理者権限を他のアカウントへ渡したり、(既存の)アカウントをプロジェクトメンバとして追加したりできます。
ちなみに以下のタイプモデルは、CloudStack4.1.1の管理コンソールを眺めて個人的に書いたものです。
図の中のアカウントの役割の管理者は"admin"、一般利用者は"user"をあらわしています。また、プロジェクトでの役割のプロジェクト管理者は"Admin"、一般プロジェクトメンバは"Regular"をあらわしています。
役割を表す構造がすこしきもちわるいので、ひょっとしたら将来的には関係主体・関係主体ロールのパターンに変更になるかもしれませんね。となると画面仕様も変更になるかも..まあ、想像ですが..
この図も参照の際はat your own riskでお願いします。
2013年8月15日木曜日
CloudStack wikiのDevCloudのページの一部を翻訳してみる
All in Oneサーバを頑張って作っていたのだけど
いろいろあって心が折れたので、
DevCloudに転がることにしました。
で、何も見ないでセットアップしたら
なにやらUbuntuがあがって..
..その次何したらいいかさっぱりわからない..
ということでCloudStackのwikiにある
DevCloudという章だけをまず読んでみようと思い
翻訳してみました。
以下翻訳した文章ですが、
参照の際はAt your own riskでお願いします。
-------
DevCloudは、VirtualBox(オープンソースtype-2もしくはデスクトップハイパバイザ)上で動作するOVAイメージとして提供される仮想アプライアンスで、CloudStack開発やテスト用として利用することができます。オリジナルのDevCloudはRAMが2GB必要で、VirtualBoxの仮想マシンとして実行するxen.orgのXenサーバがのっているUbuntu Preciseとして動作します。
開発者はCloudStackアーティファクト(jars, wars)やファイルをDevCloudへビルド、デプロイしたり、DevCloud内部でデータベースをデプロイし管理サーバを起動することができます。開発者はDevCloud内部で動作するCloudStackを使ってDevCloudをホストとして追加することなども可能です。現在ではDevCloudは多くの方に利用されており、特にApache CloudStackの初期リリース(4.0.0-incubating)の間などにリリーステストのために利用されています。
DevCloudはVirtualBox(やXenServer)もしくはKVMハイパバイザどちらでも使用出来ます。これらのハイパバイザのウチ1つを選択することだけ必要です、そして次に以下のVirtualBoxもしくはLinux KVMのセットアップ章に従って下さい。
XenServerをネストされたハイパバイザで動作させたい場合は、 「CloudStack 開発のために Fusion を使用した XenServer ハイパバイザ」を参照して下さい。
https://cwiki.apache.org/confluence/display/CLOUDSTACK/XenServer+Hypervisor+for+CloudStack+Development+using+Fusion
注意:約900MBあります。
3.2 3.1で作成したネットワークを設定するために、(訳者注:VirtualBox Host-Only Ethernet Adapterを)右クリックし"ホストオンリーネットワークを編集"を選択して下さい。そしけ"DHCPサーバ"タブ上の"サーバを有効化"のチェックを外して下さい。
3.3 (Windowsのみ)OSの「スタート」→「管理ツール」→「セキュリティが強化されたWindowsファイアウォール」を選択して下さい。「Windowsファイアウォールのプロパティ」(中央のパネル「概要」ブロックの一番下)をクリックし、各プロファイル(ドメイン、パブリック、プライベート)タブの状態欄にある「カスタマイズ」ボタンを押して下さい。そして「VirtualBox Host-Only Network」のチェックを外します。そうすることで、ウィンドウズファイアウォールの通信ブロックは発生しません。
4.1 PAEモードがアクティブであるか確認します。(VirtualBoxの)「仮想マシン」→「設定」→「システム」→「プロセッサ」タブを選択し、「PAE/NXを有効化」がチェックされていることを確認します。
7.1 必要な場合は、「CloudStack開発環境のセットアップ」を実行します。
7.2 最新のマスタコードをチェックアウトします
7.3 ラップトップ上で管理サーバを起動します:
管理サーバが起動するまで待機します。
$ pip install mysql-connector-python (#marvin dependancy)
$ pip install requests (#reqd for marvin deploying the zone)
$ mvn -P developer -pl tools/devcloud -Ddeploysvr
# もしくは、上記のコマンドが動作しない場合は、
# おそらくMAVEN_OPTSを使用してmvnをデバッグモードで動かしています。
# marvinを試して下さい
$ cd tools/devcloud; python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
上記のコマンドで、いくつかのグローバル設定が登録されているtools/devcloud/devcloud.cfgに定義された設定でゾーンがデプロイされます。コマンド実行後は、管理サーバを再起動させ、グローバル設定を反映させるために既に動作させていたシステムVMを削除して下さい。
ステップ7をスキップして、拡張ネットワークmarvin設定の1つを使用することができます。完全な機能として、これらは各自のdevcloud上のDNSリゾルバをセットアップする必要があります。セットアップすることで、管理ネットワークは名前解決が可能となります:
devcloud上で管理サーバを実行したい場合:
次に基本セットアップで説明されているとおり管理サーバを再起動します。
Eclipseなどでインタラクティブでバッグングのためにデバッグモードで管理コンソールを動作させることができます。jettyで実行する代わりに:前章のコマンドを実行し、以下のコマンドを実行します。
host(=管理サーバIP)、system.vm.use.local.storage(=true)、適切な管理ネットワークCIDR、secondstorage.allowed.internal.sites
"tiny Linux"テンプレートが選択枝として有効でないのであれば、上記の問題が発生します。
グローバル"host"設定に誤りがあった場合は、仮想マシンのファイル/var/log/cloud/systemvm.logに以下の様なエラーが書き込まれています。
必ず次の関連パッケージをインストールしなくてはなりません:python、mysql connector for python、bash、(cygwinもしくはmsysgitで使用する)tar
もしくは、プロファイル -P developer,systemvm を使用することでスキップ可能です:-P sytemvmを使ってみて下さい。
(訳者注:えーっ!)
com.cloud.api.doc.ApiXmlDocWriter ClassNotFound:build-apidoc.shの以下の行を
Devcloudノートはいつもアラートを発生させます:git global configのautocrlfがtrueとなっていないか確認してください
デフォルトでJettyが存在しない場合、pom.xmlに以下のpluginタグを使って、mavenの処理に含めることができます:
もしmavenがpythonを発見できない理由でビルドを失敗したのであれば、
以下の方法でビルドして下さい。
--------------------
なるほど管理サーバ側は外で構築してもいいし、仮想アプライアンスの中で作ってもいい..か。
XenServer自体使ったことがないから、管理サーバ別だしでやってみるか..
にしても..
ハイパバイザ重ねがけって結局Console Proxyだめなわけね...
いろいろあって心が折れたので、
DevCloudに転がることにしました。
で、何も見ないでセットアップしたら
なにやらUbuntuがあがって..
..その次何したらいいかさっぱりわからない..
ということでCloudStackのwikiにある
DevCloudという章だけをまず読んでみようと思い
翻訳してみました。
以下翻訳した文章ですが、
参照の際はAt your own riskでお願いします。
-------
はじめに
DevCloudは、VirtualBox(オープンソースtype-2もしくはデスクトップハイパバイザ)上で動作するOVAイメージとして提供される仮想アプライアンスで、CloudStack開発やテスト用として利用することができます。オリジナルのDevCloudはRAMが2GB必要で、VirtualBoxの仮想マシンとして実行するxen.orgのXenサーバがのっているUbuntu Preciseとして動作します。
開発者はCloudStackアーティファクト(jars, wars)やファイルをDevCloudへビルド、デプロイしたり、DevCloud内部でデータベースをデプロイし管理サーバを起動することができます。開発者はDevCloud内部で動作するCloudStackを使ってDevCloudをホストとして追加することなども可能です。現在ではDevCloudは多くの方に利用されており、特にApache CloudStackの初期リリース(4.0.0-incubating)の間などにリリーステストのために利用されています。
VirtualBox/KVM/Fusion?
DevCloudはVirtualBox(やXenServer)もしくはKVMハイパバイザどちらでも使用出来ます。これらのハイパバイザのウチ1つを選択することだけ必要です、そして次に以下のVirtualBoxもしくはLinux KVMのセットアップ章に従って下さい。
XenServerをネストされたハイパバイザで動作させたい場合は、 「CloudStack 開発のために Fusion を使用した XenServer ハイパバイザ」を参照して下さい。
https://cwiki.apache.org/confluence/display/CLOUDSTACK/XenServer+Hypervisor+for+CloudStack+Development+using+Fusion
セットアップ(VirtualBox)
1. DevCloud2.0仮想アプライアンスを入手します
イメージはこのサイトに記載されたプロセスで生成されています。注意:約900MBあります。
2. VirtualBox4.2もしくは最新版をインストールします
3. 未定義の場合(もしくはVirtualBoxをインストールしたばかりの場合)は、VirtualBox上に"ホストオンリー"ネットワークを作成・設定します
3.1 ネットワークを作成するためには、VirtualBoxの「ファイル」→「環境設定」→「ネットワーク」を選びホストオンリーネットワークを追加してください(訳者注:右上の+マークの着いたNICアイコンを押す)。するとcboxnet0などのような名前で作成されます。(Windowsのみ:ホストオンリーネットワークの追加は実行しなくて構いません、3.2へ進んで下さい)3.2 3.1で作成したネットワークを設定するために、(訳者注:VirtualBox Host-Only Ethernet Adapterを)右クリックし"ホストオンリーネットワークを編集"を選択して下さい。そしけ"DHCPサーバ"タブ上の"サーバを有効化"のチェックを外して下さい。
3.3 (Windowsのみ)OSの「スタート」→「管理ツール」→「セキュリティが強化されたWindowsファイアウォール」を選択して下さい。「Windowsファイアウォールのプロパティ」(中央のパネル「概要」ブロックの一番下)をクリックし、各プロファイル(ドメイン、パブリック、プライベート)タブの状態欄にある「カスタマイズ」ボタンを押して下さい。そして「VirtualBox Host-Only Network」のチェックを外します。そうすることで、ウィンドウズファイアウォールの通信ブロックは発生しません。
4. DevCloud ova イメージをVirtualBoxへインポートします
4.1 PAEモードがアクティブであるか確認します。(VirtualBoxの)「仮想マシン」→「設定」→「システム」→「プロセッサ」タブを選択し、「PAE/NXを有効化」がチェックされていることを確認します。
(訳者注:インポートは、VirtualBoxの「ファイル」→「仮想アプライアンスのインポート」→「アプライアンスを開く」からovaイメージファイルを選択し、「次へ」→「インポート」を実行します)
5. DevCloud 仮想マシンを開始します(Windowsの場合、vboxnet0を使用していないという注意が表示されることがありますので、デフォルトのホストオンリーネットワークを使用するように編集して下さい)
6. 仮想マシンブート後、ユーザ名「root」パスワード「password」でログインします
ネットワーク
DevCloudのデフォルトIPが192.168.56.10となっています。
(複数のDevCloudを実行させたいなど)もしIPアドレスを変更したい場合は
/etc/network/interfacesを変更してリブートして下さい。
7. ラップトップ上で管理サーバを動かします:
7.1 必要な場合は、「CloudStack開発環境のセットアップ」を実行します。
7.2 最新のマスタコードをチェックアウトします
7.3 ラップトップ上で管理サーバを起動します:
mvn -P developer,systemvm clean install
mvn -P developer -pl developer,tools/devcloud -Ddeploydb
mvn -pl :cloud-client-ui jetty:run
管理サーバが起動するまで待機します。
8. (mysql-connector-pythonがインストール済みで管理サーバが作動中の)DevCloudをデプロイします
$ pip install mysql-connector-python (#marvin dependancy)
$ pip install requests (#reqd for marvin deploying the zone)
$ mvn -P developer -pl tools/devcloud -Ddeploysvr
# もしくは、上記のコマンドが動作しない場合は、
# おそらくMAVEN_OPTSを使用してmvnをデバッグモードで動かしています。
# marvinを試して下さい
$ cd tools/devcloud; python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
上記のコマンドで、いくつかのグローバル設定が登録されているtools/devcloud/devcloud.cfgに定義された設定でゾーンがデプロイされます。コマンド実行後は、管理サーバを再起動させ、グローバル設定を反映させるために既に動作させていたシステムVMを削除して下さい。
9. "ssh root@192.168.56.10"をつかってDevCloudをAll in Oneボックスソリューションとして実行することもできます
(git、java、maven、mkisofsなど)すべてのビルドツール、mysql、nfsはプリインストール、セットアップ済みです。ホストOSで管理サーバを実行する方法を推奨します。そしてIntelliJやEclipseを使ってコード実行やデバッグさせながら動かしたりDevCloudをホスト、ストレージ、ネットワークインフラとしてリプレース/代替として使用することもできます。セットアップ(Linux KVM)
1. 必要条件:KVMモジュール、libvirtユーティリティ(virsh)がインストールされたLinuxマシンを持っていること
2. ここからDevCloud KVMパッケージをダウンロードして下さい
3. devcloud.tarを展開し、自分がインストールしたい場所へ置き、DevCloudディレクトリへcdしてください
4. DevCloudが使用するネットワークを定義します(rootもしくはlibvirt特権ユーザで動作する)
virsh net-define devcloud-nat-0.xml
virsh net-define devcloud-nat-1.xml
virsh net-start devcloud-nat-0
virsh net-start devcloud-nat-1
virsh net-autostart devcloud-nat-0
virsh net-autostart devcloud-nat-1
5. devcloud.xmlを開き、qcow2ファイルのロケーションを各自のシステムに合った場所に変更して下さい
ほかにもいくつかのlibvirtのバージョンに依存する定義などを変更する必要があります。6. devcloud.xmlを定義し、仮想マシンを開始します
virsh define devcloud.xml
virsh start devcloud
7. VirtualBoxセットアップ手順のステップ6から続けて下さい
オプション:拡張ネットワークゾーン
ステップ7をスキップして、拡張ネットワークmarvin設定の1つを使用することができます。完全な機能として、これらは各自のdevcloud上のDNSリゾルバをセットアップする必要があります。セットアップすることで、管理ネットワークは名前解決が可能となります:
$ apt-get install dnsmasq
$ python tools/marvin/marvin/deployDataCenter.py -i tools/devcloud/devcloud-advanced.cfg
devcloud上で管理サーバを実行したい場合:
$ apt-get install dnsmasq
$ python tools/marvin/marvin/deployDataCenter.py -i tools/devcloud/devcloud-advanced_internal-mgt.cfg
次に基本セットアップで説明されているとおり管理サーバを再起動します。
NATネットワーキングモデルの実装であるため、VirtualBox上でこの設定(KVM内の仮想マシン以外)ではConsole proxyは動作しません。
仮想マシンが外部と通信するためにNATを使用している間は、内部のNATネットワーク上のインターフェイスを持たないためアクセスすることができません(10.0.3.2はVirtualBoxスタック内部でありホスト上にはない)。
仮想マシンがどのポートでlistenしているか知っているのであれば、devcloud上からVNCを手動で接続すさせることは可能です(e.g. 192.168.56.10:0)。ホストオンリーネットワークをパブリックとして利用することで迂回することができますが、その場合仮想マシンは物理パブリックアクセスできず、結果何がテストしたいのかということになってしまいます。
DevCloudを用いたインタラクティブデバッギング
Eclipseなどでインタラクティブでバッグングのためにデバッグモードで管理コンソールを動作させることができます。jettyで実行する代わりに:前章のコマンドを実行し、以下のコマンドを実行します。
export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n"
mvn -pl :cloud-client-ui jetty:run
export MAVEN_OPTS=""
トラブルシューティング
グローバル設定のこれらの設定知を確認する:
host(=管理サーバIP)、system.vm.use.local.storage(=true)、適切な管理ネットワークCIDR、secondstorage.allowed.internal.sites
"tiny Linux"テンプレートが選択枝として有効でないのであれば、上記の問題が発生します。
グローバル"host"設定に誤りがあった場合は、仮想マシンのファイル/var/log/cloud/systemvm.logに以下の様なエラーが書き込まれています。
2013-01-22 18:45:07,987 DEBUG [agent.transport.Request] (StatsCollector-2:null) Seq 1-1613496410: Receive
2013-01-22 18:45:11,996 INFO [utils.nio.NioClient] (Agent-Selector:) Connecting to 10.0.3.15:8250
Windowsマシン上の開発:
必ず次の関連パッケージをインストールしなくてはなりません:python、mysql connector for python、bash、(cygwinもしくはmsysgitで使用する)tar
もしくは、プロファイル -P developer,systemvm を使用することでスキップ可能です:-P sytemvmを使ってみて下さい。
もしdevcloudが起動に失敗したり、ブラックスクリーンのままであれば、BIOSのVT/VT-d(仮想化テクノロジー)を有効にする必要があります。ブート中にDeleteボタンを押しBIOS設定を変更して下さい。
ランダムなWindowsマシンにいくつかのバグが時々発生します:
(訳者注:えーっ!)
com.cloud.api.doc.ApiXmlDocWriter ClassNotFound:build-apidoc.shの以下の行を
java -cp $CP com.cloud.api.doc.ApiXmlDocWriter -d "$DISTDIR" $*次のように修正して下さい。
java -cp .$CP com.cloud.api.doc.ApiXmlDocWriter -d "$DISTDIR" $*
Devcloudノートはいつもアラートを発生させます:git global configのautocrlfがtrueとなっていないか確認してください
'-pl'(ピーエル)を'papa'、'lima'内で使用して下さい、'-p1'(ピーイチ)を使用しないで下さい
maven3を使用して下さい、古いバージョンのものは使用しないで下さい
Ubuntu上にmaven3をインストールする手順は http://superuser.com/a/298063 を参照して下さい。デフォルトでJettyが存在しない場合、pom.xmlに以下のpluginタグを使って、mavenの処理に含めることができます:
org.mortbay.jetty
maven-jetty-plugin
6.1.12
mysqlデータベースパスワードとしてNULLをセットする必要があるかもしれません
E.g. http://stackoverflow.com/questions/3032054/how-to-remove-mysql-root-password もし動作しない場合は、rootユーザのパスワードとして非NULL値に変更しファイル incubator-cloudstack/utils/db.properties.override を作成してパスワードを提供し db.root.password を更新して下さい。もしmavenがpythonを発見できない理由でビルドを失敗したのであれば、
mvn -P developer,systemvm clean installを実行した結果以下の様なエラーメッセージが表示されます。
[INFO] Apache CloudStack apidoc Tools .................... SUCCESS [41.071s]
[INFO] Apache CloudStack Developer Tools ................. SUCCESS [0.125s]
[INFO] Apache CloudStack Developer Tools: marvin ......... FAILURE [0.158s]
[INFO] Apache CloudStack Developer Tools: cloudmonkey cli SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10:28.807s
[INFO] Finished at: Tue Dec 04 17:16:54 PST 2012
[INFO] Final Memory: 34M/145M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (compile) on project cloud-marvin: Command execution failed. Cannot run program "python" (in directory "C:\src\asf-acl\incubator-cloudstack\tools\marvin\marvin"): CreateProcess error=2, The system cannot find the file specified -> [Help 1]
以下の方法でビルドして下さい。
mvn -P systemvm clean install
--------------------
なるほど管理サーバ側は外で構築してもいいし、仮想アプライアンスの中で作ってもいい..か。
XenServer自体使ったことがないから、管理サーバ別だしでやってみるか..
にしても..
ハイパバイザ重ねがけって結局Console Proxyだめなわけね...
2013年8月13日火曜日
【未解決】CloudStack上のコンソール表示しようとしたら、「~.realhostip.com のサーバからの応答が一定時間以内に返ってきませんでした」というエラーが出た
先に書きますが..まだ【未解決】です。
前の記事で書いた環境で
単一PC上にCloudStack4.1をインストールして、
いざインスタンスを立ち上げ
コンソール画面を開こうとしたら
「接続がタイムアウトしました
192-168-XXX-XXX.realhostip.com のサーバからの応答が
一定時間以内に返ってきませんでした。」
とでてきて接続できない問題が発生した。
グローバル設定の consoleproxy.url.domain に
かかれているドメイン名を使ったFQDNなのだけど、
クライアントPC上でlookupするとDHCPで割り当てられた
ルータへいってしまい誰もどこにあるかわからない。
でしらべてみると、
How to Replace realhostip.com with Your Own Domain Name
という記事に、
ゾーン内にbind9(DNS)きってローカルネット側に
192-168-XXX-YYY.realhostip.comが192.168.XXX.YYYであると
正引きできるようにすれば良いみたいなことが書かれている。
ドメイン名は上記のグローバル設定変更でかえることができる。
bind9を入れる気力がなかったので.
クライアントPCのhostsに直接書き込んで対処した。
本格的にCloudStack運用する場合はDNSサーバは必要だな..
でもそれだけじゃないな..結局のところ192.168.11.xセグメントに
192.168.11.1と192.168.11.100という2つのルータがつながっているようなもの
なので、これをなんとかするにはきちんとrouteコマンドで処理しとかないと..
routeコマンドで「192.168.11.141~160」へ通信する場合は
192.168.11.100をゲートウェイにしてねという設定を実行し無くてはならない。
で次にクライアントPC上で以下のrouteコマンドを1つづつ発行した。
そして再度管理コンソールからコンソール画面開こうとしたのだけど..
あれ?ひらかない..
CloudStack All in One サーバ(192.168.11.100)からプライベートセグメントへの
ルーティングがない..
管理サーバからは、いくつかネットワーク設定があるが
cloud0: オートナンバ用
cloudbr0: サーバのNICへつながるブリッジ
eth0: 物理的なNICをさす
virbr0: 192.168.122.1(KVMインストールするとできる)
だろうからvnet0~9があやしいのだけど..
どのネットワークがインスタンスが使用しているのかがわからないので
ルーティングしようがない..
うーん、All in Oneサーバはクライアントも兼ねないと駄目かな..
taskselしてUbuntu Desktopインストール
して管理サーバ上でブラウザあげて
そこで管理コンソールを開けるか..
前の記事で書いた環境で
単一PC上にCloudStack4.1をインストールして、
いざインスタンスを立ち上げ
コンソール画面を開こうとしたら
![]() |
| 前回の記事の環境 |
「接続がタイムアウトしました
192-168-XXX-XXX.realhostip.com のサーバからの応答が
一定時間以内に返ってきませんでした。」
とでてきて接続できない問題が発生した。
グローバル設定の consoleproxy.url.domain に
かかれているドメイン名を使ったFQDNなのだけど、
クライアントPC上でlookupするとDHCPで割り当てられた
ルータへいってしまい誰もどこにあるかわからない。
でしらべてみると、
How to Replace realhostip.com with Your Own Domain Name
という記事に、
ゾーン内にbind9(DNS)きってローカルネット側に
192-168-XXX-YYY.realhostip.comが192.168.XXX.YYYであると
正引きできるようにすれば良いみたいなことが書かれている。
ドメイン名は上記のグローバル設定変更でかえることができる。
bind9を入れる気力がなかったので.
クライアントPCのhostsに直接書き込んで対処した。
Windows7ならC:\Windows\System32\drivers\etc\hostsを
ノートパッド(管理者権限起動)で
192.168.11.141 192-168-11-141.realhostip.com
192.168.11.142 192-168-11-141.realhostip.com
~
と男らしく書いていく。
本格的にCloudStack運用する場合はDNSサーバは必要だな..
でもそれだけじゃないな..結局のところ192.168.11.xセグメントに
192.168.11.1と192.168.11.100という2つのルータがつながっているようなもの
なので、これをなんとかするにはきちんとrouteコマンドで処理しとかないと..
routeコマンドで「192.168.11.141~160」へ通信する場合は
192.168.11.100をゲートウェイにしてねという設定を実行し無くてはならない。
ルーティング変更目的でrouteコマンドをWindowsで使用する場合は、
コマンドプロンプトを管理者権限であげること。
(route PRINTでテーブルの状態見るくらいなら通常起動でもOK)
で、ここではたと気づいたのだけど、
CloudStack管理下のセグメントを着る場合はCIDR表記ができるようにしとけばよかった..
そうすればrouteコマンドでプライベートアドレス範囲はこのゲートウェイというように
綺麗に1発で指定できる。
そうしないと192.168.11.141/32から192.168.11.160/32まで2回routeコマンド打たないと
いけなくなるんじゃ..
サブネット計算苦手な人はこちらの計算サイト(IPv4)があります。
IPの範囲指定する場合はできるだけCIDRで切れる範囲を
選ぶようにしよう..
で次にクライアントPC上で以下のrouteコマンドを1つづつ発行した。
route add 192.168.XXX.YYY mask 255.255.255.255 192.168.11.100 metric 1
そして再度管理コンソールからコンソール画面開こうとしたのだけど..
あれ?ひらかない..
CloudStack All in One サーバ(192.168.11.100)からプライベートセグメントへの
ルーティングがない..
管理サーバからは、いくつかネットワーク設定があるが
cloud0: オートナンバ用
cloudbr0: サーバのNICへつながるブリッジ
eth0: 物理的なNICをさす
virbr0: 192.168.122.1(KVMインストールするとできる)
だろうからvnet0~9があやしいのだけど..
どのネットワークがインスタンスが使用しているのかがわからないので
ルーティングしようがない..
うーん、All in Oneサーバはクライアントも兼ねないと駄目かな..
taskselしてUbuntu Desktopインストール
して管理サーバ上でブラウザあげて
そこで管理コンソールを開けるか..
2013年8月12日月曜日
NIC1枚しか無い物理PCへCloudStack4.1をインストールする
やっぱり残念なので再度KVM重ねがけなしで
管理サーバ、DBサーバ、ストレージ、ホストすべて
1台の物理PCしかもNIC1枚で構築しなおしてみました。
ただ..この環境でセットアップすると
インスタンス作成まではうまくいきますが、
管理コンソール上のコンソール画面が動作しません。
All in Oneサーバ上でブラウザを開いても駄目でした。
詳細は次の記事に書いていますが..
KVM重ねがけの場合は親サーバから各セグメントが見えているので
親サーバ上のブラウザからなら問題なくコンソールは上がるのですが...
0. 用意したもの
・インターネット接続可能なセグメントに接続されたPC1台
MouseComputer
Core i7 1.2GHz×8
HDD 500GB/Mem 8GB
NIC 1枚(DHCP範囲外で固定IP割り当て、Proxyなし)
※PCによってはBIOSでIntelVTを有効化する必要がある
・Ubuntu Server 12.04.2LTS CD-ROM
・Buffalo製WZR-HP-G450H
家庭用ルータ
デフォルト設定(リセットスイッチ押下→iフィルタオフ)
LAN側:
ルータのIP192.168.11.1
DHCP有効範囲:192.168.11.2~65
※66番目以降は自由に固定IPを使える
・インターネット接続
ルータのWAN側に接続
プロクシ無しで接続できる
・クライアントPC(ルータにつながり、ブラウザが入っていればOK)
1. OSのインストール
- Ubuntu Server12.04.2LTS CD-ROMメディアを挿入し電源オン
- 日本語
- Ubuntu Serverをインストール(I)
- はい
- 日本
- 日本語
- 日本語 - 日本語(かな 86) ※各自のキーボードによる
- Alt + Shift
- 戻る ※DHCPが引けたが固定IPを振る
- ネットワークを手動で設定
- 192.168.11.100
- 255.255.255.0
- 192.168.11.1
- 192.168.11.1
- william
- royal ※ドメイン名は適当に変更すること
- cloud ※OSアカウントは適当に変更すること
- cloud ※OSアカウントは適当に変更すること
- cloud ※パスワードは適当に変更すること
- cloud
- はい
- いいえ
- はい
- ガイド - ディスク全体を使いLVMをセットアップする
- SCSI1 (0,0,0) (sda) - 500.1 GB ATA Hitachi HDS72105 ※環境による
- はい
- はい
- 499.8GB ※環境による
- はい
- いいえ
- 空欄で次へ
- 自動的にアップデートしない ※適宜変更
- 続ける
- はい
- PCからCD-ROMを取り出す
- 続ける ※再起動
- cloud ※OSアカウントは適当に変更すること
- cloud
- sudo su -
- cloud
- vi .profile
(最終行へ以下の1行を追加)
export LANG=C
- exit
- sudo su -
- cloud
- vi /etc/sysctl.conf
(最終行へ以下の2行を追加)
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
- sysctl -p
- vi /etc/apt/sources.list.d/cloudstack.list
(新規:以下の行を追加)
deb http://cloudstack.apt-get.eu/ubuntu precise 4.1
- wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
2. プライマリ/セカンダリストレージ構築
- aptitude update && aptitude -y dist-upgrade && aptitude -y install ssh openntpd nfs-kernel-server bridge-utils
- vi /etc/network/interfaces
(iface eth0 inet static以降を以下のように変更)
iface eth0 inet manual
iface cloudbr0 inet static
address 192.18.11.100
netmask 255.255.255.0
network 192.168.11.0
broadcast 192.168.11.255
gateway 192.168.11.1
dns-nameservers 192.168.11.1
dns-search royal
bridge-ports eth0
bridge-stp off
auto cloudbr0
- mkdir -p /export/primary /export/secondary
- vi /etc/exports
(最終行に以下の1行を追加)
/export *(rw,async,no_root_squash,no_subtree_check)
- exportfs -a
- vi /etc/modprobe.d/nfs_lockd.conf
(新規:以下の1行を追加)
options lockd nlm_udpport=32769 nlm_tcpport=32803
- vi /etc/default/nfs-kernel-server
(修正前)
RPCMOUNTDOPTS=--manage-gids
(修正後)
RCPMOUNTDOPTS="--port 892"
- vi /etc/default/nfs-common
(修正前)
STATDOPTS=
(修正後)
STATDOPTS="--port 662 --outgoing-port 2020"
- ufw allow 111
- ufw allow 662
- ufw allow 32769/udp
- ufw allow 32803/tcp
- ufw allow 2049
- ufw allow 892
- reboot
3. 管理サーバの構築
- cloud ※OSへログインするユーザ
- cloud
- sudo su -
- cloud ※聞かれない場合あり
- aptitude -y install mysql-server cloudstack-management
- cloud ※MySQLのrootパスワード
- cloud
- vi /etc/mysql/my.cnf
([mysqld]セクション内に以下の5行を追加)
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=350
log-bin=mysql-bin
binlog-format = 'ROW'
- service mysql restart
- cloudstack-setup-databases cloud:cloud@localhost --deploy-as=root:cloud
- cloudstack-setup-management
- mkdir -p /mnt/secondary
- mount -t nfs 192.168.11.100:/export/secondary /mnt/secondary
- mount -t nfs 192.168.0.1:/export/secondary /mnt/secondary
- /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-mount-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -F
- umount /mnt/secondary
- cd /mnt
- rmdir secondary
- reboot
4. ホストの構築
- cloud ※OSログインユーザ
- cloud
- sudo su -
- cloud ※聞かれない場合あり
- passwd root
- cloud ※OSのルートパスワードを設定
- cloud
- aptutude -y install kvm qemu-utils qemu-kvm libvirt-bin virtinst cloudstack-agent
- vi /etc/default/libvirt-bin
(修正前)
libvirtd_opts="-d"
(修正後)
libvirtd_opts="-d -l"
- vi /etc/init/libvirt-bin.conf
(修正前:11行目)
env libvirtd_opts="-d"
(修正後:11行目)
env libvirtd_opts="-d -l"
- vi /etc/libvirtd/libvirtd.conf
(以下の行をコメントアウト)
listen_tls = 0
listen_tcp = 1
tcp_port = "16509"
mdns_adv = 0
(修正前)
#auth_tcp = "sasl"
(修正後)
auth_tcp = "none"
- service libvirt-bin restart
- ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
- ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
- apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
- apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
- ufw allow proto tcp from any to any port 22
- ufw allow proto tcp from any to any port 3922
- ufw allow proto tcp from any to any port 1798
- ufw allow proto tcp from any to any port 16509
- ufw allow proto tcp from any to any port 5900:6100
- ufw allow proto tcp from any to any port 49152:49216
- ufw allow proto tcp from any to any port 9090
- ufw allow proto tcp from any to any port 8250
- ufw allow proto tcp from any to any port 8080
- vi /etc/idmapd.conf
(修正前)
#Domain = localdomain
(修正後)
Domain = royal
- vi /etc/sudores
(11行目に以下の1行を追加し強制保存)
Defaults:cloud !requiretty
- reboot
5. ゾーンの構築
※クライアントPCをルータの無線LANに接続(優先でもOK)
DHCPにより192.168.11.2~65のいずれか1つ割り当てられる
※インターネットオプションでプロクシなし設定にしておく
- ブラウザを起動
- http://192.168.11.100:8080/client を開く
- Language欄を「Japanese」に変更
- ユーザ名「admin」
- パスワード「password」
- ドメインは空欄のまま
- 「ログオン」ボタン押下
- 「CloudStackを使用したことがあるので、このガイドをスキップする」押下
- 「インフラストラクチャ」押下
- ゾーンの「すべてを表示」押下
- 「+ゾーンの追加」押下
- 「基本」をチェック
- 「Next」押下
- 名前に「zone01」と入力
- DNS1に「192.168.11.1」と入力 ※publicネットワークのDNS(NAT)として
- 内部DNS1に「192.168.11.1」と入力 ※privateネットワークのDNS(NAT)として
- ハイパーバイザを「KVM」に変更
- 「Next」押下
- 管理の「Edit」押下
- KVMトラフィックラベルに「cloudbr0」と入力 ※privateネットワーク
- 「OK」押下
- ゲストの「Edit」押下
- KVMトラフィックラベルに「cloudbr0」と入力 ※publicネットワーク
- 「OK」押下
- トラフィックの種類上の「ストレージ」アイコンをドラッグしてPhysical Network 1の破線部内へドロップ
- ストレージの「Edit」押下
- KVMトラフィックラベルに「cloudbr0」と入力 ※storageネットワーク
- 「OK」押下
- 「Next」押下
- ポッド名に「pod01」と入力 ※privateネットワークの情報を設定
- 予約済みシステムゲートウェイに「192.168.11.1」を入力
- 予約済みシステムネットマスクに「255.255.255.0」を入力
- 予約済み開始システムIPアドレスに「192.168.11.121」を入力
- 予約済み終了システムIPアドレスに「192.168.11.140」を入力
- 「Next」押下
- ゲストゲートウェイに「192.168.11.1」を入力 ※publicネットワークの情報を設定
- ゲストネットマスクに「255.255.255.0」を入力
- ゲストの開始IPアドレスに「192.168.11.141」を入力 ※非DHCPなので4より上を適当に割り当てる
- ゲストの終了IPアドレスに「192.168.11.160」を入力
- 「Next」押下
- ゲートウェイに「192.168.11.1」と入力 ※storageネットワークセグメントで記述
- ネットマスクに「255.255.255.0」と入力
- VLANは空欄のままにする
- 開始IPアドレスに「192.168.11.161」と入力
- 終了IPアドレスに「192.168.11.180」と入力
- 「追加」押下
- 「Next」押下
- クラスタ名に「cluster01」と入力
- 「Next」押下
- ホスト名に「192.168.11.100」と入力 ※privateネットワークのIPアドレス
- ユーザ名に「root」と入力
- パスワードに「cloud」と入力
- ホストタグは空欄のままにする
- 「Next」押下
- 名前に「primary01」と入力
- プロトコルは「nfs」のままにする
- サーバーに「192.168.11.100」と入力 ※本来はホストのIPアドレスをstorageネットワークアドレスで記述
- Pathに「/export/primary」と入力
- ストレージタグは空欄のままにする
- 「Next」押下
- NFSサーバーに「192.168.11.100」と入力 ※本来はホストのIPアドレスをstorageネットワークアドレスで記述
- パスに「/export/secondary」と入力
- 「Next」押下
- 「Launch zone」押下 ※時間が少し掛かる
※ゾーンを有効化するかのダイアログが表示される
- 「はい」押下
※管理コンソール画面に戻る
- 右の「インフラストラクチャ」を押下
- 「更新」を押下
- システムVMの「すべてを表示」を押下
- 2つのVMが存在し、ステータスが両方「Running」になるまで待機(結構時間がかかる)
- 画面左の「テンプレート」を押下
- 「CentOS 5.5(64-bit) no GUI (KVM)」をクリック
- 準備完了欄が「Yes」となるまで待機(すこじ時間がかかる)
6. テスト
※Ubuntu Server12.04.2LTSのISOイメージを取り込み、インスタンスを起動するところまで
6.1 ISOイメージの取り込み
※管理コンソールが立ち上がり、adminでログイン済みの状態
- 画面左の「テンプレート」を押下
- 画面上のビューの選択を「ISO」に変更
- 画面右上の「+ISOの登録」を押下
- 名前欄に「Ubuntu Server 12.04.2 LTS」と入力
- 説明欄に「Downloaded YYYY/MM/DD」と入力
- URL欄に「http://release.ubuntu.com/12.04.2/ubuntu-12.04.2-server-amd64.iso」と入力 ※むちゃくちゃ遅かったので注意
ここではUbuntuサイトを指しているので、特にグローバル設定変更は不要。
もし192.168.11.100上にApache2をインストールしてローカルのHTTPサーバ
からダウンロードしたい場合は、
「secstorage.allowed.internal.sites」にCIDR表記でIP範囲指定する。
例えば「192.168.11.0/24」とすればよい。
- ゾーンは「All Zone」のままにする
- 起動可能はチェックのままにする
- OSの種類を「Ubuntu 12.04 (64-bit)」に変更する
- 抽出可能のチェックはないままとする
- パブリックをチェックする
- おすすめをチェックする
- 「OK」押下
- 「Ubuntu Server 12.04.2 LTS」をクリックする
- 準備完了欄が「Yes」になるまで待機(更新ボタンで再表示して確認する)
6.2 インスタンス作成
- 画面左の「インスタンス」を押下する
- 画面右上の「+インスタンスの追加」を押下
- ゾーンの選択は「zone01」のままとする
- ISOまたはテンプレートの選択は「ISO」をチェック
- 「次へ」押下
- おすすめタブのUbuntu Server 12.04.2 LTSがチェックされているままとする
- Hypervisorは「KVM」のままとする
- 「次へ」押下
- 「Small Instance」をチェックしたままにする
- 「次へ」押下
- 「Small」をチェックしたままにする
- 「次へ」押下
- 「default」をチェックする
- 名前(オプション)欄に「Test」と入力する
- グループへの追加(オプション)欄を空欄のままとする
- 「VMの起動」押下
- 画面左の「インスタンス」を押下する
- 「Test」をクリックし、詳細タブの一番上にアイコン群がならぶまで待機する
- アイコン群の右端のアイコン(コンソールの表示)をクリックする
- ※UbuntuのインストーラのLanguage選択が出ればOK、あとは継続するかは適宜
以上
【注意】
最初にも書きましたが、インスタンスまでは作成されますが
コンソール画面をひらくとエラーになります。
現在調査中です。
最初、1つのLANに複数のセグメントを混ぜようかと思ったが、
KVMかさねがけによるKMのNAT設定を使ったなんちゃってルーティングがないので
同一セグメントを切り分けして設定した。
cloudbr0というブリッジを1つ作成し、
192.168.11.2~192.168.11.65はそのままルータのDHCP割り当てさせておき、
192.168.11.121~192.168.11.140 を管理ネットワーク(private)に、
192.168.11.141~192.168.11.160をゲストネットワーク(public)に、
192.168.11.161~192.168.11.180をstorageネットワークに
固定IP領域をそれぞれに割り振る。
このため3つのネットワークの
デフォルトゲートウェイは192.168.11.1、
サブネットは255.255.255.0、
DNSサーバはNATなのでルータのLAN側IPアドレス192.168.11.1を
割り当てる。
やはりSecondary Storage VMで起動停止を繰り返す問題は、
渡しの場合ufwコマンドで設定するポートが足りなかったのだと思う。
2013年8月7日水曜日
CloudStack4.1.0をNIC1枚のPC(Ubuntu Server12.04.2)へKVMかさねがけしてインストールする
物理PC(NIC1枚)上にKVMかさねがけせずにUbuntu Server12.04.2を使って、管理サーバ、DBサーバ、ストレージ、ホスト全部1台にインストールする方法はこちら。ここに記載している手順よりシンプルですが..Consoleが上がりません..
NICが1枚しか刺さっていない1台の物理PCへ、
Ubuntu12.04.2LTSを使って、
4.2がでてきそうなこの時期に
CloudStack4.1をインストールしてみた。
物理構成(用意したもの)は以下の図のとおり。
あとUbuntu Server 12.04.2 LTSをCD-ROMへ予め焼いてある状態で、
インターネット接続はproxyなしで動作する環境になっています。
先に結論を書いておきますが、
上記のスペックでKVM重ねがけ構成した場合、
親サーバ側のOSがパニックを起こしてストップするため、
実用に耐えません。
物理PC上に定義したネットワークは以下の図の通り。
KVMの親ガメ子ガメの2段構成。
管理サーバとストレージを分けたのは、
ゾーンの有効化に何度も失敗して管理サーバだけを上げ直せるように
ストレージを親ガメ側に用意しました。
ISOイメージはprivateネットワークをつかってHTTPダウンロード出来るようにしています。
#要グローバル設定変更
ネットワーク構成がこの枝とよくわからないと思うので論理構成を
別の絵にしてみました。
クライアントPCにrouteコマンド使わせるなんて
ホントは嫌だったけどしょうがない..
上記の物理構成の状態からインストルする手順をすべて
書き下したものが以下。
1. 物理マシンのセットアップ
1.1 OSのインストール
- Ubuntu Server12.04.2LTS CD-ROMメディアを挿入し電源オン
- 日本語
- Ubuntu Serverをインストール(I)
- はい
- 日本
- 日本語
- 日本語 - 日本語(かな 86) ※各自のキーボードによる
- Alt + Shift
- 戻る ※DHCPが引けたが固定IPを振る
- ネットワークを手動で設定
- 192.168.11.100
- 255.255.255.0
- 192.168.11.1
- 192.168.11.1
- william
- royal ※ドメイン名は適当に変更すること
- cloud ※OSアカウントは適当に変更すること
- cloud ※OSアカウントは適当に変更すること
- cloud ※パスワードは適当に変更すること
- cloud
- はい
- いいえ
- はい
- ガイド - ディスク全体を使いLVMをセットアップする
- SCSI1 (0,0,0) (sda) - 500.1 GB ATA Hitachi HDS72105 ※環境による
- はい
- はい
- 499.8GB ※環境による
- はい
- いいえ
- 空欄で次へ
- 自動的にアップデートしない ※適宜変更
- 続ける
- はい
- PCからCD-ROMを取り出す
- 続ける ※再起動
1.2 プライマリ/セカンダリストレージ構築
- cloud ※OSアカウントは適当に変更すること
- cloud
- sudo su -
- cloud
- vi .profile
(最終行へ以下の1行を追加)
export LANG=C
- exit
- sudo su -
- cloud
- vi /etc/sysctl.conf
(最終行へ以下の2行を追加)
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
- sysctl -p
- aptitude update && aptitude -y dist-upgrade && aptitude -y install ssh openntpd nfs-kernel-server bridge-utils kvm qemu-utils qemu-kvm libvirt-bin virtinst apache2 virt-manager
- vi /etc/network/interfaces
(iface eth0 inet static以降を以下のように変更)
iface eth0 inet manual
iface br0 inet static
address 192.18.11.100
netmask 255.255.255.0
network 192.168.11.0
broadcast 192.168.11.255
gateway 192.168.11.1
dns-nameservers 192.168.11.1
dns-search royal
bridge-ports eth0
bridge-stp off
auto br0
- vi /etc/default/libvirt-bin
(修正前)
libvirtd_opts="-d"
(修正後)
libvirtd_opts="-d -l"
- vi /etc/init/libvirt-bin.conf
(修正前:11行目)
env libvirtd_opts="-d"
(修正後:11行目)
env libvirtd_opts="-d -l"
- vi /etc/libvirtd/libvirtd.conf
(以下の行をコメントアウト)
listen_tls = 0
listen_tcp = 1
tcp_port = "16509"
mdns_adv = 0
(修正前)
#auth_tcp = "sasl"
(修正後)
auth_tcp = "none"
- service libvirt-bin restart
- ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
- ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
- apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
- apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
- ufw allow proto tcp from any to any port 22
- ufw allow proto tcp from any to any port 3922
- ufw allow proto tcp from any to any port 80
- ufw allow proto tcp from any to any port 8080
- mkdir -p /export/primary /export/secondary
- vi /etc/exports
(最終行に以下の1行を追加)
/export *(rw,async,no_root_squash,no_subtree_check)
- exportfs -a
- vi /etc/modprobe.d/nfs_lockd.conf
(新規:以下の1行を追加)
options lockd nlm_udpport=32769 nlm_tcpport=32803
- vi /etc/default/nfs-kernel-server
(修正前)
RPCMOUNTDOPTS=--manage-gids
(修正後)
RCPMOUNTDOPTS="--port 892"
- vi /etc/default/nfs-common
(修正前)
STATDOPTS=
(修正後)
STATDOPTS="--port 662 --outgoing-port 2020"
- ufw allow 111
- ufw allow 662
- ufw allow 32769/udp
- ufw allow 32803/tcp
- ufw allow 2049
- ufw allow 892
- vi /etc/idmapd.conf
(修正前)
#Domain = localdomain
(修正後)
Domain = royal
- vi /etc/hosts
(以下の様に変更・追加)
#192.168.11.100 william.royal william
192.168.100.1 william.royal william
192.168.100.2 george.royal george
192.168.100.3 catherine.royal catherine
- reboot
- cloud ※OSアカウントは適当に変更すること
- cloud
- sudo su -
- cloud ※不要な場合もあり
- ifconfig -a ※br0にIPアドレスが振られているのを確認
- tasksel
- Ubuntu desktopをチェック(スペースキー)
- OK ※結構時間が掛かる
- reboot
1.3 仮想マシン用ネットワーク設定
- cloud ※パスワードは適当に変更すること
- 画面左上2番めにあるFireFoxをクリック ※ブラウザ起動
- 検索欄に「Ubuntu Serverdownload」と入力
- 「Download Ubuntu Server | Ubuntu」をクリック
- 「Get Ubuntu 12.04 LTS」をクリック
- OK
- ※ダウンロード終了後
- 画面左上2番めにフォルダマークのアイコン(Home Folder)をクリック
- 左にある「ダウンロード」フォルダをクリック
- 「ubuntu-12.04.2-server-amd64.iso」を右クリック
- 「Move to」>「Home」を選択
- 左上のUbuntuマークのアイコン(Dash Home)をクリック
- 検索欄に「Term」と入力
- Byobu Terminalを選択 ※Terminalならなんでも可
- sudo su -
- cloud ※不要な場合もあり
- cd /var/www
- mkdir -p images
- chmod a+rwx images
- cd images
- mv ~cloud/ubuntu-12.04.2-server-amd64.iso .
- chmod a+rw ./ubuntu-12.04.2-server-amd64.iso
- ※余裕があればブラウザで「http://192.168.100.1/images/ubuntu-12.04.2-server-amd64.iso」を指定しダウンロード出来るようになっていることを確認しておく
- virt-manager & ※KVM管理コンソールが起動
- 「localhost(QEMU)」行をダブルクリック ※Connection Details画面がポップアップ
- 「Virtual Networks」タブを選択
- 左下「+」ボタン押下 ※Create a new virtual network画面がポップアップ
- 「Forward」ボタン押下
- Network Name欄に「private」と入力
- 「Forward」ボタン押下
- Network欄に「192.168.100.0/24」と入力
- 「Forward」ボタン押下
- Enable DHCPのチェックをはずす
- 「Forward」ボタン押下
- 「Forwarding to physical network」をチェック ※Modeは「NAT」のまま
- 「Forward」ボタン押下
- 「Finish」ボタン押下
- 左下「+」ボタン押下 ※Create a new virtual network画面がポップアップ
- 「Forward」ボタン押下
- Network Name欄に「public」と入力
- 「Forward」ボタン押下
- Network欄に「192.168.200.0/24」と入力
- 「Forward」ボタン押下
- Enable DHCPのチェックをはずす
- 「Forward」ボタン押下
- 「Forwarding to physical network」をチェック ※Modeは「NAT」のまま
- 「Forward」ボタン押下
- 「Finish」ボタン押下
- 左下「+」ボタン押下 ※Create a new virtual network画面がポップアップ
- 「Forward」ボタン押下
- Network Name欄に「storage」と入力
- 「Forward」ボタン押下
- Network欄に「192.168.0.0/24」と入力
- 「Forward」ボタン押下
- Enable DHCPのチェックをはずす
- 「Forward」ボタン押下
- 「Forwarding to physical network」をチェック ※Modeは「NAT」のまま
- 「Forward」ボタン押下
- 「Finish」ボタン押下
- 画面左上の「×」を押して画面を閉じる
2. 管理サーバ用仮想マシンのセットアップ
2.1 仮想マシンの構築
- ※virt-managerが上がっている状態
- 左上のアイコン(Create a new virtual machine)押下
- Name欄に「management」と入力
- 「Local install media(ISO images or CDROM)」をチェック
- 「Forward」ボタン押下
- 「Use ISO image」をチェック
- 「Browse...」ボタン押下
- 「Browse Local」ボタン押下
- Place欄の「File System」をクリック
- 「var」>「www」>「images」>「ubuntu-12.04.2-server-amd64.iso」を選択
- 「Open」ボタン押下
- OS type欄を「Linux」に変更
- Version欄を「Ubuntu 12.04 LTS (Precise Pangolin)」に変更
- 「Forward」ボタン押下
- Memory(RAM)は「1024」MBのままにする
- CPUsは「1」のままにする
- 「Forward」ボタン押下
- 「Enable storage for this virtual machine」をチェック
- 「Create a disk image on the computer's hard drive」をチェック
- 「10.0」GBへ変更
- ※管理サーバは8.0GBではインストール出来ない (セカンダリストレージのテンプレートが展開できない)
- 「Allocate entire disk now」のチェックをはずす
- 「Forward」ボタン押下
- 「Customize configuration before install」をチェック
- Advanced optionsを「Virtual network 'private':NAT」に変更
- 「Finish」ボタン押下
- ※仮想マシンがすぐに起動せずVirtual Machine画面が表示
- 「NIC:xx:xx:xx」をクリック ※xx:xx:xxは毎回変わる
- Device model欄を「e1000」に変更
- 「Apply」ボタン押下
- 「Add Hardware」ボタン押下
- 左側上の「Network」を選択
- Host device欄を「Virtual network 'public':NAT」に変更
- Device model欄を「e1000」に変更
- 「Finish」ボタン押下
- 「Add Hardware」ボタン押下
- 左側上の「Network」を選択
- Host device欄を「Virtual network 'storage':NAT」に変更
- Device model欄を「e1000」に変更
- 「Finish」ボタン押下
- 画面左上の「Begin installation」ボタン押下
- ※画面コンソールが立ち上がりOSのインストールが開始
- 日本語
- 画面コンソール上にマウスカーソルを移動しクリック ※コンソールから脱出する場合はCtl+Alt押下
- Ubuntu Serverをインストール(I)
- はい
- 日本
- 日本語
- 日本語 - 日本語 (かな86)
- Alt + Shift
- eth0: Intel Corporation 82540EM Gigabit Ethernet Controller
- 続ける
- ネットワークを手動で設定
- 192.168.100.2 ※eth0は最初に設定したprivateを割り当てたネットワーク
- 255.255.255.0
- 192.168.100.1
- 192.168.100.1 ※NAT設定しているので
- george
- royal
- cloud ※OSアカウントは適当に変更すること
- cloud ※OSアカウントは適当に変更すること
- cloud ※パスワードは適当に変更すること
- cloud
- はい
- いいえ
- はい
- ガイド - ディスク全体を使いLVMをセットアップする
- 仮想ディスク 1 (vda) - 10.7 GB Virtio Block Device
- はい
- 10.5 GB
- はい
- (空欄のまま)続ける
- 自動的にアップデートしない
- (なにも選択せずに)続ける
- はい
- 続ける ※再起動
2.2 管理サーバのセットアップ
- cloud ※OSアカウントは適当に変更すること
- cloud
- sudo su -
- cloud
- vi .profile
(最終行へ以下の1行を追加)
export LANG=C
- exit
- sudo su -
- cloud
- vi /etc/sysctl.conf
(最終行へ以下の2行を追加)
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
- sysctl -p
- vi /etc/apt/sources.list.d/cloudstack.list
(新規:以下の行を追加)
deb http://cloudstack.apt-get.eu/ubuntu precise 4.1
- wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
- aptutude update && aptitude -y dist-upgrade && aptitude -y install ssh ntp nfs-common bridge-utils mysql-server cloudstack-management
- cloud ※MySQLのrootパスワード
- cloud
- vi /etc/ntp.conf
(serverから始まる行をすべてコメントアウト)
(以下の1行を追加)
server 192.168.100.1
- service ntp restart
- vi /etc/mysql/my.cnf
([mysqld]セクション内に以下の5行を追加)
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=350
log-bin=mysql-bin
binlog-format = 'ROW'
- service mysql restart
- cloudstack-setup-databases cloud:cloud@localhost --deploy-as=root:cloud
- vi /etc/sudores
(11行目に以下の1行を追加し強制保存)
Defaults:cloud !requiretty
- vi /etc/network/interfaces
(eth0以降の設定を以下のように変更)
auto eth0
iface eth0 inet manual
iface cloudbr0 inet static
addres 192.168.100.2
netmask 255.255.255.0
network 192.168.100.0
broadcast 192.168.100.255
gateway 192.168.100.1
metric 10
dns-nameservers 192.168.100.1
dns-search royal
bridge-ports eth0
bridge-stp off
auto cloudbr0
auto eth1
iface eth1 inet manual
iface cloudbr1 inet static
addres 192.168.200.2
netmask 255.255.255.0
network 192.168.200.0
broadcast 192.168.200.255
metric 20
bridge-ports eth1
bridge-stp off
auto cloudbr1
auto eth2
iface eth2 inet manual
iface cloudbr2 inet static
addres 192.168.0.2
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
metric 30
bridge-ports eth2
bridge-stp off
auto cloudbr2
- ufw allow proto tcp from any to any port 22
- ufw allow proto tcp from any to any port 3922
- ufw allow proto tcp from any to any port 9090
- ufw allow proto tcp from any to any port 8250
- ufw allow proto tcp from any to any port 8080
- vi /etc/idmapd.conf
(修正前)
#Domain = localdomain
(修正後)
Domain = royal
- vi /etc/hosts
(以下の様に変更・追加)
192.168.100.1 william.royal william
192.168.100.2 george.royal george
192.168.100.3 catherine.royal catherine
- reboot
- cloud ※OSアカウントは適当に変更すること
- cloud
- sudo su -
- reboot ※デフォルトNICがprivateネットワークになっていない場合があるのでもう1回リブート
- cloud ※OSアカウントは適当に変更すること
- cloud
- sudo su -
- cloud ※不要な場合あり
- ping www.google.com ※pingが通らない場合はネットワーク設定に誤りあり
- ping 192.168.0.1 ※pingが通らない場合はネットワーク設定に誤りあり
- cloudstack-setup-management
- mkdir -p /mnt/secondary
- mount -t nfs 192.168.0.1:/export/secondary /mnt/secondary
- /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-mount-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -F
- umount /mnt/secondary
- cd /mnt
- rmdir secondary
- reboot
3. ホスト用仮想マシンのセットアップ
3.1 仮想マシンの構築
- ※物理マシン上にvirt-managerが上がっている状態
- 左上のアイコン(Create a new virtual machine)押下
- Name欄に「agent」と入力
- 「Local install media(ISO images or CDROM)」をチェック
- 「Forward」ボタン押下
- 「Use ISO image」をチェック
- 「Browse...」ボタン押下
- 「Browse Local」ボタン押下
- Place欄の「File System」をクリック
- 「var」>「www」>「images」>「ubuntu-12.04.2-server-amd64.iso」を選択
- 「Open」ボタン押下
- OS type欄を「Linux」に変更
- Version欄を「Ubuntu 12.04 LTS (Precise Pangolin)」に変更
- 「Forward」ボタン押下
- Memory(RAM)は「3913」MBにする ※めいいっぱいとる
- CPUsは「8」にする ※めいいっぱいとる
- 「Forward」ボタン押下
- 「Enable storage for this virtual machine」をチェック
- 「Create a disk image on the computer's hard drive」をチェック
- 「10.0」GBへ変更
- ※管理サーバは8.0GBではインストール出来ない
- (セカンダリストレージのテンプレートが展開できない)
- 「Allocate entire disk now」のチェックをはずす
- 「Forward」ボタン押下
- 「Customize configuration before install」をチェック
- Advanced optionsを「Virtual network 'private':NAT」に変更
- 「Finish」ボタン押下
- ※仮想マシンがすぐに起動せずVirtual Machine画面が表示
- 「NIC:xx:xx:xx」をクリック ※xx:xx:xxは毎回変わる
- Device model欄を「e1000」に変更
- 「Apply」ボタン押下
- 「Add Hardware」ボタン押下
- 左側上の「Network」を選択
- Host device欄を「Virtual network 'public':NAT」に変更
- Device model欄を「e1000」に変更
- 「Finish」ボタン押下
- 「Add Hardware」ボタン押下
- 左側上の「Network」を選択
- Host device欄を「Virtual network 'storage':NAT」に変更
- Device model欄を「e1000」に変更
- 「Finish」ボタン押下
- 画面左上の「Begin installation」ボタン押下
- ※画面コンソールが立ち上がりOSのインストールが開始
- 日本語
- 画面コンソール上にマウスカーソルを移動しクリック ※コンソールから脱出する場合はCtl+Alt押下
- Ubuntu Serverをインストール(I)
- はい
- 日本
- 日本語
- 日本語 - 日本語 (かな86)
- Alt + Shift
- eth0: Intel Corporation 82540EM Gigabit Ethernet Controller
- 続ける
- ネットワークを手動で設定
- 192.168.100.3 ※eth0は最初に設定したprivateを割り当てたネットワーク
- 255.255.255.0
- 192.168.100.1
- 192.168.100.1 ※NAT設定しているので
- catherine
- royal
- cloud ※OSアカウントは適当に変更すること
- cloud ※OSアカウントは適当に変更すること
- cloud ※パスワードは適当に変更すること
- cloud
- はい
- いいえ
- はい
- ガイド - ディスク全体を使いLVMをセットアップする
- 仮想ディスク 1 (vda) - 10.7 GB Virtio Block Device
- はい
- 10.5 GB
- はい
- (空欄のまま)続ける
- 自動的にアップデートしない
- (なにも選択せずに)続ける
- はい
- 続ける ※再起動
3.2 ホストのセットアップ
- cloud ※OSアカウントは適当に変更すること
- cloud
- sudo su -
- cloud
- vi .profile
(最終行へ以下の1行を追加)
export LANG=C
- exit
- sudo su -
- cloud
- vi /etc/sysctl.conf
(最終行へ以下の2行を追加)
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
- sysctl -p
- vi /etc/apt/sources.list.d/cloudstack.list
(新規:以下の行を追加)
deb http://cloudstack.apt-get.eu/ubuntu precise 4.1
- wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
- aptutude update && aptitude -y dist-upgrade && aptitude -y install ssh ntp nfs-common bridge-utils kvm qemu-utils qemu-kvm libvirt-bin virtinst cloudstack-agent
- vi /etc/default/libvirt-bin
(修正前)
libvirtd_opts="-d"
(修正後)
libvirtd_opts="-d -l"
- vi /etc/init/libvirt-bin.conf
(修正前:11行目)
env libvirtd_opts="-d"
(修正後:11行目)
env libvirtd_opts="-d -l"
- vi /etc/libvirtd/libvirtd.conf
(以下の行をコメントアウト)
listen_tls = 0
listen_tcp = 1
tcp_port = "16509"
mdns_adv = 0
(修正前)
#auth_tcp = "sasl"
(修正後)
auth_tcp = "none"
- service libvirt-bin restart
- ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
- ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
- apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
- apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
- ufw allow proto tcp from any to any port 22
- ufw allow proto tcp from any to any port 3922
- ufw allow proto tcp from any to any port 1798
- ufw allow proto tcp from any to any port 16509
- ufw allow proto tcp from any to any port 5900:6100
- ufw allow proto tcp from any to any port 49152:49216
- ufw allow proto tcp from any to any port 9090
- ufw allow proto tcp from any to any port 8250
- ufw allow proto tcp from any to any port 8080
- vi /etc/idmapd.conf
(修正前)
#Domain = localdomain
(修正後)
Domain = royal
- vi /etc/hosts
(以下の様に変更・追加)
192.168.100.1 william.royal william
192.168.100.2 george.royal george
192.168.100.3 catherine.royal catherine
- vi /etc/network/interfaces
(eth0以降の設定を以下のように変更)
auto eth0
iface eth0 inet manual
iface cloudbr0 inet static
addres 192.168.100.3
netmask 255.255.255.0
network 192.168.100.0
broadcast 192.168.100.255
gateway 192.168.100.1
metric 10
dns-nameservers 192.168.100.1
dns-search royal
bridge-ports eth0
bridge-stp off
auto cloudbr0
auto eth1
iface eth1 inet manual
iface cloudbr1 inet static
addres 192.168.200.3
netmask 255.255.255.0
network 192.168.200.0
broadcast 192.168.200.255
metric 20
bridge-ports eth1
bridge-stp off
auto cloudbr1
auto eth2
iface eth2 inet manual
iface cloudbr2 inet static
addres 192.168.0.3
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
metric 30
bridge-ports eth2
bridge-stp off
auto cloudbr2
- reboot
- cloud
- sudo su -
- cloud ※聞かれない場合あり
- passwd
- cloud ※rootのパスワード
- cloud
4. ゾーンの構築
- ※物理マシンにもどる
- 画面左上のFirefoxアイコン(Firefoxウェブブラウザ)押下
- (ブラウザが既に上がっている場合は不要)
- http://192.168.100.2:8080/client を開く
- Language欄を「Japanese」に変更
- ユーザ名「admin」
- パスワード「password」
- ドメインは空欄のまま
- 「ログオン」ボタン押下
- 「CloudStackを使用したことがあるので、このガイドをスキップする」押下
- 「インフラストラクチャ」押下
- ゾーンの「すべてを表示」押下
- 「+ゾーンの追加」押下
- 「基本」をチェック
- 「Next」押下
- 名前に「zone01」と入力
- DNS1に「192.168.200.1」と入力 ※publicネットワークのDNS(NAT)として
- 内部DNS1に「192.168.100.1」と入力 ※privateネットワークのDNS(NAT)として
- ハイパーバイザを「KVM」に変更
- 「Next」押下
- 管理の「Edit」押下
- KVMトラフィックラベルに「cloudbr0」と入力 ※privateネットワーク
- 「OK」押下
- ゲストの「Edit」押下
- KVMトラフィックラベルに「cloudbr1」と入力 ※publicネットワーク
- 「OK」押下
- トラフィックの種類上の「ストレージ」アイコンをドラッグしてPhysical Network 1の破線部内へドロップ
- ストレージの「Edit」押下
- KVMトラフィックラベルに「cloudbr2」と入力 ※storageネットワーク
- 「OK」押下
- 「Next」押下
- ポッド名に「pod01」と入力 ※podの設定ではprivateネットワークの情報を設定する
- 予約済みシステムゲートウェイに「192.168.100.1」を入力
- 予約済みシステムネットマスクに「255.255.255.0」を入力
- 予約済み開始システムIPアドレスに「192.168.100.101」を入力 ※非DHCPなので4より上を適当に割り当てる
- 予約済み終了システムIPアドレスに「192.168.100.200」を入力
- 「Next」押下
- ゲストゲートウェイに「192.168.200.1」を入力 ※ゲストなのでpublicネットワークセグメントで記述
- ゲストネットマスクに「255.255.255.0」を入力
- ゲストの開始IPアドレスに「192.168.200.101」を入力 ※非DHCPなので4より上を適当に割り当てる
- ゲストの終了IPアドレスに「192.168.200.200」を入力
- 「Next」押下
- ゲートウェイに「192.168.0.1」と入力 ※storageネットワークセグメントで記述
- ネットマスクに「255.255.255.0」と入力
- VLANは空欄のままにする
- 開始IPアドレスに「192.168.0.101」と入力
- 終了IPアドレスに「192.168.0.200」と入力
- 「追加」押下
- 「Next」押下
- クラスタ名に「cluster01」と入力
- 「Next」押下
- ホスト名に「192.168.100.3」と入力 ※ホストのIPアドレスをprivateネットワークアドレスで記述
- ユーザ名に「root」と入力
- パスワードに「cloud」と入力
- ホストタグは空欄のままにする
- 「Next」押下
- 名前に「primary01」と入力
- プロトコルは「nfs」のままにする
- サーバーに「192.168.0.1」と入力 ※物理PCのIPをstorageネットワーク指定
- Pathに「/export/primary」と入力
- ストレージタグは空欄のままにする
- 「Next」押下
- NFSサーバーに「192.168.0.1」と入力 ※物理PCのIPをstorageネットワーク指定
- パスに「/export/secondary」と入力
- 「Next」押下
- 「Launch zone」押下
- ※ゾーンを有効化するかのダイアログが表示される
- ※ここからセカンダリVMの起動失敗するケースが多いので管理サーバの/var/log/cloudstack/management/management-server.logをtail -fで見ておいたほうが良い
- 「はい」押下
- ※管理コンソール画面に戻る
- 右ではなく上の「インフラストラクチャ」を押下
- 更新を押下
- システムVMの「すべてを表示」を押下
- 2つのVMが存在し、ステータスが両方「Running」になるまで待機(結構時間がかかる)
- 画面左の「テンプレート」を押下
- 「CentOS 5.5(64-bit) no GUI (KVM)」をクリック
- 準備完了欄が「Yes」となるまで待機(すこじ時間がかかる)
5. テスト
※Ubuntu Server12.04.2LTSのISOイメージを取り込み、インスタンスを起動するところまで5.1 ISOイメージの取り込み
※管理コンソールが立ち上がり、adminでログイン済みの状態- 画面左の「グローバル設定」を押下する
- 画面右上の検索欄に「secstorage」と入力
- 名前が「secstorage.allowed.internal.sites」の操作欄のアイコンをクリック
- 値欄に「192.168.100.0/24」と入力する ※もっとサブネット絞って範囲狭めても良い
- 「OK」を押す
- 画面右上の「admin cloud」>「ログオフ」を選択
- ※管理サーバのコンソール画面へ(ログイン画面)
- cloud ※OSのユーザ名、適当に変更する
- cloud ※OSのパスワード、適当に変更する
- sudo reboot
- cloud ※聞かれない場合あり
- ※再起動されたら、画面コンソールのログイン画面へ
- ユーザ名に「admin」と入力する
- パスワードに「password」と入力する
- 「ログイン」押下
- 画面左の「テンプレート」を押下
- 画面上のビューの選択を「ISO」に変更
- 画面右上の「+ISOの登録」を押下
- 名前欄に「Ubuntu Server 12.04.2 LTS」と入力
- 説明欄に「Downloaded YYYY/MM/DD」と入力
- URL欄に「http://192.168.100.1/images/ubuntu-12.04.2-server-amd64.iso」と入力
- ゾーンは「All Zone」のままにする
- 起動可能はチェックのままにする
- OSの種類を「Ubuntu 12.04 (64-bit)」に変更する
- 抽出可能のチェックはないままとする
- パブリックをチェックする
- おすすめをチェックする
- 「OK」押下
- 「Ubuntu Server 12.04.2 LTS」をクリックする
- 準備完了欄が「Yes」になるまで待機(更新ボタンで再表示して確認する)
5.2 インスタンス作成
- 画面左の「インスタンス」を押下する
- 画面右上の「+インスタンスの追加」を押下
- ゾーンの選択は「zone01」のままとする
- ISOまたはテンプレートの選択は「ISO」をチェック
- 「次へ」押下
- おすすめタブのUbuntu Server 12.04.2 LTSがチェックされているままとする
- Hypervisorは「KVM」のままとする
- 「次へ」押下
- 「Small Instance」をチェックしたままにする
- 「次へ」押下
- 「Small」をチェックしたままにする
- 「次へ」押下
- 「default」をチェックする
- 名前(オプション)欄に「Test」と入力する
- グループへの追加(オプション)欄を空欄のままとする
- 「VMの起動」押下
- 画面左の「インスタンス」を押下する
- 「Test」をクリックし、詳細タブの一番上にアイコン群がならぶまで待機する
- アイコン群の右端のアイコン(コンソールの表示)をクリックする
- ※UbuntuのインストーラのLanguage選択が出ればOK、あとは継続するかは適宜
以上
なぜ、コンソールの表示までで止まっているのかというと、
このままUbuntuをインストールしている最中に
親ガメ(192.168.11.100)のOSがパニックを起こしてしまいました..
CloudStackを試す場合は孫ガメまで作らないといけないので
メモリのリソースが足りないのかも..
子供が管理サーバとホストの2インスタンス、
孫がSecondary StorageVM、Console ProxyVMと作成したインスタンスの3つ
仮想マシン計5個動かしてることになるから..
実用に耐えないのはわかっていたけど..
もうちょっと色々させて欲しかったなあ...
OS型でないESXiにしたほうがいいのかなあ..
登録:
投稿 (Atom)
Google Colab相当の環境をローカルPC上のDocker Composeで実現する
Docker Composeの有料版に、お金を払いたくない ^H^Hが使えない ため古いゲーミングPC(GeForce3080)にDocker Composeを入れてその上のコンテナでGoogle Colab相当のノート操作ができないかためしてみた: コンテナイメージとして a...







































