この項では、Oracle VM Managerの使用時に発生する可能性があるいくつかの問題およびその解決方法について説明します。
Oracle VM Managerのエラー・メッセージは、ユーザー・インタフェース、「Jobs」タブおよびオブジェクトの「Events」リストに表示され、さらにログ・ファイルでも確認できます。 ログ・ファイルは、Oracle VM Managerホスト・コンピュータの次のディレクトリに格納されます。
/u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/AdminServer/logs
トラブルシューティングに使用できるOracle VM Managerを次に示します。
ログ・ファイル | 説明 |
|---|---|
| Oracle VM Managerおよび基礎となるOracle WebLogic Server HTTPインタフェースのWebインタフェースへのHTTPアクセスを追跡します。 このログは、アクセス問題のデバッグおよびOracle VM Managerへのアクセスの監査を目的とする、Oracle VM Manager内のアクセスとHTTP操作の追跡に使用できます。 |
|
基礎となるOracle WebLogic Serverフレームワーク内のイベント(Oracle VM Managerによってトリガーされるイベントを含む)を追跡します。 このログは、Oracle VM Manager内の様々な問題(TLS/SSL証明書の問題、サーバーの可用性の問題、Oracle VM Manager内で実行されるすべてのアクションを含む)の追跡に使用することができ、通常、これらの問題は文字列 |
|
基礎となるOracle WebLogic Serverフレームワーク内の例外(不正な資格証明が原因のログイン障害など、Oracle VM Managerによってトリガーされる特定のイベントを含む)を追跡します。 このログは、結果として例外またはログイン障害になったOracle VM Managerの動作の追跡に対して使用でき、これらは文字列 |
ログ・ファイル形式はOracle WebLogic Serverによって決定されるため、これらのファイルの多くは読取りが困難な場合があります。 実際のログ・ファイルから役立つ情報を抽出するために、Oracle VM Managerにはログ解析ツールが含まれています。 ログ解析ツールの名前はOvmLogTool.pyであり、次の場所にあります。
/u01/app/oracle/ovm-manager-3/ovm_tools/bin
OvmLogTool.pyでは、次のことが可能です。
すべてのAdminServerログ・ファイルを、より判読性の高い1つのファイルに変換して組み合せます。
エラーのみをリストする、フィルタ処理されたサマリー・ログ・ファイルを作成します。
AdminServerログを処理し、オンザフライでフィルタ処理を適用します。
通常、ログの分析は、エラー・サマリー・ログの生成によって開始されます。 サマリー・ファイルは、フィルタ処理されたファイルの索引として機能し、エラーの調査と分析を行うことが可能であり、詳細調査が必要となる可能性のある各エラーのタイムスタンプおよび短いサマリーを提供します。 サマリー・ログ・ファイルを生成するには、次の手順を実行します。
# python OvmLogTool.py -s -o summary
processing input file: /u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/
AdminServer/logs/AdminServer.log00001
processing input file: /u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/
AdminServer/logs/AdminServer.log
これにより、summaryという名前のファイルがローカル・ディレクトリに生成されます。 これを使用して、Oracle VM Manager内で発生したエラーを検索できます。
Oracle VM Manager内のすべてのイベントおよびエラーの完全なログを取得するには、次の手順を実行します。
# python OvmLogTool.py -o filteredlog
processing input file: /u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/
AdminServer/logs/AdminServer.log00001
processing input file: /u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/
AdminServer/logs/AdminServer.log
これにより、filteredlogという名前のファイルがローカル・ディレクトリに生成されます。 これを使用して、Oracle VM Manager内で発生したすべてのイベントを検索できます。
最後に、OvmLogTool.pyを使用して、ログの処理中にオンザフライで結果をフィルタ処理できます。
# python OvmLogTool.py -t
tailing log file: /u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/
AdminServer/logs/AdminServer.logログ・ファイルの処理が完了した後、[Ctrl]を押しながら[C]を使用してプログラムを終了します。
Oracle VM Manager WebインタフェースおよびOracle VM Managerコマンドライン・インタフェースはどちらもOracle VMデータ・モデルの表現を使用して、データ・オブジェクトをより迅速に取得し、Oracle VM Managerのパフォーマンスを最適化します。 データ・モデルの表現は、プライマリOracle VM Managerデータベースとは別のデータベースに保存されます。 この別のデータベースは、Oracle VM Managerのイベントに依存して、実際のデータ・モデルとの同期を保ちます。
特定のケースでは、データ・モデルの表現が実際のデータ・モデルと同期しなくなる場合もあります。 結果として、Oracle VM Manager Webインタフェースの一部のオブジェクトには、実際の環境が反映されません。 これが起こりうる典型的なシナリオは、仮想マシンの失敗するクローン操作の操作時です。 このプロセスでは、仮想マシンは実際にはユーザー・インタフェース・レイヤーで使用されるデータ・モデル内およびデータベース内で作成されます。 操作全体の一部が失敗すると、Oracle VM Managerはクリーンアップとロールバックを試み、その結果仮想マシンはデータ・モデルから削除されます。 ただし、この場合、クリーンアップが成功したことを通知するイベントは生成されず、仮想マシン情報がユーザー・インタフェース・データベースの一部に残ります。 その結果、クローンされた仮想マシンは、実際には環境内に存在しなくても、Oracle VM Manager WebインタフェースおよびOracle VM Managerコマンドライン・インタフェースに表示されます。
サービスが再起動されるときに、ユーザー・インタフェース・データベースは自動的に再同期されません。これは大規模な環境では時間がかかる可能性があるからです。 データベースの再同期を強制するには、サービスを再起動する前にOracle VM Managerホストにファイルを作成する必要があります。 再同期を強制する方法を次の手順で示します。
Oracle VM Manager Webインタフェース・データベースを再同期するステップ
Oracle VM Managerホストのシェルに、直接またはSSHを介してアクセスする必要があります。
suを使用して、ユーザーを「oracle」ユーザーに変更します。
# su - oracle
oracleユーザーで
/tmp/.resyncUIというファイルをタッチします。$ touch /tmp/.resyncUI
oracleユーザーでこれを行うことができない場合には、別のユーザーでタッチしてください。ただし、そのユーザーの権限が、他のユーザーがそのファイルを削除できる権限であることを確認してください。
# touch /tmp/.resyncUI # chmod 666 /tmp/.resyncUI
rootでOracle VM Managerサービスを再起動します。
# service ovmm restart
何千もの仮想マシンをホストし、巨大なデータ・セットが存在する環境では、ガベージ・コレクションに時間がかかったり、メモリー不足の状態が発生したりするなど、Oracle VM Managerでパフォーマンスの問題が発生する可能性があります。 同様に、Oracle VM Managerで全体的に応答が遅くなり、パフォーマンスが大幅に低下する可能性があります。 これらのパフォーマンスの問題を解決するには、Oracle WebLogic Serverに割り当てられているメモリーの量を増やすことができます。
メモリー割当てをホスト・サーバーで使用可能な最大限度までは増やさないでください。 ガイドラインとして、ホスト・オペレーティング・システムおよびその他のサービスに対して少なくとも2GBのメモリーを空けておいてください。
Oracle WebLogic Serverに割り当てられているメモリーを増やすには、次の手順を実行します。
Oracle VM Managerのホスト・コンピュータに対するsshセッションをrootユーザーで起動します。
編集するために、
/etc/sysconfig/ovmmを開きますOracle WebLogic Serverに割り当てられているメモリー量を
JVM_MEMORY_MAXプロパティの値として指定します。ノートデフォルトは、
JVM_MEMORY_MAX=4096mです。/etc/sysconfig/ovmmを保存して閉じます。Oracle VM Managerサービスを再起動します。
# service ovmm restart
使用可能なファイル・システムが大量にあるストレージ・サーバーでは、使用可能なファイル・システムのリストのリフレッシュ中にUIがタイムアウトし、「No File Systems Available」のメッセージが表示される場合があります。 これは通常、UIがリフレッシュする必要のあるファイル・システムの数に対して、タイムアウト値の設定が低すぎることを意味します。 この問題を解決するには、Oracle VM Manager Webインタフェースで、「Tools and Resources」タブの「Preferences Pane」にある「Refresh Timeout Value」の設定を変更して、タイムアウト値を増やします。
Oracle VM ManagerのUIプリファレンスの詳細は、Oracle VM Managerオンライン・ヘルプの「プリファレンス」セクションを参照してください。
Oracle VM Managerは、証明書ベース認証を使用して、各Oracle VM Serverインスタンスで実行されるOracle VM Agentとのセキュアな通信を維持します。 つまり、Oracle VM Serverのシステム時間は、証明書の有効開始時間から有効終了時間のタイムスタンプの範囲内にある必要があります。そうでない場合、証明書の有効性が問題となり、Oracle VM ManagerはOracle VM Agentに対して認証できません。
ほとんどの場合、サーバーは所有権を得るとすぐにNTPサーバーとしてOracle VM Managerを使用するよう自動的に構成されるため、これは問題ではありません。 ただし、サーバーの検出時、Oracle VM Managerはパスワードを使用してサーバーに対して初期認証を実行し、進行中の通信に証明書を提供します。 この検出フェーズ時に、Oracle VM Serverのシステム時間が証明書認証の実行に必要な範囲内にあることを確認するためのチェックが実行されます。 システム時間が範囲内にない場合、検出は失敗し、エラー・メッセージが返されます。
OVMAPI_4024E: Cannot take ownership of server myserver5.virtlab.info because the date and time on the server are outside the valid range for the manager's SSL certificate. The certificate is valid from 10/24/13 7:37 PM to 10/25/23 7:37 PM, but server's timestamp is 9/28/13 8:14 PM. Please verify the server's NTP and time settings.
この場合、Oracle VM Managerを使用してサーバーの再検出を試みる前に、影響を受けたOracle VM Serverに直接アクセスして、システム時間を手動で更新する必要があります。 Oracle VM Managerが検出を完了し、サーバーの所有権を取得できるようになると、そのNTP構成は自動的に更新されてOracle VM Managerホストとの同期が維持されます。
すでにOCFS2ファイル・システムが含まれている記憶域デバイスにあるディスクを使用してクラスタリングされたサーバー・プールを作成しようとすると、サーバーのOracle VM Agentはファイル・システムを検出し、上書きを拒否します。 これは正常な動作で、誤って同じディスクにUUIDが一致する2つのOCFS2ファイル・システムを設定して、不安定で予期せぬ動作を引き起こしてしまうことを防ぎます。
すでにディスクに存在する既存のOCFS2ファイル・システムが、別のサーバー・プールやリポジトリで使用されていないことが確実な場合、Oracle VM Serverに接続して次のコマンドを実行することでディスクをクリーニングできます。
dd if=/dev/zero of=/dev/mapper/360a98000433468704234786f36394763 bs=1M count=256
/dev/mapper/360a98000433468704234786f36394763を、新規サーバー・プール・クラスタを作成するディスク・デバイスへの適切なパスで置き換えます。
ddを使用すると、データを破壊します。 ディスク・デバイス名に間違いがなく、削除するOCFS2ファイル・システムが使用されていないことを確認してください。 続行する前に、編集中のディスクに存在するすべてのデータのバックアップを作成することをお薦めします。 この操作は熟練したシステム管理者が実行してください。
既存のパーティションが存在する物理ディスクにリポジトリをホストすることはできません。 すでにパーティションが存在するディスクにリポジトリを作成しようとすると、バッキング・デバイスにパーティションを含むことができないことを通知するエラーが生成されます。 選択したディスクにリポジトリを作成する場合、既存のパーティションを削除する必要があります。 これにより、ディスクがマウントされているOracle VM Serverに直接アクセスし、fdiskコマンドを使用してディスク上のパーティション・オブジェクトを手動で削除する必要が生じる場合があります。 次に例を示します。
# fdisk /dev/sdb
WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
switch off the mode (command 'c') and change display units to
sectors (command 'u').
Command (m for help): p
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0001e791
Device Boot Start End Blocks Id System
/dev/sdb1 1 6528 52428800 83 Linux
Command (m for help): d
Partition number (1): 1
Command (m for help): wfdiskを使用すると、データを破壊します。 削除しようとしているディスク・デバイス名およびパーティションに間違えがないか確認します。 続行する前に、編集中のディスクに存在するすべてのデータのバックアップを作成することをお薦めします。 この操作は熟練したシステム管理者が実行してください。
通常、これらの操作を実行した後、影響を受けたOracle VM Serverを再起動することをお薦めします。 iSCSIディスクの場合、ターゲットへの接続は再度初期化する必要があります。 すべてのケースにおいて、記憶域をリフレッシュする必要があります。 Oracle VM Serverを再起動すると、すべての必要な処理が実行されます。
Oracle VM Serverの再起動後、リポジトリの再作成を試みることができます。
Oracle Linux 5ホストでOracle VM Managerを実行している場合、すべてのovm-template-configに関連するRPMパッケージを単一のコマンドで削除すると、エラーが発生し、一部のパッケージは正常に削除されません。
この問題を解決するには、次に示すように2回のyum消去操作を使用して、ovm-template-configが必ず最後に削除されるようにします。
#yum erase ovm-template-config-authentication \
ovm-template-config-datetime \
ovm-template-config-firewall \
ovm-template-config-network \
ovm-template-config-selinux \
ovm-template-config-ssh \
ovm-template-config-system \
ovm-template-config-user
#yum erase ovmd libovmapi xenstoreprovider ovm-template-config
Oracle VMリリース3.4.5以降、Oracle VM Managerは、セキュリティ上の理由から、すべての接続にTLSバージョン1.2 (TLSv1.2)プロトコルを使用します。 その結果、Release 3.2.10または3.2.11でのx86用のOracle VM Server、およびリリース3.3.1でのSPARC用のOracle VM Agentの管理は、デフォルトでは実行できません。 この問題を回避するには、TLSv1プロトコルを有効にする必要があります。
この方法の詳細は、「Oracle VMインストレーションおよびアップグレード・ガイド」の「TLSバージョン1プロトコルの有効化」を参照してください。