VM avec ntpd en cours d'exécution mais pas de synchronisation

TL; DR

VM utilisant KVM, le time n'est pas synchronisé. Après 2 minutes de suspension, il garde un écart permanent de 2 minutes. La configuration d'une autre machine virtuelle avec une configuration réseau différente montre que la configuration réseau empêche le fonctionnement de ntp. La résolution de ce problème réseau est hors sujet.

Cependant, la nouvelle VM qui n'a pas le problème réseau ne se synchronise pas après un CV. Même test: suspendre 2 minutes. Vérifiez la différence de date avec une machine correctement synchronisée. Le timeout de 2 minutes est permanent.

Cela semble être un problème commun et il y a une controverse sur la façon de garder une machine virtuelle synchronisée, et sur l'utilisation de NTP et kvm-clock en même time. J'ai trouvé de nombreuses references à cela mais pas de réponse.

Question

J'ai une machine virtuelle Debian avec ntpd cours d'exécution mais pas de time de correction. Par exemple, après une suspension / reprise, j'obtiens un décalage permanent de 2 minutes.

/etc/ntp.conf est par défaut ou proche de la valeur par défaut, rien de fantaisiste:

 # /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/AccessRessortingctions> # might also be helpful. # # Note that "ressortingct" 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. ressortingct -4 default kod notrap nomodify nopeer noquery ressortingct -6 default kod notrap nomodify nopeer noquery # Local users may interrogate the ntp server more closely. ressortingct 127.0.0.1 ressortingct ::1 # Clients from this (example!) subnet have unlimited access, but only if # cryptographically authenticated. #ressortingct 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 listn 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 semble signaler un problème:

 # 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 

Cependant, je ne suis pas un assistant netcat, mais le trafic sortant AFAIU sur le port UDP 123 passe par:

 # nc -vvzu 37.187.7.160 123 mail.lafkor.de [37.187.7.160] 123 (ntp) open sent 0, rcvd 0 

Ce test est-il suffisant pour éliminer le problème du pare-feu?

L'hôte (également une machine Debian) a la même configuration NTP et la synchronisation fonctionne. La configuration réseau pour les deux machines est différente, c'est pourquoi je pense que cela pourrait être un problème de réseau.

Tout autre test utile je pourrais courir?

Je ne pense pas que le paramètre de tinker panic 0 du tinker panic 0 soit pertinent ici car il est censé forcer des mises à jour sur d'énormes lacunes, et non des écarts de 2 minutes. Et de toute façon, AFAIU, cela affecterait le comportement en cas de décalage temporel, mais cela ne résoudrait pas ntpq -pn returnnant seulement des zéros.

FWIW, d'autres résultats de test inspirés de cette question :

 # 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 

Tests tcpdump / ntpdate

Sur une machine où la synchronisation NTP fonctionne correctement, je lance tcpdump udp port ntp et quand je redémarre ntpd , je vois ce type de sortie:

 # tcpdump udp port ntp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listning 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 [...] 

Sur la machine, j'ai le problème avec, je ne vois aucune sortie lors du redémarrage de ntpd (pas de request, pas de réponse). Ne devrais-je pas au less voir les requests?

Sur la bonne machine:

 # ntpdate 0.debian.pool.ntp.org 29 Sep 17:24:49 ntpdate[700]: adjust time server 193.55.167.1 offset -0.005196 sec 

Sur la mauvaise machine:

 # ntpdate 0.debian.pool.ntp.org 29 Sep 17:43:18 ntpdate[3180]: no server suitable for synchronization found 

Testez avec une autre VM

Nous avons installé une autre VM avec la même configuration NTP mais une autre configuration réseau.

Les résultats de tcpdump et ntpdate sont corrects et ntpq -pn renvoie de bons résultats. Apparemment, la configuration réseau est en effet un problème sur la machine virtuelle défectueuse.

Cependant, la nouvelle machine virtuelle ne se synchronise pas non plus. Si je le suspends de sorte qu'il a un décalage de 100s environ, il ne se synchronise pas (je veux dire après quelques minutes, l'écart est toujours le même nombre de secondes). Cependant, lors du redémarrage de ntpd, il se synchronise instantanément.

Je semble avoir deux problèmes:

  • Configuration réseau sur la première machine virtuelle

  • ntp ne se synchronise pas sur les deux (sauf redémarrage)

Problème résolu.

Problème de réseau

La machine virtuelle avait des problèmes de réseau empêchant ntpd de réussir. Il a deux interfaces eth , et celui avec la passerelle passe par un routeur que nous ne gérons pas directement. Bien que mes tests ne le montrent pas, je suppose que certaines trames UDP ont été bloquées. Nous avons mis en place une autre machine virtuelle avec un autre réseau de configuration et ntpq donné de meilleurs résultats.

En fin de count, nous avons modifié la configuration ntp afin que l'hôte diffuse localement le time et que toutes les machines virtuelles s'y synchronisent. Cela a plus de sens et minimise la charge sur les servers publics ntp .

ntpd règle l'horloge instantanément après quelques minutes

Une chose qui me trompe probablement pendant les tests est que ntpd ne se synchronise pas immédiatement. Je pensais qu'il détecterait un écart tout de suite, puis modifierait la vitesse de l'horloge pour que l'horloge rejoigne progressivement l'horloge source. En fait, nous avons remarqué que (à less que ntpd soit redémarré) l'horloge est inchangée pendant quelques minutes, alors tout d'un coup, il est réglé ce qui semble instantanément. En attendant, les colonnes les plus à droite dans la sortie ntpq montrent que la synchronisation est en cours.

Ce comportement ntpd explique probablement pourquoi je pensais que ntpd ne fonctionnait pas même si c'était le cas. Je n'ai juste pas attendu assez longtime et je n'ai pas compris la sortie ntpq .