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"

ゲストのインストール後に特定のオペレーティング・システム・バリアントのブート・ローダー(grub.conf)構成ファイルに追加のパラメータが必要になる場合があります。 特に、最適かつ正確なクロックには、Linuxゲスト・ブート・パラメータを指定して、pitクロック・ソースを使用する必要があります。 ほとんどのゲストにclock=pit nohpet nopmtimerを追加することで、ゲストのクロック・ソースとしてpitが選択されます。 Oracle VM用に公開されているテンプレートには、これらの追加パラメータが含まれます。

仮想時間を正確に保守することは困難です。 様々なパラメータが仮想時間の管理と補完のチューニングを行いますが、ゲスト内で実行されるntp時間サービスの代わりにはなりません。 ntpdサービスが実行され、/etc/ntp.conf構成ファイルが有効な時間サーバーを示していることを確認してください。

マウス・ポインタがハードウェア仮想化ゲストのVNC Viewerセッションのカーソルを追跡しない場合、次の行を/etc/xen/xend-config.sxpのOracle VM Server構成ファイルに追加して、デバイス・モデルで絶対(タブレット)座標が使用されるようにします。

usbdevice='tablet'

変更を有効にするには、Oracle VM Serverを再起動します。 サーバー・プールのOracle VM Serverごとに、これを実行する必要があります。

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']エントリとのネットワーク構成の不一致が原因です。

この問題を解決するには、仮想マシン・テンプレートの既存のネットワークをすべて削除し、仮想マシン・ロールを持つ有効なネットワークで置換します。 クローン・ジョブを開始すると、仮想マシン・クローンが作成されます。 または、テンプレートの既存のネットワークをすべて削除し、クローン・ジョブを再開し、クローン・ジョブの完了後に任意のネットワークに追加します。

ハードウェア仮想化ゲストを実行すると、QEMUプロセス(qemu-dm)のメモリー使用量が特に負荷の高いI/Oで大幅に増加する可能性があります。 このため、メモリーが不足してハードウェア仮想化ゲストが停止する場合があります。 ゲストが停止した場合は、dom0のメモリーの割当てを(たとえば、512MBから768MBに)増加します。 dom0メモリーの割当ての変更方法の詳細は、1.6項「管理ドメインのメモリー・サイズの変更」を参照してください。

同等ではないハードウェアを使用するコンピュータの仮想マシンは移行できません。 仮想マシンを移行するには、同じ型および同じモデルのハードウェアおよび同じCPUファミリのCPUを使用する必要があります。

仮想マシンは、同じリリース以降のOracle VM Serverのインスタンス間でライブ・マイグレーションを実行できます。 x86プラットフォームで実行される仮想マシンについては、仮想マシンが実行されているOracle VM Serverより前のリリースのOracle VM Serverに仮想マシンをライブ・マイグレーションしようとするとルール例外が生成されます。

ローカル・リポジトリでホストされている仮想マシンがライブ・マイグレーションされるイベントで、移行中に移行元または移行先の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」が含まれます。 このプランは、環境を元の状態にロールバックするために実行する必要があるステップの詳細な内訳を提供します。

ローカルにホストされた仮想マシンで失敗した移行に対してこのようなイベントが表示された場合には、移行先サーバーが次に使用可能になったときに手動でロールバック・ステップを実行する必要があります。 ロールバック・ステップが、移行後の完了プランに示されているシステムで実行されていることを確認することがとても重要です。 別のサーバーでこれらのステップを実行すると、悪影響を引き起こし、仮想マシンが壊れる可能性があります。

ovs-agent-rpc stop_vm "''" "'0004fb0000060000c71d489702c240b3'" "True"

rm -f /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualDisks/
    0004fb000012000005213553a5bba24f.img
rm -f /OVS/Repositories/0004fb0000030000f9ba13d5063e330a/VirtualDisks/
    tmp_dest.0004fb000012000005213553a5bba24f.img

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

ssh -l admin localhost -p 10000 refresh repository name="r216"

SUN FIRE X4170 M2サーバーなどの一部のハードウェアでは、ハードウェア仮想化を使用して非常に大規模な仮想マシンを移行すると、仮想マシンが応答しない状態になるソフト・ロックアップになる場合があります。 このロックは、移行により仮想マシンのカーネルがクロック・ソースを失った場合に起こります。 仮想マシンのコンソールにアクセスすると、次のような一連のエラー・メッセージが表示されます。

BUG: soft lockup - CPU#0 stuck for 315s! [kstop/0:2131]

これを解決するには、仮想マシンを再起動し、HVMゲスト・カーネル・コマンドラインにclocksource=jiffiesオプションを追加してから、再度仮想マシンを再起動する必要があります。

サウンド・カードなどの一部のデバイスがハードウェア仮想化ゲストで正常に動作しない場合があります。 ハードウェア仮想化ゲストでは、物理メモリー・アドレスを必要とするデバイスが、代替として仮想化されたメモリー・アドレスを使用するため、正しくないメモリー位置の値が設定される可能性があります。 これは、ハードウェア仮想化ゲストではDMA(ダイレクト・メモリー・アクセス)が仮想化されるためです。

ハードウェア仮想化ゲストのオペレーティング・システムは、アドレス0以上のメモリーにロードされます。 これは、最初にロードされるハードウェア仮想化ゲストに対してのみ実行されます。 Oracle VM Serverは、メモリー・アドレス0を割り当てられたメモリーのサイズに仮想化しますが、ゲスト・オペレーティング・システムは、実際には別のメモリー位置にロードされます。 違いがシャドウ・ページ・テーブルで修正されますが、オペレーティング・システムはこれを認識しません。

たとえば、100MBのアドレスでMicrosoft Windows™を実行しているハードウェア仮想化ゲストのメモリーに音声がロードされると、目的の音声ではなく、サウンド・カードによってガベージが生成されることがあります。 これは、実際の音声が100MB+256MBの位置でロードされるためです。 サウンド・カードは100MBのアドレスを受け取りますが、実際は256MBの位置です。

コンピュータのメモリー管理単位のIOMMU(I/Oメモリー管理ユニット)では、仮想アドレスと物理アドレスをマッピングし、ハードウェア仮想化ゲストからハードウェアに直接アクセスできるようになるため、この問題はなくなります。

PVHVMまたはPVMを作成する場合、仮想マシンが構成されるすべてのディスクが準仮想デバイスとして構成される必要があり、そうしないとディスクが仮想マシンに認識されない場合があります。 ディスクまたは仮想CDROMデバイスが仮想マシンに認識されていないことが判明した場合、仮想マシン用のvm.cfgファイルを直接編集する必要がある場合があります。 これを行うには、仮想マシンのUUIDを確認し、たとえばOracle VM Serverのリポジトリにある構成ファイルを検索します。

# vi /OVS/Repositories/UUID/vm.cfg

hda、hdbまたはhdcなどのハードウェア・デバイスを含む各diskエントリを検索し、xvda、xvdb、xvdcなどのxvdマッピングと置き換えます。

新しい構成で仮想マシンを再起動し、ディスクまたは仮想CDROMデバイスを検出できることを確認します。

仮想マシンの作成時、次のメッセージが表示される場合があります。

Error: There is no server supporting hardware virtualization in the selected server pool.

この問題を解決するために、Oracle VM Serverがハードウェア仮想化をサポートしていることを確認します。 確認するには、次のステップを実行します。

CPUでハードウェア仮想化がサポートされていない場合は、準仮想化の方法を使用して仮想マシンを作成してください。 準仮想化仮想マシンの作成の詳細は、Oracle VM Managerオンライン・ヘルプの「サーバーおよびVMタブ」セクションを参照してください。

仮想マシンのCDを変更するには、次の手順を実行します。

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を確認してダンプ・ファイルを表示します。

仮想マシンが、実行されている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を編集する必要があります。