TL;DR
VM は KVM を使用し、時刻は同期されません。 2分間一時停止した後は、永続的な2分間隔が残ります。異なるネットワーク構成で異なる仮想マシンを設定すると、ネットワーク構成のためにntpが機能しないように見えます。このネットワークの問題を解決することはトピックを超えています。
ただし、ネットワークに問題がない新しい仮想マシンは、回復後も同期されません。同じテスト：2分間一時停止します。正しく同期されたコンピュータとの日付の違いを確認してください。 2分の遅延は永久的です。
これは一般的な問題であるように見え、仮想マシンを同期状態に保ち、NTPとkvm-clockを同時に使用する方法について議論があります。多くの参考資料が見つかりましたが、答えはありません。
質問
ntpd実行されているが時間を変更できないDebian VMがあります。たとえば、一時停止/再開後に永続的な2分オフセットを取得します。
/etc/ntp.confデフォルト値またはデフォルト値に近い、特別なものはありません。
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
driftfile /var/lib/ntp/ntp.drift
# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst
# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.
# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1
# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust
# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255
# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines. Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient
ntpqが問題を報告しているようです。
# cat ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
37.187.7.160 .INIT. 16 u - 1024 0 0.000 0.000 0.000
195.154.211.37 .INIT. 16 u - 1024 0 0.000 0.000 0.000
195.154.216.44 .INIT. 16 u - 1024 0 0.000 0.000 0.000
95.81.173.155 .INIT. 16 u - 1024 0 0.000 0.000 0.000
しかし、私はnetcatウィザードではありませんが、UDPポート123のAFAIU発信トラフィックは次を通過します。
# nc -vvzu 37.187.7.160 123
mail.lafkor.de [37.187.7.160] 123 (ntp) open
sent 0, rcvd 0
このテストはファイアウォールの問題を排除するのに十分ですか？
ホスト（Debianシステムでもあります）は同じNTP設定を持ち、同期が実行されています。両方のコンピュータのネットワーク構成が異なるため、ネットワークの問題である可能性があると思いました。
実行できる他の便利なテストはありますか？
tinker panic 0このパラメータは、2分間隔ではなく大きな間隔の更新を強制するように設計されているため、ここでは関係がないと思います。とにかく、AFAIUは時間オフセットの動作に影響しますが、ntpq -pnゼロを返すだけの問題は解決しません。
FWIW、他のテスト出力は以下からインスピレーションを受けました。この問題:
# ntpq
ntpq> pe
remote refid st t when poll reach delay offset jitter
==============================================================================
mail.lafkor.de .INIT. 16 u - 1024 0 0.000 0.000 0.000
atoll.tropicdre .INIT. 16 u - 1024 0 0.000 0.000 0.000
oods.roflcopter .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntp-3.arkena.ne .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntpq> as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 21025 8011 yes no none reject mobilize 1
2 21026 8011 yes no none reject mobilize 1
3 21027 8011 yes no none reject mobilize 1
4 21028 8011 yes no none reject mobilize 1
ntpq> rv
associd=0 status=c012 leap_alarm, sync_unspec, 1 event, freq_set,
version="ntpd [email protected] Fri Apr 10 19:04:04 UTC 2015 (1)",
processor="x86_64", system="Linux/3.16.0-4-amd64", leap=11, stratum=16,
precision=-23, rootdelay=0.000, rootdisp=6683.055, refid=INIT,
reftime=00000000.00000000 Mon, Jan 1 1900 0:09:21.000,
clock=d9b51587.b7a1085f Tue, Sep 29 2015 15:49:59.717, peer=0, tc=3,
mintc=3, offset=0.000, frequency=-0.125, sys_jitter=0.000,
clk_jitter=0.000, clk_wander=0.000
ntpq> rv 21025
associd=21025 status=8011 conf, sel_reject, 1 event, mobilize,
srcadr=mail.lafkor.de, srcport=123, dstadr=147.210.157.185, dstport=123,
leap=11, stratum=16, precision=-23, rootdelay=0.000, rootdisp=0.000,
refid=INIT, reftime=00000000.00000000 Mon, Jan 1 1900 0:09:21.000,
rec=00000000.00000000 Mon, Jan 1 1900 0:09:21.000, reach=000,
unreach=1137, hmode=3, pmode=0, hpoll=10, ppoll=10, headway=0,
flash=1600 peer_stratum, peer_dist, peer_unreach, keyid=0, offset=0.000,
delay=0.000, dispersion=15937.500, jitter=0.000, xleave=0.167,
filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00,
filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00,
filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
tcpdump/ntpdate テスト
NTP 同期が正常に動作しているコンピュータでtcpdump udp port ntp起動して再起動すると、ntpd次の出力が表示されます。
# tcpdump udp port ntp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:31:33.719166 IP 10.0.2.15.ntp > spica.beduzar.fr.ntp: NTPv4, Client, length 48
17:31:33.736804 IP spica.beduzar.fr.ntp > 10.0.2.15.ntp: NTPv4, Server, length 48
17:31:35.973551 IP 10.0.2.15.ntp > ntp.tuxfamily.net.ntp: NTPv4, Client, length 48
17:31:35.992671 IP ntp.tuxfamily.net.ntp > 10.0.2.15.ntp: NTPv4, Server, length 48
[...]
問題のあるコンピュータでntpd再起動すると、出力はまったく表示されません（要求なし、応答なし）。少なくともこのような要求は見なければなりませんか？
よい機械で:
# ntpdate 0.debian.pool.ntp.org
29 Sep 17:24:49 ntpdate[700]: adjust time server 193.55.167.1 offset -0.005196 sec
不良マシンの場合：
# ntpdate 0.debian.pool.ntp.org
29 Sep 17:43:18 ntpdate[3180]: no server suitable for synchronization found
テストに別の仮想マシンを使用する
NTP構成は同じですが、ネットワーク構成が異なる別の仮想マシンを設定しました。
tcpdumpand の結果はntpdate正確でntpq -pn良い結果を返します。明らかに、ネットワーク構成は実際に欠陥のあるVMに問題があるようです。
ただし、新しい仮想マシンも同期されません。約100秒遅れるように一時停止すると同期されません。つまり、数分後でも間隔はまだ同じ秒数です。ただし、ntpdが再起動するとすぐに同期されます。
2つの問題があるようです。
最初の仮想マシンのネットワーク構成
ntpは両方で同期されません（再起動しない限り）。
答え1
問題が解決しました。
インターネットの問題
VMにntpdの成功を妨げるネットワークの問題があります。 2つのインターフェイスがありますがeth、ゲートウェイを持つインターフェイスは私たちが直接管理していないルータを通過します。私のテストではこれは表示されていませんが、一部のUDPフレームがブロックされているようです。我々は、異なるネットワーク構成で異なる仮想マシンを設定し、ntpqより良い結果を得ました。
結局のところ、ntpホストは時間をローカルにブロードキャストし、すべてのVMが同期するように設定を変更しました。より合理的でntpパブリックサーバーの負荷を最小限に抑えます。
ntpd数分後、すぐに時計を設定してください。
テスト中に私を誤解した可能性があるのは、ntpdがすぐに同期されないことです。私の考えでは、間隔をすぐに検出してからクロック速度を修正して、クロックがソースクロックに徐々に合流するようにするようです。実際には、（ntpd再起動しない限り）時計が数分間変更されず、突然すぐに見えるように設定されていることがわかりました。一方、ntpq出力の一番右の列は、同期が進行中であることを示します。
この動作は、おそらく動作しても動作しないと思うntpd理由を説明します。ntpd私は十分に長く待たず、ntpq結果を理解していませんでした。