Redhat の KB は私のアカウントではアクセスできませんでした。
Product Documentの記載では以下の部分が根拠となっていますね。
| 仮想マシンは実際のハードウェアクロックにアクセスできず、仮想クロックの安定性はホストシステムの作業量に依存することから、十分な安定性がありません。 |
ESXiの仮想化においては以下のドキュメントにもある通り、タイマーデバイスも仮想化されているため、Guest OSが直接ハードウェアクロックを参照することは無いようです
Timekeeping in VMware Virtual Machines
ドキュメント自体が古いため現在では当てはまらない可能性もありますが、資料中ではTSCなどのCPU 割り込みが発生しない仕組みであっても、遅延する可能性について示されております。
NTPを利用すれば、より正確に時刻同期をすることができますが、NTPの同期間隔のカウントにも仮想タイマーデバイスが利用されていると考えると、物理マシン上のOSのほうが精度は高いと考えられます。
仮想化によって仮想タイムデバイスが提供する時刻がリアルタイムとどれくらいズレるのかについては環境に依存しますので実際に測定してみていただくくらいしかないと思います。
NTPを利用する場合はNTP自体の精度の考慮も必要かと思います。
Wikiの記載ではNTPはLAN内でミリSec程度、PTPであればサブマイクロSec程度の精度だと記載があります。
Precision Time Protocol - Wikipedia
Network Time Protocol - Wikipedia
そもそもNTPでも精度が足りないということであればPTPを検討いただくのが良いでしょう。
PTPについては以下のブログが参考になります。
プレシジョンクロックデバイスで ESXi とゲストOSを時刻同期 | vSoliloquy (jangari-ntk.github.io)
ここからは完全に私見となりますが、仮想化（CPU時間のスケジューリング等）による時刻のズレを気にするよりも、vMotionやSnapshotに起因する瞬間的なフリーズが作り出すズレを修正するための時間のほうが問題になるのではないかと思います。
以下の記事によるとNTPのSkewモードでは1秒の誤差を直すのに2000秒もかかるとあります。
時刻の後戻りを発生させずにシステム全体の時刻を確実に同期させたい | 日経クロステック（xTECH） (nikkei.com)
実際に仮想マシンのvMotionやSnapshotなどで1秒もフリーズするようなことはほぼ起こりえないと思いますが、もし何かの拍子にずれが発生してしまうとそれを修正するのに何倍もの時間がかかってしまいますので、信頼のある時刻同期が必要な場合は専用の物理サーバで用意するのが良いとおもいます。
逆に数秒くらいのズレを許容できるような環境であれば仮想マシン（NTP同期）でも問題ないと思います。
結局のところはNTP Client側でどの程度正確な時刻同期が要求されるのかが一番重要ですね。
