第 13 章 Oracle VMのトラブルシューティング
この章では、一般的なOracle VMに関する問題のトラブルシューティング方法について説明します。
詳細およびサポート情報は、次のOracleサイトを参照してください。
-
My Oracle Support, https://support.oracle.com
-
Oracle仮想化コミュニティ、https://community.oracle.com/community/groundbreakers/server_%26_storage_systems/virtualization
-
Oracle VMデプロイメントに関するベスト・プラクティスの追加情報は、Oracle Supportに連絡してドキュメントID 1940756.1を参照してください。
13.1 Oracle VMの診断情報の取得
Oracle Support Servicesでは、スクリプトvmpinfo3.shが提供され、トラブルシューティングのためにOracle VM環境から診断情報を収集します。 このスクリプトは、Oracle VM Managerによって、次の場所にインストールされます。
/u01/app/oracle/ovm-manager-3/ovm_tools/support/vmpinfo3.sh
構文
./vmpinfo3.sh { --username=admin } [ listservers | servers= ]server1,server2,server3
オプション
|
オプション |
説明 |
|---|---|
|
{ |
スクリプトを実行するユーザーを指定します。 デフォルトOracle VM Managerユーザーの |
|
[ |
スクリプトが診断情報を収集できるすべてのサーバーをリストします。 このオプションを指定すると、スクリプトによってOracle VM Managerが所有するサーバーのリストが表示され、終了します。 診断情報を収集するには、スクリプトを再度実行する必要があります。 |
|
[ |
診断情報を収集するOracle VM Serverのインスタンスを少なくとも1つ指定します。 このオプションを使用して、ご使用の環境でサーバーを除外したり、診断の収集を特定のサーバーのみに限定したりします。 複数のサーバー名はカンマで区切ります。 ヒント Oracle VM環境全体の診断情報を収集すると、スクリプトが数分かかることがあります。 時間を節約するには、このオプションを指定して問題がある可能性のあるOracle VM Serverのインスタンスのみを含めるようにします(特に、Oracle VM Serverデプロイメントが多数ある場合)。 |
例
Oracle VM Managerおよびモデル内で所有されているすべてのOracle VM Serverを含むOracle VM環境の診断情報を収集するには、次のコマンドを実行します。
# ./vmpinfo3.sh --username=admin
診断情報を収集できるサーバーをリスト表示するには、次のコマンドを実行します。
# ./vmpinfo3.sh --username=admin listservers
特定のサーバーの診断情報のみを収集するには、次のコマンドを実行します。
# ./vmpinfo3.sh --username=admin servers=myserver1.example.com,myserver2.example.com
出力
スクリプトによって、ログ・ファイル、sosreportsおよびその他の診断情報(Oracle VMモデルの詳細など)が含まれる/tmpディレクトリにtar書庫ファイルが作成されます。
スクリプトが正常に終了すると、次の例に示すようにtar書庫ファイルのファイル名が表示されます。
======================================================================================= Please send /tmp/vmpinfo3-3.x.y.z-time_stamp.tar.gz to Oracle OVM support =======================================================================================
13.2 Oracle VM Serverのトラブルシューティング
この項では、Oracle VM Serverの使用時に発生する可能性があるいくつかの問題およびその解決方法について説明します。
Oracleサポート・サービスに問合せが必要な場合、この項で説明するログ・ファイルの提供を求められます。 各Oracle VM構成要素の正確なバージョンを提供する必要がある場合もあります。 Oracle VM Managerのバージョンを確認するには、「Help」メニューをクリックし、次に「About」をクリックします。 Oracle VM ServerおよびOracle VM Agentのバージョンを確認するには、「Oracle VM Managerユーザー・ガイド」の「制御ドメインのパースペクティブ」の項を参照してください。
13.2.1 Oracle VM Serverのデバッグ・ツール
仮想マシンの作成に失敗した場合、Oracle VM Serverのログ・ファイルを確認し、コマンドライン・ツールを使用して問題の原因を特定してください。 Oracle VM Serverの問題をトラブルシューティングする際に使用する多くの便利なコマンドライン・ツールや、確認する必要のある重要なディレクトリおよびログ・ファイルがあります。 この項では、これらのツールおよびログ・ファイルについて説明します。
13.2.1.1 Oracle VM Serverのディレクトリ
表13.1「Oracle VM Serverのディレクトリ」に、Oracle VM Serverの問題をトラブルシューティングする際に確認する必要がある重要なOracle VM Serverのディレクトリを示します。
|
ディレクトリ |
用途 |
|---|---|
|
|
Oracle VM Serverデーモンと仮想化ゲストのOracle VM Server構成ファイルを含みます。 |
|
|
ネットワーク関連スクリプトを含みます。 |
|
|
次のファイルを含む:
|
|
|
Oracle VM Serverのログ・ファイルを含みます。 |
13.2.1.2 Oracle VM Serverのログ・ファイル
次の表に、Oracle VM Serverの問題をトラブルシューティングする際に確認する必要があるOracle VM Serverのログ・ファイルを示します。
|
ログ・ファイル |
ディレクトリ |
説明 |
|---|---|---|
|
|
|
Oracle VM Serverデーモンのすべてのアクションのログを含みます。 アクションは、通常の条件またはエラー条件です。 このログ・ファイルには、xm logコマンドによる出力と同じ情報を含みます。 |
|
|
|
Oracle VM Serverデーモンのアクションの詳細ログを含みます。 |
|
|
|
ホットプラグ・イベントのログを含みます。 デバイスまたはネットワーク・スクリプトが起動しない、または使用できない場合、ホットプラグ・イベントがログに記録されます。 |
|
|
|
各ハードウェア仮想化ゲストのログを含みます。 このログは、quemu-dmプロセスによって作成されます。 psコマンドを使用してpid(プロセス識別子)を検索し、これをファイル名に置き換えます。 |
|
|
|
Oracle VM Agentのログを含みます。 |
|
|
|
Oracle VM Storage Connectプラグインのログを含みます。 |
|
|
|
Oracle VM仮想マシン・コンソールのログを含みます。 |
|
|
|
Oracle VM監視デーモンのログを含みます。 |
13.2.1.3 Oracle VM Serverのコマンドライン・ツール
次の表は、Oracle VM Serverの問題をトラブルシューティングする際に使用できるコマンドライン・ツールを示します。
これらのコマンドライン・ツールはXen環境の一部として組み込まれています。 これらの使用方法の詳細は、該当するXenドキュメントを参照してください。
|
コマンドライン・ツール |
説明 |
|---|---|
|
xentop |
Oracle VM Serverおよびドメインのリアルタイム情報を表示します。 |
|
xm dmesg |
ハイパーバイザのログ情報を表示します。 |
|
xm log |
Oracle VM Serverデーモンのログ情報を表示します。 |
13.2.2 Oracle VM ServerでのDHCPの使用
Oracle VM Serverは、静的IPアドレスのコンピュータにインストールすることをお薦めします。 ご使用の環境でDHCPを使用してIPアドレス領域を管理するには、DHCPサーバーはサーバー・インタフェースのMACアドレスを特定のIP割当てにマップするように構成してください。 これによって、ホストは常に同じIPアドレスを受信できます。 DHCPのリース期間によってIPアドレスが変わる可能性のある環境で使用すると、Oracle VM Serverホストの動作が不確定になります。
13.2.3 Dom0コンソールに接続時に特定のキーの組合せが使用できない
一部のサーバー・モデルと一部のクライアント端末は、特殊なキーの組合せに関して理論的には互換性がありません。 たとえば、HP DL380G4 (BIOS P51)サーバーなどの一部のHPサーバーでは、ログイン画面に切り替えるために必要な[Alt]-[F2]キーの組合せが、すべての端末クライアントで機能するわけではありません。 一部の端末クライアントでは別のキー・マッピングを使用するため、代わりのマッピングを使用できるかどうか、選択した端末クライアントのドキュメントを確認することをお薦めします。
Windows PuTTY SSHクライアントを使用している場合、[Alt] + 右矢印キーおよび[Alt] + 左矢印キーを押して、記載されている[Alt]-[F2]ではなくログイン画面に切り替えます。
13.2.4 Oracle VM Serverでのストレージ・アレイのLUN再マッピング
ストレージ・アレイのLUN再マッピングは、Oracle VM Serverではサポートされていません。 Oracle VM Serverは、同じLUN IDを使用してストレージ・アレイの論理ドライブに対する接続を維持する必要があります。 LUNが再マップされると、次のエラーがOracle VM Serverのメッセージ・ログに出力される可能性があります。
Warning! Received an indication that the LUN assignments on this target have changed. The Linux SCSI layer does not automatically remap LUN assignments.
この問題を解決するには、次の操作を実行します。
-
ファイバ・チャネル・ストレージの場合、Oracle VM Serverを再起動します。 新しいストレージ・アレイLUN IDが使用されます。
-
iSCSI記憶域の場合、次の例に示すように、Oracle VM Serverでiscsiデーモンを再起動し、すべてのiSCSIターゲット接続を削除およびリストアします。
# service iscsi restart
または、Oracle VM Serverにおいて、次の例に示すように、LUN IDが変更されたターゲットに対してログアウトしてから再度ログインします。
# iscsiadm --mode node --logout
ip_addressiqn.xyz:1535.uuid# iscsiadm --mode node --loginip_addressiqn.xyz:1535.uuid
13.2.5 Oracle VM ServerでのISCSI設定のチューニング
場合によっては、特定のISCSI実装で制限またはバグに遭遇する可能性があり、それによりOracle VM Serverごとにストレージ・イニシエータのISCSI設定のチューニングが必要となることがあります。
通常、LUNでIOロックが発生し、Oracle VM Server上でカーネル・ワークロードに対する予期しない変更があった場合にこうしたことが必要になります。 Oracle VM Serverとストレージ・アレイとの間のネットワーク・トラフィックが大幅に増加していることにも気づく可能性があります。 この特定のケースは、Oracle Solaris 11で実行されているZFSアプライアンスで発生することがわかっており、Sun iSCSI COMSTARポート・プロバイダに関連しています。 この問題は、通常、パッケージのバージョンを更新することで解決できますが、バージョンの更新が選択肢にない場合には、SUN.COMSTARターゲットと通信する各Oracle VM ServerのISCSI設定をチューニングすることでフロー・コントロールを有効にできます。
ISCSIをチューニングするには、各Oracle VM Serverで次のステップを実行します。
-
テキスト・エディタで
/etc/iscsi/iscsid.confを開きます。 -
iSCSI settingsというセクションを検索します。 -
エントリ
node.session.iscsi.InitialR2Tの値をyesに変更し、エントリnode.session.iscsi.ImmediateDataの値をnoに変更します。 -
ファイルを保存します。
-
次のコマンドを実行してISCSIデーモンを再起動します。
# service iscsid restart
この問題に対するお薦めの解決策は、ソフトウェアを更新することです。 Oracle VM Server設定の手動構成は、今後の更新で変更内容が失われる可能性があるため一般的にはお薦めできません。
13.2.6 クラスタリングされたサーバー・プールのOracle VM Server for x86のトラブルシューティング
サーバー・プールからOracle VM Serverを削除すると、エラーが発生する場合があります。 典型的な例は、OCFS2ベース・リポジトリがサーバー・プールから削除しようとした時点でもまだOracle VM Serverに提示されている場合、またはOracle VM Serverがサーバー・プール・ファイル・システムに対するアクセス権を失ったり、そのOracle VM Serverに対するハートビート機能が失敗したりしている場合です。 次のリストは、このような状況に対処するステップを説明します。
-
サーバー・プールからリポジトリを削除する際に、サーバーに提示されているリポジトリが存在しないことを確認します。 これが問題の原因である場合には、通常、表示されるエラーにOCFS2ファイル・システムがまだ存在していることが示されます。 詳細は、Oracle VM Managerオンライン・ヘルプの「リポジトリの観点」セクションを参照してください。
-
プール・ファイル・システムが原因で削除操作が失敗する場合は、アンマウント時にプール・ファイル・システムで他のプロセスが動作していた可能性があります。 後でOracle VM Serverの削除を試行してください。
-
新しくインストールされたOracle VM Managerのインスタンスにあるクラスタリングされたサーバー・プールからサーバーを削除しようとすると、ご使用の環境でサーバー・プールが検出されて以降ファイル・サーバーがリフレッシュされていない可能性があります。 Oracle VM Serverを削除する前に、記憶域上で、すべての記憶域とすべてのファイル・システムをリフレッシュしてみてください。
-
サーバーが残りのサーバー・プールまたはサーバー・プール・ファイル・システムのある記憶域とのネットワーク接続を失ったためにOracle VM Serverをサーバー・プールから削除できない場合、通常、疑いのあるサーバーに対して重大なイベントが生成されます。 疑いのあるOracle VM Serverに対して生成された重大なイベントを確認してください。 詳細は、Oracle VM Managerオンライン・ヘルプの「イベントの観点」セクションを参照してください。 これらのイベントが確認されれば、再度サーバー・プールからサーバーを削除してみることができます。 ほとんどの場合、重大なイベントを確認した後にはサーバー・プールからのサーバーの削除は正常に行われますが、削除プロセス中にいくつかの警告が生成される場合があります。 サーバーがサーバー・プールから削除されたら、サーバーで発生している可能性のあるネットワークまたはストレージのアクセスの問題を解決する必要があります。
-
サーバーにまだ記憶域へのアクセスの問題があり、すべての重大なイベントが確認されてもまだサーバー・プールから削除できない場合、サーバーを再起動してクラスタに正しく再結合できるようにしてから再度削除してみてください。
-
サーバー・プールのファイル・システムがなんらかの理由で壊れた場合、または古くなったクラスタの残骸がサーバーに残っている場合、サーバー・プールを完全に消去して最初から再構築する必要があります。 これには、通常、クラスタ内の各Oracle VM Serverで一連の手動ステップを実行する必要があり、これはOracle Supportの支援のもとに実行する必要があります。
13.2.7 複数のインフィニバンドHCAのメモリーの割当て
Oracle VM Serverの準仮想化環境用のPCIe Scalable Interface (psif)ドライバで複数のInfinibandホスト・チャネル・アダプタ(HCA)を使用すると、メモリー不足のエラーが発生することがあります。 こうしたメモリー不足のエラーは、psifドライバが各インタフェース・インスタンスのメモリー50MBに加えて、ドライバ自体に最小30MBのメモリーを必要とするために発生します。 dom0のデフォルトのメモリー割当てでは、複数のインタフェースをサポートするのに十分なメモリーがありません。
メモリー不足のエラーを解決するには、Oracle VM Serverのdom0メモリー割当てを増やしてください。 1.6項「管理ドメインのメモリー・サイズの変更」を参照してください。
/var/log/messagesに記載されている、メモリー不足の例を次に示します。
time_stamphostnamekernel: [ 1465.466059] Out of memory: Kill process 8106 (python) score 0 or sacrifice child Connection tohostnameclosed.l: [ 1465.466089] Killed process 8467 (ovs-agent) total-vm:108488kB, anon-rss:12kB, file-rss:2064kB
13.2.8 NICがDHCP用に構成されている場合にIPアドレスの取得に失敗する問題の解決
場合によっては、DHCPを通じてIPアドレスを取得するようにOracle VM Serverのネットワーク・インタフェースを構成してから、そのインタフェースを起動すると、IPアドレスを取得できず、次に示すエラーが発生します。
Determining IP information for interface_name...
failed; no link present. Check cable?
この問題は、ネットワーク・インタフェースの起動にかかる時間が、LINKDELAY環境変数に設定された時間よりも長い場合に発生する可能性があります。
この問題を解決するには、次の例に示すように、/etc/sysconfig/network-scripts/ifcfg-eth*ファイルでLINKDELAYの値を10以上に設定します。
DEVICE=eth3 BOOTPROTO=dhcp HWADDR=00:00:00:00:00:00 ONBOOT=yes LINKDELAY=10
13.3 Oracle VM Managerのトラブルシューティング
この項では、Oracle VM Managerの使用時に発生する可能性があるいくつかの問題およびその解決方法について説明します。
13.3.1 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]を使用してプログラムを終了します。
13.3.2 Oracle VM Manager Webインタフェース・データベース同期
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ホストのシェルに、直接または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
13.3.3 Oracle WebLogic Serverに割り当てられたメモリーの増加
何千もの仮想マシンをホストし、巨大なデータ・セットが存在する環境では、ガベージ・コレクションに時間がかかったり、メモリー不足の状態が発生したりするなど、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
13.3.4 ストレージ・サーバーの検索時にファイル・システムが見つからない
使用可能なファイル・システムが大量にあるストレージ・サーバーでは、使用可能なファイル・システムのリストのリフレッシュ中に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オンライン・ヘルプの「プリファレンス」セクションを参照してください。
13.3.5 時間差が原因で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ホストとの同期が維持されます。
13.3.6 クラスタリングされたサーバー・プールをすでにOCFS2ファイル・システムがあるディスクに作成できない
すでに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ファイル・システムが使用されていないことを確認してください。 続行する前に、編集中のディスクに存在するすべてのデータのバックアップを作成することをお薦めします。 この操作は熟練したシステム管理者が実行してください。
13.3.7 パーティションがあるデバイスにリポジトリを作成できない
既存のパーティションが存在する物理ディスクにリポジトリをホストすることはできません。 すでにパーティションが存在するディスクにリポジトリを作成しようとすると、バッキング・デバイスにパーティションを含むことができないことを通知するエラーが生成されます。 選択したディスクにリポジトリを作成する場合、既存のパーティションを削除する必要があります。 これにより、ディスクがマウントされている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): w
fdiskを使用すると、データを破壊します。 削除しようとしているディスク・デバイス名およびパーティションに間違えがないか確認します。 続行する前に、編集中のディスクに存在するすべてのデータのバックアップを作成することをお薦めします。 この操作は熟練したシステム管理者が実行してください。
通常、これらの操作を実行した後、影響を受けたOracle VM Serverを再起動することをお薦めします。 iSCSIディスクの場合、ターゲットへの接続は再度初期化する必要があります。 すべてのケースにおいて、記憶域をリフレッシュする必要があります。 Oracle VM Serverを再起動すると、すべての必要な処理が実行されます。
Oracle VM Serverの再起動後、リポジトリの再作成を試みることができます。
13.3.8 Oracle Linux 5ホストでのOracle VMテンプレート構成パッケージの削除
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
13.3.9 リリース3.2.10または3.2.11でOracle VM Server for x86を管理できず、リリース3.3.1でOracle VM Agent for SPARCを管理できない
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プロトコルの有効化」を参照してください。
13.4 仮想マシンのトラブルシューティング
この項では、仮想マシンを作成または使用する際に発生する可能性のある既知の問題とその解決方法について説明します。
13.4.1 ゲストのクロックの設定
PVMゲストが、NTPD(ネットワーク・タイム・プロトコル・デーモン)などを使用して、固有のシステム・クロック管理を実行するか、または、ハイパーバイザが、すべてのゲストのシステム・クロック管理を実行します。
/etc/sysctl.confファイルのxen.independent_wallclockパラメータを1に設定すると、固有のシステム・クロックを管理するために準仮想化ゲストを設定できます。 次に例を示します。
"xen.independent_wallclock = 1"
ハイパーバイザを設定して準仮想化ゲストのシステム・クロックを管理する場合、xen.independent_wallclockを0に設定します。 ゲストの時間の設定または変更の処理は失敗します。
/procファイルの設定を一時的に変更できます。 次に例を示します。
"echo 1 > /proc/sys/xen/independent_wallclock"
この設定は、ハードウェア仮想化ゲストに適用されません。
13.4.2 wallclock時刻のずれの問題
ゲストのインストール後に特定のオペレーティング・システム・バリアントのブート・ローダー(grub.conf)構成ファイルに追加のパラメータが必要になる場合があります。 特に、最適かつ正確なクロックには、Linuxゲスト・ブート・パラメータを指定して、pitクロック・ソースを使用する必要があります。 ほとんどのゲストにclock=pit nohpet nopmtimerを追加することで、ゲストのクロック・ソースとしてpitが選択されます。 Oracle VM用に公開されているテンプレートには、これらの追加パラメータが含まれます。
仮想時間を正確に保守することは困難です。 様々なパラメータが仮想時間の管理と補完のチューニングを行いますが、ゲスト内で実行されるntp時間サービスの代わりにはなりません。 ntpdサービスが実行され、/etc/ntp.conf構成ファイルが有効な時間サーバーを示していることを確認してください。
13.4.3 マウス・ポインタ追跡の問題
マウス・ポインタがハードウェア仮想化ゲストのVNC Viewerセッションのカーソルを追跡しない場合、次の行を/etc/xen/xend-config.sxpのOracle VM Server構成ファイルに追加して、デバイス・モデルで絶対(タブレット)座標が使用されるようにします。
usbdevice='tablet'
変更を有効にするには、Oracle VM Serverを再起動します。 サーバー・プールのOracle VM Serverごとに、これを実行する必要があります。
13.4.4 Oracle VM 2.xテンプレートからの仮想マシンのクローニングが保留中のままである
Oracle VM 2.xテンプレートから仮想マシンを作成する場合、クローン・ジョブは失敗し、次のエラーが表示されます。
OVMAPI_9039E Cannot place clone VM:template_name.tgz, in Server Pool: server-pool-uuid. That server pool has no servers that can run the VM.
これは、仮想マシンの構成ファイルのvif = ['bridge=xenbr0']エントリとのネットワーク構成の不一致が原因です。
この問題を解決するには、仮想マシン・テンプレートの既存のネットワークをすべて削除し、仮想マシン・ロールを持つ有効なネットワークで置換します。 クローン・ジョブを開始すると、仮想マシン・クローンが作成されます。 または、テンプレートの既存のネットワークをすべて削除し、クローン・ジョブを再開し、クローン・ジョブの完了後に任意のネットワークに追加します。
13.4.5 ハードウェア仮想化ゲストの停止
ハードウェア仮想化ゲストを実行すると、QEMUプロセス(qemu-dm)のメモリー使用量が特に負荷の高いI/Oで大幅に増加する可能性があります。 このため、メモリーが不足してハードウェア仮想化ゲストが停止する場合があります。 ゲストが停止した場合は、dom0のメモリーの割当てを(たとえば、512MBから768MBに)増加します。 dom0メモリーの割当ての変更方法の詳細は、1.6項「管理ドメインのメモリー・サイズの変更」を参照してください。
13.4.6 仮想マシンの移行
同等ではないハードウェアを使用するコンピュータの仮想マシンは移行できません。 仮想マシンを移行するには、同じ型および同じモデルのハードウェアおよび同じCPUファミリのCPUを使用する必要があります。
仮想マシンは、同じリリース以降のOracle VM Serverのインスタンス間でライブ・マイグレーションを実行できます。 x86プラットフォームで実行される仮想マシンについては、仮想マシンが実行されているOracle VM Serverより前のリリースのOracle VM Serverに仮想マシンをライブ・マイグレーションしようとするとルール例外が生成されます。
13.4.7 失敗したローカル仮想マシン移行からのリカバリ
ローカル・リポジトリでホストされている仮想マシンがライブ・マイグレーションされるイベントで、移行中に移行元または移行先のOracle VM Serverが使用できなくなると、Oracle VM Managerは操作のロールバックを試みます。 このロールバック・プロセスにより、移行元Oracle VM Serverの仮想マシンの元のバージョンがオンラインに戻され、再度使用できるようになると移行先Oracle VM Serverでクリーンアップ操作が実行されます。 このクリーンアップ・プロセスには、移行先Oracle VM Serverにコピーされた一時停止中の仮想マシンを強制停止させてから、仮想ディスク、仮想マシン構成および一時ファイルの移行先リポジトリをクリーンアップします。 最後に、移行元サーバーのリポジトリでリポジトリ・リフレッシュが実行され、すべてが順調であることが保証されます。
クリーンアップ操作がトリガーされる前に、移行ジョブが失敗したか停止したことを示し、ロールバック・プロセスを追跡するためのイベントがOracle VM Manager内に作成されます。 Oracle VM Manager内でイベントが生成されると、「WARNING」ステータスが設定されます。 ロールバック・プロセスは、最大3つの異なるジョブのセットとして生成されます。それぞれジョブには、タイムアウト時間が15分に指定され、10秒ごとに実行を試みます。 これらのジョブが成功すると、Oracle VM Managerはイベントを確認します。 ジョブがすべてタイムアウトした場合でも、Oracle VM Managerはイベントを確認しますが、ロールバックが失敗したことを示す「WARNING」ステータスの2番目のユーザー確認可能なイベントが作成されます。 ロールバック失敗の原因に応じて、Oracle VM Managerは「CRITICAL」ステータスのユーザー確認可能なイベントを作成することもあります。
通常、ジョブは順番に実行されるため、ロールバック・プロセス全体がタイムアウトしてロールバック失敗を示す新しいイベントが生成されるまでに合計45分かかる場合があります。 ロールバック失敗のイベントは、Oracle VM Managerホストのログ・ファイル/u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/AdminServer/logs/AdminServer.logにも記録されます。
ロールバック失敗のイベントの情報には、失敗した仮想マシンの移行をクリーンアップするためにOracle VM Managerが実行しようとしたロールバック・プランが含まれます。 このイベントは、Oracle VM Manager Webインタフェース内またはOracle VM Web Services APIを使用して仮想マシンに関連づけられたイベントを表示することで、Oracle VM Managerコマンドライン・インタフェースでgetEventsForObjectコマンドを使用して表示できます。
次のコンテンツは、ロールバック失敗イベントの説明フィールドに表示される典型的な出力を表します。
Live VM Migration With Storage, started at 2015-11-04 09:51:13,205
VM: [VirtualMachineDbImpl] 0004fb0000060000c71d489702c240b3<978> (MyVM)
Source server: [ServerDbImpl] 30:30:38:37:30:32:58:4d:51:34:35:30:30:37:4c:52<386> (ovs216)
Target server: [ServerDbImpl] 30:30:38:37:30:32:58:4d:51:34:35:30:30:38:58:42<238> (ovs215)
Source repository: [RepositoryDbImpl] 0004fb0000030000c4fca9a963e2706c<479> (r216)
Target repository: [RepositoryDbImpl] 0004fb0000030000f9ba13d5063e330a<382> (r215)
Source vDisks to be migrated:
/OVS/Repositories/0004fb0000030000c4fca9a963e2706c/VirtualDisks/
0004fb000012000005213553a5bba24f.img
Migration job has failed or was aborted.
VM's server has been set back to: (ovs216)
Source vDisk files have been retained.
Constructed the following post-migration completion plan at 2015-11-04 09:51:36,686
VM to be killed on server: (ovs215)
To be deleted on target server (ovs215):
vDisk: /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualDisks/
0004fb000012000005213553a5bba24f.img
tmp file: /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualDisks/
tmp_dest.0004fb000012000005213553a5bba24f.img
Also to be deleted on target server (ovs215):
cfg file: /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualMachines/
0004fb0000060000c71d489702c240b3/vm.cfg
directory: /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualMachines/
0004fb0000060000c71d489702c240b3
tmp file: /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualMachines/
tmp_dest.0004fb0000060000c71d489702c240b3
Source repository (r216) must be refreshed.
イベントの説明は、移行プロセスに関する詳細な情報を提供し、移行ジョブが失敗したことを示します。 このメッセージは、仮想マシンが移行元のサーバー上で動作するように設定が戻され、移行元の仮想ディスクが保持されていることを示しています。 つまり、仮想マシンは移行元サーバー上で実行中または停止済ですが、Oracle VM Managerの観点からは、仮想マシンの場所は元に戻されています。 最も顕著なことには、出力に「post-migration completion plan」が含まれます。 このプランは、環境を元の状態にロールバックするために実行する必要があるステップの詳細な内訳を提供します。
ローカルにホストされた仮想マシンで失敗した移行に対してこのようなイベントが表示された場合には、移行先サーバーが次に使用可能になったときに手動でロールバック・ステップを実行する必要があります。 ロールバック・ステップが、移行後の完了プランに示されているシステムで実行されていることを確認することがとても重要です。 別のサーバーでこれらのステップを実行すると、悪影響を引き起こし、仮想マシンが壊れる可能性があります。
指定したOracle VM Server上の仮想マシンを強制停止
このプランの最初のステップでは、指定されたOracle VM Server上の仮想マシンを強制終了します。 移行先のOracle VM Serverが使用不可になった時点における移行の状態に応じて、移行先Oracle VM Serverまたは移行先と移行元のOracle VM Serverの両方で処理が必要な場合があります。 どちらのOracle VM Serverでもこの処理を実行する必要がない場合もあります。 適切な処理はイベント説明に記録されます。
移行中、移行元Oracle VM Serverから移行先Oracle VM Serverにコピーされる際に仮想マシンは一時停止状態になります。 コピーが完了すると、移行先Oracle VM Serverの仮想マシンはOracle VM Manager内でまったく表示されなくなります。これは、元の移行元Oracle VM Serverにある同一UUIDを持つ仮想マシンと競合するからです。 この移行は、移行が完了すると、Oracle VM Manager内で実行されます。 結果として、移行期間中、環境内に同じUUIDを持つ2つの仮想マシンが存在する可能性があります。 移行中のある時点で移行先サーバーがオフラインになると、競合を避けるために少なくとも1つの仮想マシンを強制終了する必要があることがよくあります。 ロールバックが完了するまで、Oracle VM Manager内の仮想マシンの表現は信頼できないため、指定されたOracle VM Server上で強制停止操作を直接実行する必要があります。 これは通常、次のコマンドを使用して、rootユーザーでSSHを介して実行されます。
ovs-agent-rpc stop_vm "''" "'0004fb0000060000c71d489702c240b3'" "True"
0004fb0000060000c71d489702c240b3は、当初移行していた仮想マシンのUUIDと一致する必要があります。 また、ここで示された各引数の引用符にも注意してください。 このコマンドの最初の引数は空であるため、一重引用符のペアが二重引用符のペアに囲まれています。 2番目の引数は、強制停止する仮想マシンのUUIDで、二重引用符内のペア内の一重引用符のペアに囲まれて表されています。 最後に、最後の引数は処理を強制するために使用され、二重引用符のペアに囲まれたテキストTrueが入ります。
仮想マシンを停止するには、このコマンドを使用してください。破棄する仮想マシンの正しいドメインを特定するのに役立ち、環境の整合性を維持し、仮想マシン上実行されたすべての処理を記録するからです。 Oracleサポート担当者からの明示的な指示がない場合には、仮想マシンでXenハイパーバイザ・ツールを使用して、直接処理を実行しないでください。
移行先Oracle VM Server上のリポジトリから仮想ディスクを削除
ローカル記憶域でホストされている仮想マシンのライブ・マイグレーションでも、移行元サーバーでホストされているリポジトリから移行先サーバーのリポジトリに仮想ディスクをコピーする必要があります。 そのため、環境をクリーンアップするには、移行先Oracle VM Serverにホストされているリポジトリからこれらのファイルを手動で削除する必要があります。 これを実行するには、移行先Oracle VM Serverに対してSSHを行い、イベント説明で返されたプランに示されているファイルを削除する必要があります。 次に例を示します。
rm -f /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualDisks/
0004fb000012000005213553a5bba24f.img
rm -f /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualDisks/
tmp_dest.0004fb000012000005213553a5bba24f.img
移行先Oracle VM Serverのリポジトリから仮想マシン構成を削除
仮想マシンの仮想マシン構成も、移行時に移行元サーバー上にホストされているリポジトリから移行先サーバーのリポジトリにコピーされます。 そのため、環境をクリーンアップするには、移行先Oracle VM Serverでホストされているリポジトリからこれらのファイルおよびディレクトリを手動で削除する必要があります。 これを実行するには、移行先Oracle VM Serverに対してSSHを行い、イベント説明で返されたプランに示されているファイルを削除する必要があります。 次に例を示します。
rm -f /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualMachines/
0004fb0000060000c71d489702c240b3/vm.cfg
rm -rf /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualMachines/
0004fb0000060000c71d489702c240b3
rm -f /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualMachines/
tmp_dest.0004fb0000060000c71d489702c240b3
移行先Oracle VM Serverのリポジトリのリフレッシュ
移行プロセス中、Oracle VM Managerは、移行が完了した後の環境と一致するように各Oracle VM Serverにホストされている移行元および移行先のリポジトリのモデルを更新します。 自動ロールバックが行われないかぎり、この表現は戻されません。 ロールバックが失敗して、ご使用の環境を元の状態に戻すために手動のステップを実行した場合、モデルがリポジトリの状態を正確に反映するようにOracle VM Manager内のリポジトリもリフレッシュする必要があります。 Oracle VM Manager Webインタフェースを使用してこれを実行することも、Oracle VM Managerコマンドラインを使用して直接実行することもできます。 次に例を示します。
ssh -l admin localhost -p 10000 refresh repository name="r216"
ここまでで、環境は完全に元に戻っているはずです。
13.4.8 大規模なハードウェア仮想化ゲストの移行はCPUソフト・ロックになる
SUN FIRE X4170 M2サーバーなどの一部のハードウェアでは、ハードウェア仮想化を使用して非常に大規模な仮想マシンを移行すると、仮想マシンが応答しない状態になるソフト・ロックアップになる場合があります。 このロックは、移行により仮想マシンのカーネルがクロック・ソースを失った場合に起こります。 仮想マシンのコンソールにアクセスすると、次のような一連のエラー・メッセージが表示されます。
BUG: soft lockup - CPU#0 stuck for 315s! [kstop/0:2131]
これを解決するには、仮想マシンを再起動し、HVMゲスト・カーネル・コマンドラインにclocksource=jiffiesオプションを追加してから、再度仮想マシンを再起動する必要があります。
このオプションは、実際にCPUソフトロックになったHVMゲスト・システムにのみ使用する必要があります。
13.4.9 ハードウェア仮想化ゲスト・デバイスが正常に動作しない
サウンド・カードなどの一部のデバイスがハードウェア仮想化ゲストで正常に動作しない場合があります。 ハードウェア仮想化ゲストでは、物理メモリー・アドレスを必要とするデバイスが、代替として仮想化されたメモリー・アドレスを使用するため、正しくないメモリー位置の値が設定される可能性があります。 これは、ハードウェア仮想化ゲストではDMA(ダイレクト・メモリー・アクセス)が仮想化されるためです。
ハードウェア仮想化ゲストのオペレーティング・システムは、アドレス0以上のメモリーにロードされます。 これは、最初にロードされるハードウェア仮想化ゲストに対してのみ実行されます。 Oracle VM Serverは、メモリー・アドレス0を割り当てられたメモリーのサイズに仮想化しますが、ゲスト・オペレーティング・システムは、実際には別のメモリー位置にロードされます。 違いがシャドウ・ページ・テーブルで修正されますが、オペレーティング・システムはこれを認識しません。
たとえば、100MBのアドレスでMicrosoft Windows™を実行しているハードウェア仮想化ゲストのメモリーに音声がロードされると、目的の音声ではなく、サウンド・カードによってガベージが生成されることがあります。 これは、実際の音声が100MB+256MBの位置でロードされるためです。 サウンド・カードは100MBのアドレスを受け取りますが、実際は256MBの位置です。
コンピュータのメモリー管理単位のIOMMU(I/Oメモリー管理ユニット)では、仮想アドレスと物理アドレスをマッピングし、ハードウェア仮想化ゲストからハードウェアに直接アクセスできるようになるため、この問題はなくなります。
13.4.10 準仮想化ゲスト・ディスク・デバイスが認識されない
PVHVMまたはPVMを作成する場合、仮想マシンが構成されるすべてのディスクが準仮想デバイスとして構成される必要があり、そうしないとディスクが仮想マシンに認識されない場合があります。 ディスクまたは仮想CDROMデバイスが仮想マシンに認識されていないことが判明した場合、仮想マシン用のvm.cfgファイルを直接編集する必要がある場合があります。 これを行うには、仮想マシンのUUIDを確認し、たとえばOracle VM Serverのリポジトリにある構成ファイルを検索します。
# vi /OVS/Repositories/UUID/vm.cfg
hda、hdbまたはhdcなどのハードウェア・デバイスを含む各diskエントリを検索し、xvda、xvdb、xvdcなどのxvdマッピングと置き換えます。
新しい構成で仮想マシンを再起動し、ディスクまたは仮想CDROMデバイスを検出できることを確認します。
13.4.11 インストール・メディアから仮想マシンを作成できない
仮想マシンの作成時、次のメッセージが表示される場合があります。
Error: There is no server supporting hardware virtualization in the selected server pool.
この問題を解決するために、Oracle VM Serverがハードウェア仮想化をサポートしていることを確認します。 確認するには、次のステップを実行します。
-
次のコマンドを実行して、ハードウェア仮想化がCPUでサポートされているかどうかを確認します。
# cat /proc/cpuinfo |grep -E 'vmx|smx'
vmxまたはsmxを含む情報が表示される場合、CPUはハードウェア仮想化をサポートしています。 返されるメッセージの例は、次のとおりです。flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
ノートLinux 2.6.15 (Intel®)およびLinux 2.6.16 (AMD)以降、/proc/cpuinfoコマンドは仮想化機能のみを示します。 カーネルのバージョンを問い合せるには、uname -rコマンドを使用します。
-
BIOSのハードウェア仮想化が有効になっていることを確認します。
-
次のコマンドを実行して、オペレーティング・システムがハードウェア仮想化をサポートしているかどうかを確認します。
# xm info |grep hvm
返されるメッセージの例は、次のとおりです。
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x
CPUでハードウェア仮想化がサポートされていない場合は、準仮想化の方法を使用して仮想マシンを作成してください。 準仮想化仮想マシンの作成の詳細は、Oracle VM Managerオンライン・ヘルプの「サーバーおよびVMタブ」セクションを参照してください。
13.4.12 仮想マシンのCDを変更できない
仮想マシンのCDを変更するには、次の手順を実行します。
-
最初のCDをアンマウントします。
# umount
mount-point -
2番目のISOファイルを選択し、「Change CD」をクリックします。
-
2番目のCDをマウントします。
# mount /dev/cdrom
mount-point
13.4.13 Oracle VM Server (x86)でのゲスト・ダンプ・ファイルの生成
Xenハイパーバイザによって、クラッシュした場合に仮想マシンがコア・ダンプ・ファイルを生成できます。 このファイルは、デバッグおよびサポート目的に役立ちます。 コア・ダンプ・ファイルは大きい可能性があり、ファイルの上書きを避けるために、各ファイルには一意の名前が付けられます。 この機能を有効にすると、コア・ダンプ・ファイルはクラッシュ時に仮想マシンが実行されていたOracle VM Serverの/var/xen/dumpに保存されます。 これにより、dom0システム・パーティション上の使用可能なディスク領域が急速に使い尽くされる可能性があります。 この機能を有効にする場合、このパスに追加のディスクをマウントするか、ディスク領域が十分にある別の場所を指すようにこのパスのシンボリックリンクを作成することで、Oracle VM Serverのこのパスに十分なディスク領域を確保する必要があります。
デフォルトでは、この機能はシステム全体レベルで無効です。 /etc/xen/xend-config.sxpを直接編集して、次に示す行を変更することで、この動作を変更することができます。
# Whether to enable core-dumps when domains crash. #(enable-dump no)
次のようにします。
# Whether to enable core-dumps when domains crash. (enable-dump yes)
この変更を行ったら、変更が有効になるようにOracle VM Serverを再起動する必要があります。 Oracle VM ServerでのグローバルXen構成パラメータの手動編集は、Oracleではサポートされていません。
個々の仮想マシンのvm.cfgにこのパラメータを直接設定することで、システム全体の動作をオーバーライドできます。 デバッグしようとしている仮想マシンにコア・ダンプを限定できるため、これはダンプ・ファイルを生成するお薦めの方法です。 そのため、この構成オプションは、Oracle VM Manager内から各仮想マシンに対して制御できます。 仮想マシンの「Restart Action On Crash」オプションを構成することで、このオプションを設定できます。 このパラメータの詳細は、Oracle VM Managerオンライン・ヘルプの「サーバーおよびVMタブ」セクションを参照してください。
仮想マシンの「Restart Action On Crash」オプションを変更する場合、変更を有効にするには仮想マシンを停止してから再起動する必要があります。 仮想マシンのvm.cfg構成ファイルは、仮想マシンの起動時にXenハイパーバイザからのみ読み込まれるため、これは仮想マシンの再起動とは異なります。 構成は変更したが、仮想マシンを適切に再起動していない場合、クラッシュと再起動では自動的に構成オプションが有効にはなりません。
仮想マシンのコア・ダンプ機能が正常に動作しているかどうかをテストするために、次のコマンドを発行する前に、仮想マシンにログインしてroot権限を取得し、クラッシュを直接トリガーすることができます。
# echo c >/proc/sysrq-trigger
このコマンドは、仮想マシンのオペレーティング・システムがLinuxベースであり、システム・リクエスト・トリガーがカーネル内で有効であることが前提です。 クラッシュをトリガーした後、仮想マシンが実行されていたOracle VM Serverの/var/xen/dumpを確認してダンプ・ファイルを表示します。
13.4.14 ストレージ移行処理用のLinuxベースの仮想マシンのチューニング
仮想マシンが、実行されているOracle VM Server上のローカル記憶域を使用するリポジトリでホストされている場合、その仮想マシンを別のOracle VM Serverおよびリポジトリに移行するには、影響を受けるディスクに対するI/Oがあまり高くならないようにする必要があります。 移行時にI/Oが高いアプリケーションを実行している場合、ゲストまたはアプリケーションがハングする可能性があります。 ゲスト・カーネル内の仮想メモリー・キャッシング・パラメータをチューニングし、ext4でフォーマットされたファイル・システムを実行している可能性のあるゲストに対してext4ジャーナリング・コミット頻度を減らすことで、Linuxオペレーティング・システムを実行しているゲストに対してI/Oを減らすステップを実行できます。
「仮想メモリー・キャッシングのチューニング。」ゲスト・コマンド行で、rootユーザーとして、sysctlコマンドを使用してカーネル・パラメータの数を設定することでキャッシュをチューニングできます。 キャッシュ・サイズを、システム・メモリーの5%(デフォルト値は10%)に減らし、メモリーがフラッシュされるまで使用済のままである時間をおおよそ20秒(デフォルトは30秒)に減らすことをお薦めします。 次のコマンドを実行して、これを一時的に実行することができます。
# sysctl -w vm.dirty_background_ratio=5 # sysctl -w vm.dirty_expire_centisecs=2000
あるいは、/etc/sysctl.confを編集して、これらの行を追加できます。
vm.dirty_background_ratio=5 vm.dirty_expire_centisecs=2000
追加後、sysctl -pを実行して、これらの値をカーネルにロードできます。
ext4ジャーナリングのチューニング。 ゲストが、ext4を使用するようにフォーマットされたファイル・システムを使用している場合、ジャーナリング・コミット・プロセスは移行によって影響を受ける可能性があります。 これを避けるには、ジャーナル・コミット間の時間を減らし、コミットが非同期に行われるようにします。 これを行うには、ゲスト内にマウントしたext4ファイル・システムのマウント・パラメータをチューニングしてください。 たとえば、ext4でフォーマットされたファイル・システムをマウントする場合、次のオプションを使用できます。
# mount -o commit=5,journal_async_commit /dev/xvdd /vdisk3
これをすべてのext4マウントに対して効果的に実行するには、/etc/fstabを編集する必要があります。