Linux ゲスト OS におけるタイムキーピングの問題のトラブルシューティング
Article ID: 307991
Updated On:
Products
VMware
VMware Desktop Hypervisor
VMware vSphere ESXi
Issue/Introduction
この記事には、仮想マシンで Linux ゲスト OS を実行する場合に発生するタイムキーピングの問題のトラブルシューティング手順が記載されています。
Symptoms:
Symptoms:
免責事項： これは英文の記事 「Troubleshooting timekeeping issues in Linux guest operating systems (1011771)」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。
- 仮想マシンの時間が突然進んだり戻ったりします
- 仮想マシンの時間がゆっくりと経過します
- 仮想マシンの時間が早く経過します
Resolution
下記のそれぞれのトラブルシューティング手順がお使いの環境に当てはまることを確認します。各手順で提供されている指示または記事へのリンクは、考えられる原因を排除し、必要に応じて是正措置を講じるのに役立ちます。手順は、問題を隔離し、適切な解決方法を特定するために最適な順番で並べられています。手順を省略しないでください。
- 「Linux timekeeping best practices (1006427)」で説明されている、タイムキーピングのベスト プラクティスを適用します。
ESX の場合は、ホストで NTP を実行します。
ホスト製品の場合は、ホストで w32time または NTP を必要に応じて実行します。Workstation 6.5 以降、Fusion 2.0 以降、Server 2.0 以降、または Player 2.0 以降のバージョンを使用します。これらのリリースには、ホストの TSC 同期に関する問題を解決するためのいくつかの修正が含まれます。
- タイマー割り込みの伝達が遅れていないかどうかを確認します。
通常、タイムキーピング割り込みは、ゲスト OS が現在時刻を決定するために使用します。ハイパーバイザーによって起動されたタイムキーピング割り込みのレートが、ゲスト OS によって要求されたレートよりも低い場合、ゲスト OS に表示される、仮想ハードウェアから報告された時間は実際の時間とは異なります。タイマー割り込みの伝達の詳細、およびタイマー割り込みの伝達が遅れることの意味については、『Timekeeping in VMware Virtual Machines』を参照してください。タイマー割り込みが正しいレートで伝達されている、つまり、仮想ハードウェアが正しい時間を報告している場合でも、ゲスト OS の問題（手順 3 以降でこの問題を解決します）によりゲストの時間が依然として不正確になることがあります。ただし、タイマー割り込みの伝達が遅れている場合、その問題を修正するためにゲスト内から実行できることはほとんどありません。そのため、まず、タイマー割り込みの伝達の遅れを解決することが重要になります。
タイマー割り込みの伝達がどの程度遅れているかを測定する最良の方法は、TimeTrackerStats を有効化することです。TimeTrackerStats の詳細については、『Timekeeping in VMware Virtual Machines』の「Turn On Additional Logging」を参照してください。
この記事の目的上、次の行を仮想マシンの構成 (.vmx) ファイルに追加します。
timeTracker.periodicStats = TRUE
timeTracker.statInterval = 5
これらの行は、直接、または VI Client を使用して追加できます。
確認されたタイムキーピングの問題が割り込みの伝達の遅れによって発生しているかどうかを確認するには、タイムキーピングの問題を再現し、問題のある時間に対応する TimeTrackerStats メッセージを調べます。メッセージ内で重要なのは、behind by の部分です。
TimeTrackerStats behind by 2246 us; ...
この場合、TimeTrackerStats は、割り込みの伝達が 2246 マイクロ秒のみ遅れていることを報告しています。これは正常です。タイマー割り込みの伝達が相当な時間遅れている場合、次のようなメッセージが表示されます。
TimeTrackerStats behind by 6929841 us; ...
この場合、TimeTrackerStats は、割り込みの伝達が 6929841 マイクロ秒遅れていることを報告しています。つまり、6.9 秒の遅れです。
割り込みの伝達が相当な時間（1 または 2 秒以上）遅れていることが TimeTrackerStats によって報告された場合、次の手順を実行します。
- vmkernel がゲストのメモリをディスクにページングしているかどうかを確認します。
次の手順を実行してください。
- esxtop を起動します。
- m と入力し、メモリ ビューに切り替えます。
- SWAP で始まる行を確認します。
たとえば、次のように表示されます。
SWAP /MB: 0 curr, 0 target: 0.00 r/s, 0.00 w/s
ゼロ以外の数字がある場合、vmkernel は、ホスト上の 1 つ以上の仮想マシン用のディスクにゲストのメモリの一部をスワップしています。問題の背景情報と解決方法については、「Time falls behind in a virtual machine when the memory of the virtual machine is paged from disk by the VMKernel (1005861)」を参照してください。
VMkernel のスワップが発生していないのに、割り込みの伝達が依然として遅れている場合は、手順 b に進んでください。
- 仮想マシンに十分な CPU リソースがあることを確認します。
次の手順を実行してください。
- esxtop を起動します。
- e、および問題のある仮想間マシンの GID を入力します。Enter を押します。
- vmm ワールドの %RDY 時間を確認します。
%RDY が高い場合、仮想マシンは、必要なだけの CPU リソースを取得していません。
以下に ESX 3.5 の例を示します。この例では、VM RHEL5.2-0 が展開され、個々の vmm ワールド（vmm0:RHEL5.2-0 など）が表示されています。各ワールドの %RDY は約 50% を示しています。これは、ホストで 2 倍の CPU オーバーコミットが提供されていることに相当します。
ID GID NAME NWLD %USED %RUN %SYS %WAIT %RDY %IDLE %OVRLP
1141 28 vmware-vmx 1 0.06 0.06 0.00 99.71 0.30 0.00 0.00
1142 28 vmm0:RHEL5.2-0 1 50.54 51.00 0.01 0.68 48.37 0.00 0.46
1143 28 vmm1:RHEL5.2-0 1 49.69 50.16 0.00 1.38 48.52 0.00 0.46
1144 28 vmm2:RHEL5.2-0 1 50.56 51.01 0.00 2.80 46.24 0.00 0.45
1145 28 vmm3:RHEL5.2-0 1 50.52 50.97 0.00 2.51 46.56 0.00 0.40
1146 28 vmware-vmx 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00
1147 28 mks:RHEL5.2-0 1 0.60 0.59 0.02 95.23 4.25 0.00 0.00
1148 28 vcpu-0:RHEL5.2-0 1 0.01 0.01 0.00 99.99 0.00 0.00 0.00
1149 28 vcpu-1:RHEL5.2-0 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00
1150 28 vcpu-2:RHEL5.2-0 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00
1151 28 vcpu-3:RHEL5.2-0 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00
1169 28 Worker#0:RHEL5.2-0 1 0.01 0.01 0.00 99.98 0.00 0.00 0.00
29 29 RHEL5.2-1 12 188.39 189.68 0.02 797.75 213.04 0.00 1.30
30 30 RHEL5.2-2 5 4.50 4.52 0.00 487.59 8.09 88.99 0.02
31 31 RHEL5.2-3 11 187.19 188.70 0.00 706.60 205.30 0.19 1.48
32 32 RHEL5.2-4 12 211.10 211.47 0.00 803.07 185.59 0.00 1.29
%RDY が高い場合、この問題を解決するには、次の 2 つの方法があります。
-
- ホストの負荷を軽減します。これが最も簡単な解決策です。
または
- CPU 予約を仮想マシンに適用します。この方法が役立つのは、一部の仮想マシンでのみ正確なタイムキーピングを維持する必要がある場合や、一部の仮想マシンが時間を正確に維持するためにより多くの CPU リソースを必要とする場合です。
仮想マシンの %RDY が低いのに、タイマー割り込みの伝達が依然として遅れている場合は、手順 3 に進んでください。
- ホストの負荷を軽減します。これが最も簡単な解決策です。
- 「Time falls behind in a virtual machine when the guest operating system writes to previously unwritten regions of its virtual disk (1008284)」の問題に該当するかどうかを確認し、該当する場合は、この記事で説明されている解決策のいずれかを適用します。
- タイマー割り込みの伝達が依然として相当な時間遅れる場合、サポート リクエストを提出してください。
- vmkernel がゲストのメモリをディスクにページングしているかどうかを確認します。
- ゲストおよびホストで NTP が適切に動作していることを確認します。ntpd のステータスを確認するには、ntpq -p コマンドを実行し、ntpd と通信しているピアのリストを出力します。現在選択しているピア（名前の先頭に「*」が付いています）があることを確認します。他のサーバに「+」のマークが付けられている状態が理想的です。このマークは、これらのサーバも受け入れ可能であることを示しています。
例：
bash$ ntpq -p
remote refid st t when poll reach delay offset jitter
========================================================================
+ntps2.gslabs.org 192.168.0.72 2 u 149 256 377 0.212 -18.115 11.359
+ntps3.gslabs.org 192.168.0.72 2 u 185 256 377 0.207 -82.106 14.625
*ntps1.gslabs.org 192.168.0.72 2 u 175 256 377 0.266 65.871 21.401
ntps4.gslabs.org 192.168.10.2 3 u 55 256 377 0.284 -20.468 19.470
- 参照源から報告された時間に対して、ゲストの時間を収集します。
/usr/sbin/ntpdate -q <timeserver> では、<timeserver> に指定された NTP サーバと比べて、クライアント（ntpdate が実行されている）の時間がどの程度進んでいるか、または遅れているかが報告されます。正のオフセットは、クライアントの時間がサーバの時間よりも遅れていることを示します。負のオフセットは、クライアントの時間がサーバの時間よりも進んでいることを示します。
例：
bash$ /usr/sbin/ntpdate -q 0.vmware.pool.ntp.org
server 65.182.224.39, stratum 2, offset -0.002269, delay 0.04424
server 66.79.167.34, stratum 2, offset 0.004515, delay 0.03171
server 72.18.205.156, stratum 2, offset 0.004714, delay 0.04095
server 72.167.54.201, stratum 2, offset 0.000994, delay 0.04677
server 128.10.252.10, stratum 2, offset -0.019049, delay 0.08801
28 Apr 20:25:20 ntpdate[1217]: adjust time server 66.79.167.34 offset 0.004515 sec
次のコマンドを使用して、クライアントの時間がどのように変化しているかに関するデータを収集できます。
bash$ while true; do /usr/sbin/ntpdate -q 0.vmware.pool.ntp.org | tail -n -1; sleep 1; done
28 Apr 20:35:21 ntpdate[5112]: adjust time server 66.79.167.34 offset 0.004764 sec
28 Apr 20:35:27 ntpdate[5116]: adjust time server 66.79.167.34 offset 0.004872 sec
28 Apr 20:35:33 ntpdate[5119]: adjust time server 66.79.167.34 offset 0.004834 sec
28 Apr 20:35:39 ntpdate[5123]: adjust time server 66.79.167.34 offset 0.004871 sec
28 Apr 20:35:44 ntpdate[5127]: adjust time server 66.79.167.34 offset 0.004857 sec
28 Apr 20:35:50 ntpdate[5147]: adjust time server 66.79.167.34 offset 0.004909 sec
28 Apr 20:35:56 ntpdate[5150]: adjust time server 66.79.167.34 offset 0.004858 sec
このデータをスプレッドシートにインポートし、オフセットをグラフで経時的に示すことができます。グラフの中で時間の突然の変化が現われた場合、ゲスト内の時刻同期ユーティリティ（NTP または VMware Tools の時刻同期など）によって修正が適用された可能性があります。問題のトラブルシューティングを行う場合は、すべての時刻同期ユーティリティを一時的に無効化することをお勧めします。これにより、同期ユーティリティによる時刻修正の試みと根本的な問題を区別することが容易になります。- 結果の線が直線の場合は、問題として、ハードウェアのドリフトのレートが、NTP で修正できないほど高いことが考えられます。この問題の回避策については、「Confirming HPET is not misreporting its frequency (1006090)」を参照してください。
- 結果の線が直線でない場合は、次のどちらかの問題が考えられます。
- 結果の線が時間の損失を示している、つまり、ゲストの時間が実際の時間よりもさらに遅れていく場合、最も可能性の高い問題としてティックの損失が考えられます。詳細は、「Time runs slower than real time due to lost timer interrupts (1006088)」を参照してください。
- 結果の線が時間の先行を示している、つまり、ゲストの時間が実際の時間よりもさらに進んでいく場合、最も可能性の高い問題としてティックの損失の過補償が考えられます。詳細は、「Time in Linux 2.6 guest operating system runs faster than real time due to lost tick overcompensation (1006113)」を参照してください。
注：問題が解決しない場合は、次の操作を実行してください。
- VMware サポート スクリプト データを収集します。詳細は、「Collecting diagnostic information for VMware products (1008524)」を参照してください。
- VMware サポートにサポート リクエストを提出し、このナレッジ ベースの記事 ID を問題の説明の中に記入してください。詳細は、『How to submit a support request』を参照してください。
Additional Information
Feedback
Yes
No
Powered by
