Builderのトラブルシューティングに関するテクニックについて説明し、トラブルシューティング項目を特定します。一般的な問題この項では、一般的な問題のトラブルシューティングについて説明します。Builderクライアントが他にないことを確認した場合、マシンでファイル・ロックが不足している可能性があります。Studioまたはabctlを使用して同時操作を実行しているときにも、このようなエラーが表示されることがあります。この問題を解決するには、ロックの解放が遅くなる環境上の問題がないかどうかをチェックしてください。homeのタイムアウトをトラブルシューティングする手順は、次のとおりです。Builderホストのファイアウォールがオフになっていることを確認します。rootとして、次のコマンドを実行します。stopマシンの再起動時に自動的に起動するようにファイアウォールが構成されている場合があります。これを回避するには、次のコマンドを実行して完全にオフにします。homeのデフォルトのタイムアウトは、15分です。root>/ovab/config/deployer/deployer.propertiesで増やすことができます。seconds>のような行を追加します。既存のアセンブリ・アーカイブ(OVAファイル)によるアセンブリの変更の妨害アセンブリ用にアセンブリ・アーカイブを作成すると、そのアセンブリはロックされます。アーカイブを削除しないかぎり、形状、プロパティ、パッケージまたはテンプレートを変更できません。name>を使用して削除できます。イントロスペクションおよびファイル・セット取得の失敗この項では、イントロスペクションおよびファイル・セット取得の問題のトラブルシューティングについて説明します。VMのイントロスペクションデプロイされた仮想マシン(VM)のイントロスペクションは、イントロスペクションに使用される一時ディレクトリがマウントされたNFS共有で、NFSファイルがロックされている場合、完了に失敗することがあります。この問題を回避するには、ロックをオフにしてNFSファイル・システムを再マウントします。name>/にコピーされます。リモート・マシンがabc12345の場合、ログは$AB_INSTANCE/logs/remote_abc12345.example.com/に格納されます。username>ですが、これは、-remoteWorkingDirフラグを使用してオーバーライドできます。リモート・マシンでipv6を実行中に発生する接続不可エラーリモート・イントロスペクション/パッケージングを実行できず、「接続できません」エラーが表示される場合、1つの可能性として、リモート・マシンでipv6を実行しているのにsshd_configファイルが正しくないことが考えられます。リモート・システムがipv6およびipv4を使用するように構成されている場合、次の行がsshd_configファイルに指定されている必要があります。パスワード入力後のリモート操作のハングリモート・パスワードの入力後にリモート操作がハングする場合、強制終了された前のリモート操作から残された孤立したリモート・プロセスによる可能性があります。リモート作業ディレクトリがリモート・プロセス下から移されると、この事象が発生する場合があります。リモート・マシンに移動して孤立したリモート・プロセスをすべて強制終了し、リモート作業ディレクトリをクリーンアップして再度リモート操作を試行してください。リモート・プロセスは、次のように表示されます。ファイル権限の問題リモート操作用に指定するリモート・ユーザーまたはsudoユーザーが参照インストールのファイルに対する読取り権限を持っていることを確認してください。リモート接続の失敗リモート操作(イントロスペクションおよびファイル・セット作成)が正常に機能するように、参照システムのSSHポート転送を有効にする必要があります。次のようにして、ssh構成ファイルをチェックします。~/.ssh/config/etc/ssh/ssh_config指定したremoteUserのシェルがログイン時にstdout/stderrに出力する場合、次のエラーが発生することがあります。sockets.リモート・ユーザーのプロファイルおよびrcファイルをチェックし、これを実行するロジックを取り除きます。別のリモート・ユーザーを指定し、sudoUserパラメータを使用して参照インストールを調査/取得する権限を持つユーザーを指定します。リモート・ファイル・セット取得の失敗リモート作業ディレクトリには、ローカル・マシンに戻される前に、ファイル・セットの格納に使用できる十分なディスク領域が必要です。テンプレート作成の失敗テンプレート作成操作が失敗した場合、次のことをチェックします。イントール時またはインストール後、$ORACLE_HOME/oracleRoot.shをrootとして実行したことを確認します。modifyjeosがインストールされていることを確認します。ovaユーティリティがインストールされていることを確認します。有効なベース・イメージ(System.img)およびvm.cfgファイルがあることを確認します。ファイル権限が正しいことを確認します。ディスク領域が不足していないことを確認します。取得するファイル・セットに対してループ・デバイス数が十分であることを確認します。D.3.1項「不十分なループ・デバイス数」を参照してください。BuilderホストのLinuxループ・デバイス数が足りないという問題が発生する場合があります。Builderおよびmodifyjeosでは、テンプレートのディスクごとに使用可能なLinuxループ・デバイスが1つ(つまり、System.imgおよびAB.imgのそれぞれに1つと、製品ディスクごとに1つ)必要です。Linuxシステムには、ループ・デバイスが7つしかありません。最大5つのファイル・セットがあるテンプレートに対してテンプレートを作成できます。ファイル・セットがそれより多いアプライアンスのテンプレートを作成するには、ループ・デバイスを追加作成する必要があります。これを実行する方法は、次のとおりです。/etc/modprobe.confを編集します。次のような行を追加します。<n>は、作成するループ・デバイスの数です。rootとして次のコマンドを実行し、Linuxカーネル・ループ・モジュールをアンロードおよびリロードします。新しいループ・デバイスが作成されたことを確認します。<n>個のループ・デバイスが見つかります。デプロイヤ通信の失敗この項では、デプロイヤ通信の失敗のトラブルシューティングについて説明します。無効なデプロイヤ・レスポンスが返される次のエラーが発生することがあります。Serverのデプロイメントをチェックし、デプロイヤ・アプリケーションの状態が「アクティブ」であり、ヘルスが「OK」であることを確認します。Serverのコンソールで次の項目をチェックします。デプロイヤに移動し、セキュリティ・モデルが「CustomRoles」であることを確認します。Adminsグループが含まれていることを確認します。Adminsグループが含まれていることを確認します。Admins」が存在し、DefaultAuthenticatorによって処理されることを確認します。[ユーザー]に移動し、「applicationAdmin」と「cloudAdmin」が存在し、DefaultAuthenticatorによって処理されることを確認します。url-patternにロール定義がないことを確認します。クライアントで接続を作成するときに、ユーザー名が手順5で示した2つのうちのいずれかであり、そのユーザーのパスワードとともに指定されていることを確認します。登録が応答なしになった場合、次のことをチェックします。Builderをバイパス)してテンプレートの登録を試みます。Serverの両方について、「スタック・スレッド最大時間」設定の増加が必要なことがあります。管理コンソールで、サーバーの「チューニング」タブを使用してこの設定にアクセスします。デプロイメントの失敗この項では、デプロイメントの失敗のトラブルシューティングについて説明します。Studioログまたはデプロイヤ・ログから失敗の原因を特定できない場合、調査を続行する必要があります。Managerコンソールにログインし、アセンブリのVMが作成および起動されているかどうかを確認します。Serverのログをチェックします。VM環境と同期しなくなる可能性があります。VM環境から実際には削除されている場合に、デプロイヤでは登録またはデプロイされていると記録されていることがあります。Builderを使用してアーカイブを登録解除およびアンデプロイしてから、もう一度登録およびデプロイする必要があります。VMが作成されたが実行されないVMが作成されたのに実行されない場合、次の手順を実行します。Serverのログをチェックします。手動によるVMの起動を試み、有効な出力が得られるかどうかを確認します。Managerコンソールから、プール内のどのマシンがVMを所有しているかを確認できます)。問題のVMのvm.cfgを探します。VMコンソールからのIDがパスに含まれています。file>コマンドを使用してVMを起動します。ディスク・イメージのマウントを試み、ログが作成されるかどうかを確認します。(これは、VMが起動した後、なんらかの理由で停止した場合が考えられます)。Linuxイメージは複数のディスクで構成されます。AB.img、System.img、Product_001.imgなど、該当するディスクをマウントする必要があります。BuilderログはAB.imgディスクにあります。VM環境に登録されると、そのイメージの名前は変わります。新しい名前になったイメージの場所を探すには、vm.cfgを見つける必要があります。IDがパスに含まれています。見つかったイメージ・ファイルへのパスを使用して、ループ・デバイスを特定します。file>前のコマンドのリスト出力から、どのループ・デバイスがディスクにマップされているかを特定できます。ディスクをマウントし、ループ・デバイスを指定します。/mnt上の最初の疑問符(?)はループ・デバイス数を表し、通常ゼロですが異なる数値でもかまいません。2番目の疑問符はパーティション番号で、通常ゼロですが異なる数値でもかまいません。/mntに移動し、ファイルを調べます。再構成がログの作成に十分である場合、AB.imgのにログは/mnt/logsにあります。次のように入力します。VMが作成および実行されたがpingできないマシンのネットワーク構成がなんらかの理由で正常に完了しませんでした。VM環境でDHCPをサポートしていることを確認します。静的IPアドレスを使用している場合は、対応するホスト名をデプロイメント・プランに指定していることも確認します。次のネットワーク関連プロパティをすべてデプロイメント・プランに指定する必要があります。pingできない実行中のVMへのアクセス方法VMにアクセスする手順は、次のとおりです。Managerコンソールから、プール内のどのマシンがVMを所有しているかを確認できます)。listコマンドを実行します。返されたリストでVMを探します。テンプレート作成時に指定したパスワード)を指定します。ネットワーク構成の失敗のトリアージ失敗をトリアージする手順は、次のとおりです。/assemblybuilder/logs下のログをチェックします。ログがない場合は、次の手順を続行します。abサービスがインストールされたかどうかを確認します。abサービスは、/etc/init.d/abにインストールされます。そこにない場合は、oraclevm-templateサービス・ログ/var/log/oraclevm-templateを調べます。oraclevm-templateサービスによって、abサービスはインストールされます。abサービスがない場合、ORACLE_HOMEのab_service.shおよびoraclevm-template.shに対する権限が正しいことを確認します。これらのファイルは、実行可能です。実行可能でない場合は、権限を修正し、アセンブリ・アーカイブを再作成してアップロードおよび登録し、デプロイを再試行します。+コマンドを実行できます。このコマンドにより、遅延バインドが出力されます。VMが作成および起動されpingできるVMが起動しpingできる場合、VMのネットワーク構成は正常に完了しました。失敗したVMにログインして、/assemblybuilder/logs下のログをチェックします。ログ・セクションで、各種ログ・ファイルの内容に関する詳細を確認します。rootユーザーおよびテンプレートの作成時に指定したパスワードを使用して、マシンへのsshを実行できる必要があります。+コマンドを実行できます。このコマンドにより、遅延バインドが出力されます。ログの場所と説明この項には、ログの場所と説明が記載されています。複数の異なるログとログの場所がありますが、これらは失敗をトリアージする時期を知るのに役立ちます。StudioログStudioログのログ・レベルは、$AB_INSTANCE/config/logging.xmlを編集して変更することができます。目的のレベルを指定して次の行を変更します。name>/にコピーされます。リモート・マシンがabc12345の場合、ログは$AB_INSTANCE/logs/remote_abc12345.example.com/に格納されます。username>ですが、これは、-remoteWorkingDirフラグを使用してオーバーライドできます。デプロイヤ・ログデプロイヤ・アプリケーション・ログ・メッセージは、デプロイヤ・アプリケーションがデプロイされたWLSのサーバー・ログまたはドメイン・ログ、あるいはその両方にあります。Serverのstdout/stderrにも関連情報やスタック・トレースが含まれることがあります。reserved.法律上の。