1つのクラスターコントローラーと3つのノードでOpenNebulaを実行しています。
フロントエンドコントローラーでノードを登録し、ノードの1つでUbuntu仮想マシンを起動できます。
ただし、ネットワークから仮想マシンにpingを実行できません。仮想マシンが正しくセットアップされているかどうかはよくわかりません。
すべてのノードには、br0
でブリッジされるeth0
インターフェースがあります。 IPアドレスは192.168.1.xの範囲にあります。
Vmnetに使用したテンプレートファイルは次のとおりです。
NAME = "VM LAN"
TYPE = RANGED
BRIDGE = br0 # Replace br0 with the bridge interface from the cluster nodes
NETWORK_ADDRESS = 192.168.1.128 # Replace with corresponding IP address
NETWORK_SIZE = 126
NETMASK = 255.255.255.0
GATEWAY = 192.168.1.1
NS = 192.168.1.1
ただし、サンストーンが仮想マシンが実行中であると述べ、onevm list
も仮想マシンが実行中であると述べているにもかかわらず、どの仮想マシンにも到達できません。
ハイパーバイザーとしてKVMを使用していることを知っておくと役立つ場合があります。また、インストール時に自動的に作成されたvirbr0インターフェイスがKVM問題になる。
私はこれと同じ問題に遭遇し、ubuntuvmbuilderを使用してセットアップしたのはVM)でした。
これをチェックしてください 完全なvmを含むイントロ 。私はこれがあなたのために働くはずだと確信しています。
これらは、とりわけ、起動時に特定のネットワークパラメータを設定するinitスクリプトを提供するため、これが問題の中心にある可能性があります。彼ら ここで文脈化でこれをより完全に説明します 。
したがって、コンテキスト化ファイルをVMにインストールするのはかなり単純な問題であることがわかります。
Vmbuilderを使用してVMを作成している場合は、インストール後のフックを使用できます(他のビルド方法にもさまざまなインストール後のフックがあると確信しています)。
コピーファイルを作成します(hostfileからguestfileへ、単一のスペースで区切られていることを確認しますか?)
copy.cfg
<path>/rc.context /etc/init.d/vmcontext
<path>/postinstall.sh /tmp/postinstall.sh
インストール後のフックを作成する
postinstall.sh
#!/bin/bash
# create mount point for context image
mkdir /mnt/context
# setup vmcontext at runlevel 2 service level 1
ln -s /etc/init.d/vmcontext /etc/rc2.d/S01vmcontext
Vmゲストにchmodするスクリプトを作成する
chvm.sh
#!/bin/bash
# vmbuilder passes vmguest root as $1
chroot $1 /tmp/postinstall.sh
最後に、VMのvmbuilderconfファイルを編集します
yourvm.cfg
...
copy = <full_path>/copy.cfg
execscript = <full_path>/chvm.sh
...
次に、vmbuilderを使用して構築します
Sudo vmbuilder kvm ubuntu -c vmbuilder.cfg
あなたの文脈にこのようなものを含めてください
GRAPHICS = [
LISTEN = 0.0.0.0,
PORT = 5900,
TYPE = vnc ]
次に、ゲストマシンネットワーク上にあるコンピューターへのsshトンネル
ssh -L 5900:127.0.0.1:5900 yourserver.com
そして、ローカルコンピュータで127.0.0.1でvncクライアントを開きます。
Nebulaはkvm/libvirtにhd */sh *でドライブを実行させることができないため、ドライブが終了する場所を試してみる必要があります(そして、これを反映するようにrcファイルを編集します)。例えば。私のUbuntuセットアップでは、qcow2イメージは/ dev/sdaを取得し、コンテキストイメージは/ dev/sr0を取得します。
また、kvmまたはnebulaのいずれかが.qcow2イメージの形式を推測できないという問題がありました。したがって、DISKにはDRIVER = qcow2を含める必要がありました。これと同じ問題がプロセッサアーキテクチャでも発生するため、OSではArch = x86_64を含める必要がありました(AMD64ゲストを実行していたため)。
幸運を
OpenNebulaを初めてセットアップするときは、VNCベースのコンソールが命の恩人です。私は他の何かを診断する前にそれを設定することを強くお勧めしますVMの状態を見ることができるのはとても便利だからですネットワーク構成が壊れています。真剣に-goを渡さないでください、$ 200を集めないでください-noVNCコンポーネントを動作させてから、他のOpenNebulaセットアップ作業に戻ってください。
実際の質問に関しては、問題はほぼ間違いなく、ネットワークコンテキスト化スクリプトなしでストックOSイメージを使用していることです。 OpenNebulaは、設計上、IPアドレスのプールを維持し、それらを「リース」していても、実際にはIPアドレスを管理しません。実際に行っているのは、MACアドレスの最後の4バイトにエンコードされた目的のIPアドレスを持つ仮想イーサネットインターフェイスにMACアドレスを割り当てることです。これを認識し、IPを適切に割り当てるのはOSの責任です。
OpenNebulaには コンテキスト化に関するいくつかのドキュメント がありますが、正直言ってそれほど良くはありません。 sample vmcontext.sh script のソースを読み取り、起動時にブートプロセスの適切なポイントでvmcontextを実行することにより、そのメカニズムを使用するようにVMをセットアップする方が簡単であることがわかりました。