なぜそれが起こるのですか?
これは、ホストの物理ハードウェアの特性を仮想ハードウェアで完全かつ正確に表現できず、x86 プラットフォーム (効率的な仮想化は長年不可能と考えられていた) で仮想化を提供できないために発生すると考えられます。オーバーヘッド。より具体的には、物理 CPU と論理 CPU 間のクロック速度と電力管理のばらつきが 1 つの要因であると考えられます。おそらく物理 CPU の CPU クロック速度は異なると思いますが、VMware が提示する論理 CPU はそれを示していません。IIRC の TSC (Time Stamp Counter) レジスタがめちゃくちゃになり、特に Windows が混乱します。
VMware は、通常の徹底的なエンジニアリングで、VM のタイムキーピングがどのように機能し、どのような問題が発生する可能性があるかについて 、 31 ページの包括的な記事を公開しています。 .pdf . Windows のタイムキーピングについては、14 ページで説明しています。
参照:
http://pelican.rsvs.ulaval.ca/mediawiki/index.php/VMWare_tips_and_tricks#Power_ Saving_.28SpeedStep.2C_C-states.2C_P-States.2C....29
このハードウェア上のこの VM にとって、なぜそれほど悪いのでしょうか? 何も思いつきません; そこでお役に立てれば幸いです。同じマシンに他の Windows VM がありますか? 彼らはどのようにうまくいきますか?
修正方法:
正確なホスト時刻がある場合、VMware Tools の時刻を 60 秒ごとに同期させることが適切な解決策であると確信しています。(ホスト時間が正確でない場合は、このセクションの最後で設定方法を確認してください。)
これを VM の .vmx ファイルに配置します。
tools.syncTime = true
tools.syncTime.period = 60 #Every 60 seconds is supposed to be the default, but this forces it to 60 second just in case.
必要に応じて、毎秒ホストと同期させることができます。
tools.syncTime.period = 1
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1318
これを行ったら、Windows がハードウェア TOD クロックと同期していないことを確認してください。がそれと同期しようとすると、VMware のドキュメントで詳しく説明されているように、問題が発生する可能性があります。VMware は、これをデフォルトで無効にしていると言っていますが、特に別の修正を試みていた場合は、再び有効になっている可能性があります。
また、私見ですが、マイクロソフトの時刻同期は問題の終わりではありません。同じホストに Linux ゲストがあるので、そこに NTP をセットアップして、ホストのクロックを最新の状態に保ちます。
その他のソリューション情報:
問題が発生する理由についての時折のボーナス回答とともに、Linux VM 用であっても、VM を適切な時間同期に保つための優れた回答のセットを次に示します。
VMWare VM のクロックを同期させるには?
これは、Linux VM への参照にもかかわらず機能すると思われる古い記事です
。 .aspx