Proxmox VE : Configuration NTP avec chrony — Guide Complet 2026

La synchronisation temporelle est l'une de ces fondations invisibles d'une infrastructure virtualisée : tant qu'elle fonctionne, personne n'y pense ; dès qu'elle dérive, tout se met à casser de manière incompréhensible. Sur un hyperviseur Proxmox VE, l'horloge n'est pas un simple confort d'affichage dans les logs : elle conditionne la validité des certificats TLS de l'interface web, le fonctionnement de l'authentification à deux facteurs TOTP, la cohérence des snapshots et des sauvegardes Proxmox Backup Server, la corrélation des journaux entre nœuds, et la santé d'un cluster Ceph qui refusera de passer en état HEALTH_OK dès que quelques dizaines de millisecondes de dérive apparaissent entre les moniteurs. Ajoutez à cela les machines virtuelles et les containers LXC, dont l'horloge dépend directement ou indirectement de celle de l'hôte, et vous obtenez un point de défaillance unique capable de paralyser une plateforme entière. Ce guide complet détaille la configuration de chrony sur Proxmox VE 8 et 9, la bonne stratégie pour les invités, la vérification opérationnelle, le durcissement du service et les pratiques éprouvées en cluster.

Pourquoi NTP est essentiel sur Proxmox VE ?

Un serveur physique mesure le temps de deux façons : l'horloge matérielle (RTC, alimentée par la pile de la carte mère) qui survit aux redémarrages, et l'horloge système maintenue par le noyau Linux à partir d'une source de comptage à haute fréquence, généralement le TSC du processeur. Cette horloge système dérive naturellement. Une dérive de 20 à 50 parties par million est courante sur du matériel serveur, soit environ deux à quatre secondes par jour. Sur trois mois sans correction, un nœud peut accumuser plusieurs minutes d'écart. C'est largement suffisant pour rendre une infrastructure incohérente.

Les conséquences concrètes sur Proxmox VE sont nombreuses et rarement diagnostiquées du premier coup. L'authentification à deux facteurs par TOTP repose sur des fenêtres de trente secondes : un décalage de plus d'une minute et demie et tous les codes générés par les administrateurs sont rejetés, verrouillant potentiellement l'accès à l'interface d'administration. Les certificats émis via ACME et Let's Encrypt sont refusés si l'horloge du nœud se situe hors de leur période de validité. Le système de fichiers en cluster pmxcfs et les mécanismes de réplication ZFS s'appuient sur des horodatages pour arbitrer les versions des fichiers de configuration. Les tâches planifiées de sauvegarde se déclenchent au mauvais moment, voire deux fois.

Du point de vue de la sécurité, la question est encore plus sensible. Toute investigation post-incident repose sur la capacité à ordonner les événements provenant de sources hétérogènes : journaux de l'hyperviseur, logs applicatifs des VMs, alertes de l'EDR, flux réseau du pare-feu. Si les horloges divergent, la reconstruction de la chronologie d'attaque devient un exercice de spéculation. C'est un point systématiquement souligné dans les référentiels de conformité comme la directive NIS 2, l'ISO/IEC 27001 ou le PCI DSS, qui exigent explicitement une source de temps de référence unique et documentée. Les outils d'analyse et de corrélation que nous détaillons dans notre comparatif des solutions EDR perdent une grande partie de leur valeur sur un parc désynchronisé. Enfin, l'authentification Kerberos en environnement Active Directory rejette tout ticket dont l'horodatage s'écarte de plus de cinq minutes, un mécanisme anti-rejeu que l'on rencontre immédiatement lorsqu'on manipule les outils décrits dans notre article sur BloodHound, SharpHound et BloodyAD.

Prérequis et architecture NTP recommandée

Avant toute configuration, il faut décider de l'architecture. Trois modèles se rencontrent en production, avec des compromis très différents. Le premier consiste à laisser chaque nœud Proxmox interroger directement des pools publics sur Internet. C'est le comportement par défaut après installation et il convient parfaitement à un laboratoire ou à un hôte isolé. Ses limites apparaissent en environnement contraint : dépendance à un accès Internet sortant en UDP/123, absence de maîtrise sur les serveurs interrogés, et impossibilité de garantir que tous les nœuds convergent vers exactement la même référence.

Le deuxième modèle, recommandé dès qu'on dépasse deux ou trois hyperviseurs, place deux à quatre serveurs NTP internes en strate 2 ou 3, qui se synchronisent en amont sur des sources publiques ou sur un boîtier GPS, et qui servent de référence unique à l'ensemble du datacenter. Les nœuds Proxmox, les VMs, les équipements réseau et les contrôleurs de domaine pointent tous vers ces serveurs. L'avantage est double : cohérence garantie et surface d'exposition réduite, puisque seuls les serveurs NTP internes ont besoin de sortir vers Internet.

Le troisième modèle ajoute une source de temps physique, typiquement un récepteur GNSS relié en PPS, pour les environnements où la traçabilité temporelle est réglementée : horodatage qualifié, finance, industrie. Il est rarement nécessaire pour de la virtualisation généraliste mais devient incontournable dès qu'on doit prouver une exactitude à la milliseconde.

Quelle que soit l'option retenue, respectez trois règles de dimensionnement. Configurez toujours au minimum quatre sources : avec une seule source, aucune détection d'erreur n'est possible ; avec deux, un désaccord est indécidable ; avec trois, une source défaillante peut encore fausser le vote ; à partir de quatre, l'algorithme de sélection isole correctement un falseticker. Ne mélangez jamais des sources de strates très hétérogènes sans intention claire, sous peine de voir chrony osciller entre elles. Et assurez-vous que le flux UDP/123 sortant est autorisé sur le pare-feu du datacenter Proxmox comme sur l'équipement périmétrique, en vérifiant qu'aucun équipement intermédiaire ne réécrit le trafic NTP, pratique encore répandue sur certains routeurs grand public.

Côté matériel, vérifiez que la pile CMOS des serveurs est fonctionnelle. Une pile morte fait repartir le RTC à une date arbitraire au démarrage, ce qui produit exactement le scénario le plus difficile à corriger : un nœud qui redémarre avec plusieurs années d'écart et dont les certificats sont considérés comme non encore valides.

Configuration de chrony sur Proxmox VE 8 et 9

Depuis Proxmox VE 7, l'installateur déploie chrony comme démon de synchronisation par défaut, en remplacement de systemd-timesyncd. Proxmox VE 8 s'appuie sur Debian 12 et chrony 4.3 ; Proxmox VE 9 s'appuie sur Debian 13 et embarque une version 4.6 ou supérieure, qui apporte notamment un support NTS plus mature. Attention toutefois : un hôte issu d'une mise à niveau successive depuis une ancienne version peut avoir conservé systemd-timesyncd, voire l'ancien ntpd. La première étape consiste donc à faire l'inventaire de l'existant.

timedatectl status
systemctl is-active chrony systemd-timesyncd ntp ntpsec
dpkg -l | grep -E 'chrony|ntp'

Deux démons NTP actifs simultanément se disputent l'horloge système et produisent des corrections erratiques. Si systemd-timesyncd est présent, désactivez-le explicitement avant d'installer chrony. Le masquage évite toute réactivation par une dépendance ultérieure.

apt update
apt install -y chrony
systemctl disable --now systemd-timesyncd
systemctl mask systemd-timesyncd
systemctl enable --now chrony

Le fichier principal se trouve dans /etc/chrony/chrony.conf sur Debian. Plutôt que de le modifier directement, ce qui provoque des conflits lors des mises à jour du paquet, exploitez le mécanisme de répertoire de sources : la directive sourcedir /etc/chrony/sources.d est déjà présente et permet de déposer vos propres définitions dans un fichier séparé, rechargeable à chaud avec chronyc reload sources.

cat > /etc/chrony/sources.d/local-ntp.sources <<'EOF'
server ntp1.interne.lan iburst minpoll 4 maxpoll 8
server ntp2.interne.lan iburst minpoll 4 maxpoll 8
pool fr.pool.ntp.org iburst maxsources 3
EOF

chronyc reload sources

Fichier /etc/chrony.conf : directives essentielles pour Proxmox

Si vous préférez une configuration entièrement maîtrisée, commentez la ligne pool par défaut de Debian dans /etc/chrony/chrony.conf puis complétez le fichier avec les directives suivantes, dont chacune répond à un besoin précis sur un hyperviseur.

# Corrige immédiatement un écart > 1 s lors des 3 premières mesures
makestep 1.0 3

# Recopie l'heure système vers le RTC : le nœud redémarre à l'heure
rtcsync

# Suivi de la dérive matérielle, accélère la convergence après reboot
driftfile /var/lib/chrony/chrony.drift

# Journalise mesures, statistiques et ajustements
logdir /var/log/chrony
log measurements statistics tracking

# Ne pas se déclarer serveur si le nœud est purement client
port 0
cmdport 0

La directive makestep 1.0 3 mérite une explication. Par défaut, chrony corrige l'horloge par ajustement progressif de sa fréquence — le slewing — afin de ne jamais faire reculer le temps, ce qui casserait les bases de données et les systèmes de fichiers. Mais après un long arrêt, rattraper plusieurs minutes à raison de quelques millisecondes par seconde prendrait des heures. Autoriser un saut brutal lors des trois premières mesures permet une convergence immédiate au démarrage tout en conservant un comportement monotone en régime établi. Sur un hyperviseur, ce compromis est presque toujours le bon. Appliquez ensuite la configuration et fixez le fuseau horaire du nœud, en privilégiant UTC sur les infrastructures multi-sites.

timedatectl set-timezone Europe/Paris
systemctl restart chrony
chronyc tracking

La documentation officielle de l'hyperviseur détaille les spécificités de l'intégration dans le manuel administrateur Proxmox VE, et l'ensemble des directives disponibles est décrit dans la documentation du projet chrony.

Configurer les VMs et containers LXC comme clients NTP

C'est ici que se concentrent la majorité des erreurs de configuration, parce que VMs et containers ne suivent pas du tout la même logique. La distinction est fondamentale et découle de l'architecture même de la virtualisation sous Linux.

Containers LXC Proxmox : synchronisation sans démon NTP

Un container LXC partage le noyau de l'hôte. Il n'existe pas de namespace de temps permettant à un container d'avoir sa propre horloge murale : l'heure vue à l'intérieur est celle de l'hôte, point final. De surcroît, un container non privilégié — le mode par défaut et recommandé sur Proxmox VE — ne dispose pas de la capacité CAP_SYS_TIME, ce qui lui interdit formellement toute modification de l'horloge système.

La conséquence pratique est simple : n'installez jamais chrony ou ntpd dans un container LXC. Le démon démarrera, tentera d'ajuster l'horloge, échouera avec des erreurs Operation not permitted ou adjtimex() failed, et polluera les journaux sans le moindre bénéfice. Si un modèle de container en embarque un par défaut, neutralisez-le proprement.

pct exec 105 -- systemctl disable --now chrony
pct exec 105 -- systemctl mask chrony systemd-timesyncd

Le seul réglage réellement utile dans un container est le fuseau horaire, qui n'affecte que l'affichage local et reste parfaitement autorisé sans privilège particulier : pct exec 105 -- timedatectl set-timezone Europe/Paris. Synchronisez l'hôte correctement et les containers le sont automatiquement.

Machines virtuelles KVM : installer chrony dans chaque invité

Une VM QEMU/KVM possède en revanche son propre noyau et sa propre horloge système, qui dérive indépendamment. Elle doit donc exécuter son propre démon de synchronisation. Sur les invités Linux modernes, QEMU expose une source d'horloge paravirtualisée, kvm-clock, qui limite fortement la dérive en lisant le temps directement depuis l'hôte sans sortie coûteuse de l'hyperviseur. Vérifiez qu'elle est bien active dans l'invité.

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
# attendu : kvm-clock

kvm-clock ne remplace toutefois pas NTP : elle réduit la dérive, elle ne corrige pas un décalage absolu et ne survit pas à une suspension prolongée ou à une migration à chaud. Installez donc chrony dans chaque VM Linux, en pointant vers les mêmes serveurs internes que les hyperviseurs. Installez également l'agent invité QEMU (qemu-guest-agent), qui permet à l'hôte de notifier l'invité après une restauration de snapshot ou une reprise, déclenchant une resynchronisation immédiate.

Pour les invités Windows, conservez le service W32Time et pointez-le vers vos serveurs internes, ou laissez les contrôleurs de domaine jouer leur rôle hiérarchique habituel. Un point de configuration Proxmox mérite attention : la façon dont l'horloge matérielle virtuelle est interprétée. Les invités Linux attendent un RTC en UTC, les invités Windows un RTC en heure locale.

qm set 110 --localtime 0   # invité Linux : RTC en UTC
qm set 120 --localtime 1   # invité Windows : RTC en heure locale

Une erreur sur ce paramètre produit un décalage systématique et constant, exactement égal au décalage horaire du fuseau, qui réapparaît à chaque redémarrage de la VM même si NTP fonctionne parfaitement à l'intérieur.

Vérification et monitoring de la synchronisation NTP

Une configuration NTP n'est jamais validée par le simple fait que le service démarre. Trois commandes constituent la base du diagnostic, et il faut savoir lire leur sortie. chronyc tracking donne l'état de synchronisation global du nœud.

chronyc tracking

Reference ID    : C0A80A05 (ntp1.interne.lan)
Stratum         : 3
Ref time (UTC)  : Sun Aug 23 08:14:22 2026
System time     : 0.000041237 seconds slow of NTP time
Last offset     : -0.000012884 seconds
RMS offset      : 0.000038119 seconds
Frequency       : 12.447 ppm slow
Skew            : 0.061 ppm
Root delay      : 0.004182 seconds
Root dispersion : 0.000913 seconds
Leap status     : Normal

Les champs déterminants sont System time, qui doit rester bien en dessous de la milliseconde sur un réseau local, Skew, qui mesure l'incertitude sur la fréquence et doit être faible et stable, et surtout Leap status, qui doit indiquer Normal. Une valeur Not synchronised signifie que chrony tourne mais n'a retenu aucune source valide : le service est actif et l'horloge pourtant abandonnée à sa dérive, situation trompeuse pour une supervision naïve basée sur systemctl is-active.

chronyc sources -v détaille chaque source et son état. Le caractère en début de ligne est la clé de lecture : * désigne la source actuellement sélectionnée, + une source acceptable combinée à la précédente, - une source exclue par l'algorithme de combinaison, x un falseticker dont l'intervalle est incompatible avec la majorité, et ? une source injoignable. Une ligne x persistante trahit un serveur défaillant qu'il faut retirer. chronyc sourcestats complète l'analyse en exposant la régression linéaire calculée pour chaque source, particulièrement utile pour repérer un serveur au comportement instable.

Pour la supervision continue, plusieurs approches se combinent. La plus simple consiste à exposer les métriques via un exporteur Prometheus dédié, ou à écrire une sonde qui compare la valeur absolue de l'offset à un seuil. Un contrôle robuste vérifie trois conditions simultanément : le service est actif, Leap status vaut Normal, et l'offset absolu reste inférieur à 100 millisecondes.

#!/bin/bash
# /usr/local/bin/check-ntp.sh
LEAP=$(chronyc tracking | awk -F': ' '/Leap status/ {print $2}')
OFFSET=$(chronyc tracking | awk -F': ' '/System time/ {print $2}' | awk '{print $1}')
SEUIL=0.1

if [ "$LEAP" != "Normal" ]; then
  echo "CRITICAL - chrony non synchronisé (leap=$LEAP)"; exit 2
fi
if awk -v o="$OFFSET" -v s="$SEUIL" 'BEGIN{exit !(o>s)}'; then
  echo "WARNING - offset $OFFSET s au-dessus du seuil"; exit 1
fi
echo "OK - offset $OFFSET s"; exit 0

Sur un cluster, ajoutez un contrôle transverse qui compare les nœuds entre eux plutôt que chacun à sa référence : deux nœuds synchronisés sur des sources différentes peuvent tous deux se déclarer sains tout en divergeant l'un de l'autre. La méthodologie de supervision et les outils associés sont détaillés dans notre panorama des outils d'audit d'infrastructure.

Intégrer la supervision NTP dans Zabbix et Prometheus

Une vérification manuelle ponctuelle ne suffit pas en production : l'horloge peut dériver entre deux contrôles ou se décrocher silencieusement si toutes les sources NTP deviennent inaccessibles simultanément. L'intégration dans un outil de supervision existant fournit une alerte temps réel. Zabbix dispose d'un modèle NTP natif qui surveille le décalage système, le stratum et le statut de synchronisation. Pour Prometheus, l'exporteur prometheus-ntp-exporter expose ces métriques au format OpenMetrics ; une alerte Alertmanager se déclenche dès que ntp_offset_seconds dépasse 100 ms ou que ntp_stratum remonte au-dessus de 5.

# Vérification rapide via Zabbix agent
zabbix_get -s 127.0.0.1 -k system.localtime

# Métriques Prometheus (si prometheus-ntp-exporter installé)
curl -s localhost:9559/metrics | grep ntp_

Résolution des problèmes NTP courants sur Proxmox

Le symptôme le plus fréquent est un chronyc tracking qui affiche Not synchronised alors que le service tourne depuis des heures. La cause est presque toujours un blocage du trafic UDP/123 sortant. Vérifiez d'abord la joignabilité applicative avec chronyc ntpdata, qui indique le nombre de paquets émis et reçus par source. Si les paquets partent sans réponse, le problème est réseau. Contrôlez le pare-feu Proxmox au niveau du datacenter et du nœud, puis les règles de l'équipement périmétrique. Un test direct lève le doute rapidement.

chronyc -N sources -v
chronyc ntpdata
apt install -y ntpdate && ntpdate -q ntp1.interne.lan

Deuxième cas classique : un nœud dont l'horloge saute brutalement après un redémarrage ou une coupure d'alimentation. Si le décalage se chiffre en années, suspectez immédiatement la pile CMOS. Si le décalage est d'exactement une ou deux heures, il s'agit d'une incohérence entre le RTC et le fuseau horaire, corrigeable avec timedatectl set-local-rtc 0 sur l'hôte. Si le décalage persiste malgré chrony actif, c'est que makestep n'est pas configuré et que le démon refuse de corriger un écart trop important : une correction manuelle immédiate est alors possible avec chronyc makestep.

Troisième cas : une VM dont l'heure dérive uniquement après une migration à chaud ou une restauration de snapshot. Le phénomène est normal, l'invité ayant été suspendu pendant que le temps réel continuait de s'écouler. La correction passe par l'agent invité QEMU, qui reçoit la notification de reprise et déclenche une resynchronisation. Vérifiez que l'option est bien activée pour la VM avec qm set 110 --agent enabled=1 et que le service qemu-guest-agent tourne à l'intérieur.

Quatrième cas, spécifique aux containers : des messages d'erreur récurrents adjtimex() failed ou Could not step system clock dans le journal d'un LXC. Il ne s'agit pas d'un dysfonctionnement à corriger mais de la conséquence attendue de l'absence de CAP_SYS_TIME. La solution est de désinstaller ou masquer le démon dans le container, comme décrit plus haut.

Cinquième cas, plus insidieux : une dérive importante et erratique sur un hôte fortement chargé, avec un Skew élevé. Vérifiez la source d'horloge du noyau avec cat /sys/devices/system/clocksource/clocksource0/current_clocksource. Si la valeur est hpet ou acpi_pm au lieu de tsc, le noyau a disqualifié le TSC, souvent à cause d'un firmware ou d'une gestion d'énergie agressive. Une mise à jour du BIOS et la désactivation des états C profonds règlent généralement le problème. Enfin, gardez à l'esprit qu'un décalage temporel peut être le symptôme d'une compromission : la manipulation d'horloge et l'effacement d'horodatages sont des techniques d'anti-forensique documentées, un sujet que nous abordons dans notre article sur les idées reçues en cybersécurité vues par un pentester.

Sécuriser le service NTP

NTP a longtemps été un vecteur d'attaque de premier plan, principalement par amplification : le protocole répond en UDP, sans état, et certaines requêtes de contrôle historiques de ntpd renvoyaient une réponse bien plus volumineuse que la requête, offrant des facteurs d'amplification considérables pour des attaques par déni de service distribué. Chrony n'implémente pas ces commandes vulnérables, ce qui constitue déjà une amélioration structurelle, mais plusieurs mesures de durcissement restent indispensables.

La première est le principe de moindre exposition. Un hyperviseur Proxmox est un client NTP, pas un serveur. Ajoutez port 0 à la configuration pour que chrony n'écoute sur aucun port NTP entrant, et cmdport 0 pour désactiver l'écoute du port de commande 323. Les commandes locales chronyc continuent de fonctionner via la socket Unix /run/chrony/chronyd.sock, sans aucune exposition réseau.

Si un nœud doit malgré tout servir de référence à un sous-réseau, restreignez explicitement les clients autorisés et désactivez la journalisation par client, qui consomme de la mémoire et facilite l'énumération.

allow 10.20.0.0/16
deny all
noclientlog
ratelimit interval 3 burst 8 leak 2

La mesure la plus significative est cependant l'adoption de NTS (Network Time Security), normalisé par la RFC 8915. NTP en clair n'offre aucune authentification : un attaquant en position d'interception peut altérer les réponses et décaler progressivement l'horloge d'une cible, ce qui permet notamment de réactiver des certificats révoqués ou d'invalider des mécanismes anti-rejeu. NTS ajoute une négociation TLS sur le port 4460 pour établir des clés, puis authentifie chaque paquet NTP. Chrony 4.x prend NTS en charge nativement, ce qui rend son activation triviale sur Proxmox VE 8 comme sur Proxmox VE 9.

cat > /etc/chrony/sources.d/nts.sources <<'EOF'
server time.cloudflare.com iburst nts
server ptbtime1.ptb.de iburst nts
server nts.netnod.se iburst nts
EOF

# Répertoire de persistance des clés de session NTS
mkdir -p /var/lib/chrony
chown _chrony:_chrony /var/lib/chrony

chronyc reload sources
chronyc authdata

La commande chronyc authdata confirme l'établissement des sessions : la colonne Mode doit afficher NTS et la colonne KeyID une valeur non nulle. Notez qu'un serveur NTS exige que l'horloge du client soit déjà approximativement juste pour valider le certificat TLS, ce qui crée une dépendance circulaire au premier démarrage sur un nœud dont le RTC est aberrant ; la directive nocerttimecheck 1 permet de contourner ce blocage lors des premières mises à jour, à retirer ensuite. Complétez enfin par une restriction au niveau du pare-feu du datacenter Proxmox, en n'autorisant l'UDP/123 sortant que vers les serveurs explicitement listés. Ces principes de segmentation et de durcissement font partie du socle technique évalué dans les certifications que nous détaillons dans notre guide des certifications cybersécurité OSCP et CISSP.

NTP en cluster Proxmox : bonnes pratiques

En cluster, la synchronisation cesse d'être une hygiène pour devenir une condition de fonctionnement. Il faut cependant être précis sur ce qui dépend réellement de l'heure murale, car la littérature entretient une confusion tenace. Corosync, le moteur de communication du cluster, utilise des minuteurs monotones pour ses jetons et ses délais : un décalage d'horloge murale ne provoque pas directement de perte de quorum. Ce qui casse, en revanche, est nombreux et bien réel.

Ceph est le cas le plus visible. Les moniteurs Ceph vérifient en permanence l'écart entre eux et lèvent un avertissement MON_CLOCK_SKEW dès que la dérive dépasse le seuil mon clock drift allowed, fixé par défaut à 50 millisecondes. Le cluster de stockage sort alors de l'état HEALTH_OK, ce qui masque potentiellement d'autres alertes et bloque certaines opérations de maintenance. Sur un cluster Proxmox hyperconvergé, c'est le symptôme numéro un d'un problème NTP. La bonne réaction n'est jamais d'augmenter le seuil, mais de corriger la synchronisation.

Les autres impacts sont tout aussi concrets : la réplication ZFS entre nœuds s'appuie sur des horodatages pour nommer et ordonner les instantanés ; la haute disponibilité et son gestionnaire de ressources produisent des journaux dont l'analyse croisée devient impossible en cas de bascule si les horloges divergent ; les tâches de sauvegarde planifiées au datacenter se déclenchent à des instants différents selon les nœuds ; et l'authentification TOTP échoue de manière intermittente selon le nœud qui traite la requête, produisant un comportement en apparence aléatoire particulièrement déroutant.

Quatre règles s'imposent donc. Premièrement, tous les nœuds du cluster doivent utiliser exactement la même liste de serveurs NTP, dans le même ordre. Des sources différentes, même toutes correctes, introduisent des écarts relatifs de quelques millisecondes qui suffisent à déclencher les alertes Ceph. Deuxièmement, ces serveurs doivent être internes et redondants : dépendre d'un pool public expose le cluster à la variabilité de la latence Internet. Troisièmement, validez la cohérence après chaque ajout de nœud, avec une boucle simple exécutée depuis un membre du cluster.

for n in $(pvecm nodes | awk '/^ *[0-9]/ {print $3}'); do
  printf "%-20s " "$n"
  ssh -o BatchMode=yes "$n" "chronyc tracking | awk -F': ' '/System time/ {print \$2}'"
done

Quatrièmement, intégrez le contrôle NTP à vos procédures de maintenance. Avant toute mise à jour de nœud, toute intervention sur Ceph ou toute opération de migration massive, vérifiez que l'ensemble du cluster est synchronisé. Un nœud remis en service après un long arrêt, avec un RTC dérivé et une correction par slewing qui prendra plusieurs heures, est un candidat idéal à l'incident. Forcez la convergence immédiate avec chronyc makestep avant de le réintégrer aux opérations de production.

Automatiser le déploiement NTP avec Ansible

Sur un parc de plus de trois hyperviseurs, la configuration manuelle garantit à terme une divergence entre nœuds. L'automatisation par gestion de configuration règle simultanément le déploiement initial, la conformité continue et la documentation de l'état attendu. Un rôle Ansible minimal suffit à couvrir les besoins décrits dans ce guide.

- name: Synchronisation temporelle des nœuds Proxmox
  hosts: proxmox
  become: true
  vars:
    ntp_servers:
      - ntp1.interne.lan
      - ntp2.interne.lan
  tasks:
    - name: Installer chrony
      apt: { name: chrony, state: present, update_cache: yes }

    - name: Neutraliser systemd-timesyncd
      systemd: { name: systemd-timesyncd, enabled: no, state: stopped, masked: yes }
      ignore_errors: true

    - name: Déployer les sources NTP
      template:
        src: local-ntp.sources.j2
        dest: /etc/chrony/sources.d/local-ntp.sources
        owner: root
        mode: '0644'
      notify: restart chrony

    - name: Activer chrony
      systemd: { name: chrony, enabled: yes, state: started }

  handlers:
    - name: restart chrony
      systemd: { name: chrony, state: restarted }

Ajoutez une tâche de vérification post-déploiement qui échoue si Leap status n'est pas Normal après un délai de convergence, et exécutez le playbook périodiquement en mode contrôle pour détecter toute dérive de configuration. Le même principe s'applique aux VMs via un groupe d'inventaire distinct, en excluant explicitement les containers LXC, qui ne doivent recevoir que le réglage de fuseau horaire.

Questions fréquentes sur la configuration NTP sur Proxmox VE

Faut-il installer chrony dans les containers LXC de Proxmox ?

Non, et c'est même contre-productif. Un container LXC partage le noyau de l'hôte Proxmox et ne dispose donc pas d'une horloge système indépendante : l'heure qu'il affiche est celle de l'hyperviseur. De plus, les containers non privilégiés — le mode par défaut sur Proxmox VE — ne possèdent pas la capacité CAP_SYS_TIME, ce qui leur interdit toute modification de l'horloge. Un démon NTP installé dans ce contexte échouera systématiquement avec des erreurs adjtimex() failed et remplira les journaux sans effet utile. La bonne pratique consiste à masquer tout démon présent dans le modèle de container et à ne configurer que le fuseau horaire via timedatectl set-timezone, qui n'affecte que l'affichage local et fonctionne sans privilège.

Quelle différence entre chrony et systemd-timesyncd sur Proxmox VE ?

systemd-timesyncd est un client SNTP minimaliste : il interroge une seule source à la fois, n'implémente pas les algorithmes de sélection et de filtrage de NTP, ne gère pas la discipline fine de fréquence et ne peut pas servir de serveur. C'est acceptable pour un poste de travail, insuffisant pour un hyperviseur. Chrony implémente le protocole NTP complet, sélectionne la meilleure combinaison parmi plusieurs sources, détecte et exclut les serveurs incohérents, corrige la fréquence de l'horloge en plus de son offset, converge beaucoup plus vite après un redémarrage grâce au fichier de dérive, et supporte NTS. C'est la raison pour laquelle Proxmox l'a adopté comme démon par défaut depuis la version 7. Ne faites jamais tourner les deux simultanément.

Comment vérifier si un nœud Proxmox est correctement synchronisé ?

La commande de référence est chronyc tracking. Trois éléments doivent être contrôlés : le champ Leap status doit valoir Normal, le champ System time doit indiquer un écart inférieur à quelques millisecondes sur un réseau local, et le champ Reference ID doit désigner un serveur attendu et non 127.127.1.1, qui signalerait un repli sur l'horloge locale. Complétez avec chronyc sources -v pour confirmer qu'au moins une source porte le marqueur *. Attention au piège classique : systemctl is-active chrony peut renvoyer active sur un nœud totalement désynchronisé. Une supervision fiable doit contrôler l'offset réel, pas seulement l'état du service.

Problèmes courants de dérive temporelle : FAQ avancée

Pourquoi l'heure de mes VMs dérive-t-elle après une migration à chaud ?

Pendant une migration à chaud, la machine virtuelle est brièvement suspendue le temps du basculement, puis reprend sur l'hôte de destination. Le temps réel a continué de s'écouler pendant cette suspension, mais l'horloge de l'invité, elle, était figée. Le décalage résultant est généralement de l'ordre de la seconde, davantage sur des VMs très volumineuses ou un réseau de migration saturé. La solution consiste à installer et activer qemu-guest-agent dans l'invité, puis à autoriser l'agent au niveau de la VM avec qm set <vmid> --agent enabled=1. L'hôte notifie alors l'invité de la reprise, ce qui déclenche une resynchronisation immédiate de chrony. Le même mécanisme corrige le décalage après restauration d'un snapshot.

Faut-il activer NTS sur un hyperviseur Proxmox en production ?

Oui dès que les serveurs NTP interrogés sont accessibles via un réseau non maîtrisé, typiquement Internet. NTP en clair n'authentifie rien : un attaquant capable d'intercepter le trafic peut manipuler progressivement l'horloge d'un hyperviseur pour réactiver des certificats révoqués, invalider des protections anti-rejeu ou fausser des journaux d'audit. NTS résout ce problème en établissant des clés via TLS puis en authentifiant chaque paquet. Chrony 4.x le supporte nativement sur Proxmox VE 8 comme sur Proxmox VE 9, et l'activation se limite à ajouter le mot-clé nts sur les lignes server. En revanche, si vos sources sont des serveurs internes situés sur un segment réseau de confiance et contrôlé, NTS apporte un bénéfice marginal ; concentrez alors l'effort sur les serveurs internes eux-mêmes, qui doivent utiliser NTS vers l'extérieur.

Que faire si Ceph signale une erreur clock skew sur un cluster Proxmox ?

L'avertissement MON_CLOCK_SKEW apparaît lorsque l'écart entre deux moniteurs Ceph dépasse le seuil mon clock drift allowed, fixé par défaut à 50 millisecondes. La réaction correcte n'est jamais d'augmenter ce seuil, qui n'est pas arbitraire mais dimensionné pour les mécanismes de consensus du stockage. Identifiez d'abord le nœud fautif en comparant la sortie de chronyc tracking sur chaque membre. Dans la grande majorité des cas, la cause est une divergence de configuration : un nœud interroge des sources différentes des autres, ou son service chrony a été arrêté lors d'une maintenance sans être relancé. Alignez la liste des serveurs NTP sur tous les nœuds, redémarrez chrony, forcez la convergence immédiate avec chronyc makestep, puis attendez quelques minutes que Ceph efface l'alerte. Si le problème réapparaît sur le même nœud, examinez la source d'horloge du noyau et la pile CMOS de la machine.