[[EucalyptusTroubleshooting_v1.6]]
*Eucalyptus Troubleshooting (1.6) [#eaaf158a]
*Eucalyptus トラブルシューティング (1.6) [#le35f7a3]
Eucalyptus cloud admins are encouraged to consult the Known Bugs page before diving into the investigation of unexpected behavior.~
Eucalyptus クラウドの管理者は、予想外の動作が怒ったときには、まず[[既知のバグ>EucalyptusKnownBugs_v1.6]]のページを確認するようにしてください。
The instructions below rely on the euca2ools command-line tools distributed by the Eucalyptus Team. Please, install them if you haven't done so already.~
以下の説明では、Eucalyptus チームが配布している [[euca2ools>http://open.eucalyptus.com/wiki/Euca2oolsGuide]] というコマンドライン・ツールを用います。インストールがまだであれば、これから作業をしてください。
**1. Restarting [#j33ee349]
**1. 再起動 [#q4625539]
Eucalyptus components can be restarted using the init scripts at any time with the 'restart' operation:~
Eucalyptus のコンポーネントは、init スクリプトのrestartオプションを使うことでいつでも再起動することができます。
/etc/init.d/eucalyptus-cloud restart
/etc/init.d/eucalyptus-cc restart
/etc/init.d/eucalyptus-nc restart
If you need to make a change to the cluster controller or node controller configuration through modification of $EUCALYPTUS/etc/eucalyptus/eucalyptus.conf, you will typically be required to 'stop' and then 'start' the service after the modification has been made:~
クラスタ・コントローラやノード・コントローラ上で、設定ファイル $EUCALYPTUS/etc/eucalyptus/eucalyptus.conf の変更を行った後は、設定を反映させるために、一時的にサービスを'stop'(停止)した後 'start'(起動)する必要があります。
/etc/init.d/eucalyptus-cc stop
/etc/init.d/eucalyptus-cc start
/etc/init.d/eucalyptus-nc stop
/etc/init.d/eucalyptus-nc start
Warning: depending on your configuration of Eucalyptus, making changes to eucalyptus.conf that drastically alter the way Eucalyptus is handling non-eucalyptus resources (network, hypervisor, etc) may require that all currently running VMs be terminated before the configuration changes can be successfully applied. In addition, if you are running in any network mode (VNET_MODE) other than SYSTEM, correct VM network connectivity is only ensured while the CC that launched the VMs is running. If the machine that hosts a CC that has previously launched VMs fails or reboots, then the VMs will lose network connectivity.~
'警告'：Eucalyptus の設定を eucalyptus.conf で大幅に変更する場合（ネットワーク、ハイパーバイザー等）は、設定を適用する前に、現在動作している仮想マシンすべてを停止させておく必要があります。更に、SYSTEM モード以外のネットワーク・モードで動作させている場合、現在の仮想マシンが動作しているネットワークの接続は、クラスタ・コントローラ（CC）が稼働している間だけですので、注意してください。 クラスタ・コントローラ（CC）として稼働しているマシンが故障するか、あるいは再起動してしまいますと、仮想マシンはネットワークの接続ができなくなります。
If the administrator needs to terminate running VMs for the reasons described above, they can use the client tools to terminate all instances. Optionally, the admin can manually stop all eucalyptus components, destroy all running Xen instances using 'xm shutdown' or 'xm destroy' on the nodes, and start all Eucalyptus components to return to a clean state.~
管理者は設定変更を反映させるため、稼働中の仮想マシン・インスタンスを停止する必要がある場合、クライアント・ツールを使って、すべてのインスタンスを終了することもできます。あるいは、管理者はすべての Eucalyptus コンポーネントを手動で停止させることもできます。Xen のノード上で稼働している、全インスタンスを停止するには、'xm shutdown' か 'xm desotoy' を実行します。設定を反映したクリーンな状態に復帰するには、手動で Eucalyptus コンポーネントを起動してください。
**2. Diagnostics [#d06bd0f9]
**2. 診断 [#dc5f9f4c]
***Installation/Discovering resources [#t40907ec]
***リソースの組み込みと発見 [#t29aa3a6]
If something is not working right with your Eucalyptus installation, the best first step (after making sure that you have followed the installation/configuration/networking documents faithfully) is to make sure that your cloud is up and running, that all of the components are communicating properly, and that there are resources available to run instances. After you have set up and configured Eucalyptus, set up your environment properly with your admin credentials, and use the following command to see the 'status' of your cloud:~
なぜか Eucalyptus が正常に動作しない場合、確実な第一歩は（ドキュメントを読みながら、正しくインストール・設定・ネットワークを行った後）、クラウドが確実に動作していることを確認することです。その際、すべてのコンポーネントがきちんと通信できるかどうかや、インスタンスを実行可能なリソースがあるかどうか、確認してください。Eucalyptus をセットアップ、設定し、管理者による証明書の組み込みを行った後に、以下のようにコマンドを実行してステータスを確認します。
euca-describe-availability-zones verbose
You should see output similar to the following:~
そうすると、次のような結果が表示されます。
AVAILABILITYZONE cluster <hostname of your front-end>
AVAILABILITYZONE |- vm types free / max cpu ram disk
AVAILABILITYZONE |- m1.small 0128 / 0128 1 128 10
AVAILABILITYZONE |- c1.medium 0128 / 0128 1 256 10
AVAILABILITYZONE |- m1.large 0064 / 0064 2 512 10
AVAILABILITYZONE |- m1.xlarge 0064 / 0064 2 1024 20
AVAILABILITYZONE |- c1.xlarge 0032 / 0032 4 2048 20
AVAILABILITYZONE |- <node-hostname-a> certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
AVAILABILITYZONE |- <node-hostname-b> certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
AVAILABILITYZONE |- <node-hostname-c> certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
AVAILABILITYZONE |- <node-hostname-d> certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
AVAILABILITYZONE |- <node-hostname-e> certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
AVAILABILITYZONE |- <node-hostname-f> certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
...
Next, the administrator should consult the Eucalyptus logfiles. On each machine running a Eucalyptus component, the logfiles are located in:~
次にEucalyptus のログファイルを参照します。Eucalyptus コンポーネントを動作させている各々のマシン上で、ログは次の場所にあります。
$EUCALYPTUS/var/log/eucalyptus/
On the front-end, the Cloud Controller (CLC) logs primarily to 'cloud-output.log' and 'cloud-debug.log'. Consult these files if your client tool (ec2 API tools) output contains exception messages, or if you suspect that none of your operations are ever being executed (never see Xen activity on the nodes, network configuration activity on the front-end, etc.).~
フロント・エンド上のクラウド・コントローラ（CLC）のログは、主に 'cloud-output.log' と 'cluod-debug.log' に記録されます。クライアントツール（ec2 API ツール）が例外メッセージを表示するような場合や、何もしていないのに問題が発生していると思う場合（Xen がノード上で一切動作しない場合や、フロントエンドのネットワーク設定が通らないなど）に参照してください。
The Cluster Controller (CC) also resides on the front-end, and logs to 'cc.log' and 'httpd-cc_error_log'. Consult these logfile in general, but especially if you suspect there is a problem with networking. 'cc.log' will contain log entries from the CC itself, and 'httpd-cc_error_log' will contain the STDERR/STDOUT from any external commands that the CC executes at runtime.~
クラスタ・コントローラ（CC）は、フロント・エンド上に存在しており、ログは 'cc.log' と 'httpd-cc_error_log' です。ほとんどの場合は、これらのログファイルを参照して問題解決を図ることができますが、問題はネットワークに起因している場合があります。'cc.log' にはクラスタ・コントローラ自身のログを記録します。また、'httpd-cc_error_log' には、クラスタ・コントローラ実行時のランタイムが外部コマンドとして実行する際の、標準出力(STDOUT)や標準エラー出力(STDERR) が記録されます。
A Node Controller (NC) will run on every machine in the system that you have configured to run VM instances. The NC logs to 'nc.log' and 'httpd-nc_error_log'. Consult these files in general, but especially if you believe that there is a problem with VM instances actually running (i.e., it appears as if instances are trying to run - get submitted, go into 'pending' state, then go into 'terminated' directly - but fail to stay running).~
ノード・コントローラ（NC）は、仮想マシン・インスタンスを実行するように設定されている、すべてのマシンで動作します。ネットワーク・コントローラ（NC）のログは、'nc.log' と 'httpd-nc_error_log' に記録されます。ほとんどの場合は、これらのログファイルを参照して問題解決を図ることができますが、仮想マシン・インスタンス事態の問題が原因になることがあります（例えば、インスタンスが稼働しようとしたときに、'pending'(保留)の状態から'terminated'(終了)の状態に遷移してしまったが、実際にはVMは動き続けている場合）。
***Node Controller troubleshooting [#g6a9697f]
***ノード・コントローラのトラブルシューティング [#f1d4b7e8]
-If nc.log reports "Failed to connect to hypervisor," xen/kvm + libvirt is not functioning correctly.~
nc.log に "Failed to connect to hypervisor"（ハイパーバイザーへの接続に失敗しました）と表示される場合は、Xen 又は kvm と libvirt が正常に機能していないことを示します。
-If the NC cannot be contacted, make sure that you have synchronized keys to the nodes and that the keys are owned by the user that you are running the NC as (EUCA_USER in eucalyptus.conf).~
ノード・コントローラが応答しない場合、それぞれのノード・コントローラ上の設定で、鍵が同期しており、所有者権限が設定通り（eucalyptus.conf の EUCA_USER で明示）かどうか確認してください。
***Walrus troubleshooting [#r5580801]
***Walrus のトラブルシューティング [#a6940106]
-"ec2-upload-bundle" will report a "409" error when uploading to a bucket that already exists. This is a known compatibility issue when using ec2 tools with Eucalyptus. The workaround is to use ec2-delete-bundle with the "--clear" option to delete the bundle and the bucket, before uploading to a bucket with the same name, or to use a different bucket name.~
"ec2-upload-bundle"が「409」エラーを表示したときは、既にバケットがアップロード済みの状態を指します。これはEucapyptus で EC2 ツールを使う際に発生する、互換性に関する問題です。回避するには、ec2-delete-bundle コマンドに "--clear" オプションをつけることです。そうすると、バケットをアップロードする前に、バンドル済みの同名のバケットを削除するようにできます。あるいは、違うバケット名を使ってください。
Note: If you are using Euca2ools, this is not necessary.~
メモ：[[euca2ools>Euca2oolsGuide]] を使っている場合、この作業は必要ありません。
-When using "ec2-upload-bundle," make sure that there is no "/" at the end of the bucket name.~
"ec2-upload-bunle" を使うとき、バケット名の最後に "/" はつけないでください。
***Block storage troubleshooting [#w524c7e6]
***Block Storage のトラブルシューティング [#affc8032]
-Unable to attach volumes when the front end and the NC are running on the same machine. This is a known issue with ATA over Ethernet (AoE). AoE will not export to the same machine that the server is running on. The workaround is to run the front end and the node controller on different hosts.~
フロント・エンドとノード・コントローラ(NC)が同一のマシン上で実行していると、ボリュームを仮想マシンに接続することができません。これは既知の ATA over Ethernet(AoE)に関する既知の問題です。AoE は、サーバとして動作している同じマシンにはエクスポートすることができません。回避するには、フロント・エンドとノード・コントローラを別々のホストで実行してください。
-Volume ends up in "deleted" state when created, instead of showing up as "available." Look for error messages in $EUCALYPTUS/var/log/eucalyptus/cloud-error.log. A common problem is that ATA-over-Ethernet may not be able to export the created volume (this will appear as a "Could not export..." message in cloud-error.log). Make sure that "VNET_INTERFACE" in eucalyptus.conf on the front end is correct.~
ボリューム作成時に"available(利用可能)"になるはずが、"deleted"(削除)の状態になるときがあります。$EUCALYPTUS/var/log/eucalyptus/cloud-error.log のエラーメッセージを確認してください。一般的な原因は、ATA-over-Ehternet が作成済みボリュームをエクスポートできないというものです。（"cloud not export..."というメッセージが、cloud-error.log に出力されます）。フロントエンドの eucalyptus.conf の "VNET_INTERFACE" が適切に設定されているか確認してください。
-Failure to create volume/snapshot. Make sure you have enough loopback devices. If you are installing from packages, you will get a warning. On most distributions, the loopback driver is installed as a module. The following will increase the number of loopback devices available,~
ボリュームやスナップショットの作成に失敗する場合は、十分なループバック・デバイスを持っているかどうか確認してください。もし、パッケージからインストールしている場合であれば、警告が出力されます。多くのディストリビューションでは、ループバック・デバイスはカーネルモジュールとして組み込まれています。次の設定を行う事で、利用可能なループバック・デバイスの数を増やします。
rmmod loop ; modprobe loop max_loop=256
-If block devices do not automatically appear in your VMs, make sure that you have the "udev" package installed.~
ブロックデバイスが仮想マシン上で自動的に追加されない場合は、"udev" パッケージがインストールされているかを確認します。
-If you are running gentoo and you get "which: no vblade in ((null)).", try compiling "su" without pam.~
Gentoo Linuxで動作させようとしている場合は、"which: no vblade in ((null))." と表示されるでしょう。この場合は、"su" コマンドが pam を使用しないようにコンパイルしてください。
-If you are running gentoo and you get "which: no vblade in （（null））.", try compiling "su" without pam.~
Gentoo Linuxで動作させようとしている場合は、"which: no vblade in （（null））." と表示されるでしょう。この場合は、"su" コマンドが pam を使用しないようにコンパイルしてください。
![[PukiWiki]](image/eucalyptus-j.png "[PukiWiki]")
