Héberger un NTP public sur une VM Proxmox : bonne ou mauvaise idée ?
Le temps est un pilier silencieux de toute infrastructure : TLS, logs, réplication, Kerberos — tout repose sur une horloge fiable. Chez RDEM Systems, nous opérons un pool NTP public , dont une partie tourne en VM Proxmox. Voici notre retour d'expérience.
Le clock drift en VM : pourquoi ça dérive
Sur un serveur bare-metal, l'OS a un accès direct à l'horloge matérielle (RTC, TSC). En VM, c'est différent : l'hyperviseur virtualise l'horloge. Le CPU est partagé entre plusieurs VM, et chacune ne reçoit ses cycles que par tranches. Résultat : l'horloge de la VM peut dériver.
Bare-metal vs VM : accès à l'horloge
Bare-metal
Machine virtuelle
Les facteurs principaux de dérive en VM : steal time (CPU partagé), live migration (pause de la VM), et suspension/reprise.
Ce clock drift est gérable pour la plupart des usages — à condition d'utiliser le bon outil de synchronisation.
Pour comprendre les impacts concrets d'une horloge desynchronisee, consultez notre article Pourquoi la precision NTP est critique en environnement virtualise : certificats TLS invalides, echecs Kerberos, corruption de replicas — les consequences sont bien reelles.
Chrony vs ntpd vs systemd-timesyncd
Trois démons NTP coexistent dans l'écosystème Linux. Leur comportement en VM diffère fortement.
| Critère | Chrony | ntpd | timesyncd |
|---|---|---|---|
| Resync après suspension | Rapide | Lent (minutes) | Moyen |
| Mode serveur NTP | Oui | Oui | Non |
| Saut de temps (makestep) | Natif | -g flag | N/A |
| Mode burst | iburst | iburst | Non |
| NTS (Network Time Security) | Oui | Non | Non |
| Adapté aux VM | Excellent | Passable | Client seul |
Verdict : Pour un serveur NTP en VM, Chrony est le choix évident. Il a été conçu pour les environnements où l'horloge dérive (VM, laptops, conteneurs). Il se resynchronise en secondes après une live migration, là où ntpd peut mettre plusieurs minutes. De plus, Chrony est le seul à supporter NTS (Network Time Security) , la sécurisation du protocole NTP.
Configuration Chrony optimale pour un NTP public en VM
Voici une configuration /etc/chrony/chrony.conf adaptée à un serveur NTP public hébergé en VM Proxmox. Chaque directive est commentée.
La directive clé pour les VM est makestep 0.1 5 : elle autorise Chrony à corriger brutalement l'horloge si l'écart dépasse 100ms pendant les premiers échanges — typiquement après un reboot, une migration ou une suspension.
Consultez ntp.rdem-systems.com pour voir notre pool NTP public en production, alimenté par cette configuration.
VM vs LXC vs bare-metal pour héberger du NTP
Le choix du type d'hébergement impacte directement la qualité du service NTP. Voici un comparatif :
| Critère | VM (KVM) | LXC | Bare-metal |
|---|---|---|---|
| Horloge | Virtuelle (kvm-clock) | Partagée avec le host | Matérielle directe |
| Chrony indépendant | Oui | Non (horloge host) | Oui |
| Accès PPS / GPS | Non | Non | Oui |
| Précision typique | ~0.5–2 ms | = précision du host | < 1 µs (avec PPS) |
| Stratum recommandé | 2 ou 3 | Pas adapté (pas de contrôle) | 1 (avec GNSS) |
| Live migration | Cause un saut | N/A | N/A |
| Isolation | Complète | Partielle | Complète |
Pourquoi pas LXC ?
Un conteneur LXC partage l'horloge du host : il ne peut pas exécuter son propre démon NTP de manière indépendante. Si le host dérive, le conteneur dérive aussi. Pour servir du NTP à des clients externes, il faut une horloge que vous contrôlez — donc une VM ou du bare-metal.
Le verdict honnête
VM Proxmox : parfait pour Stratum 2/3
- Précision ~1 ms — suffisante pour 99% des usages
- TLS, Kerberos, logs, réplication : aucun problème
- Chrony compense le clock drift automatiquement
- Facilement redondant (plusieurs VM sur différents hosts)
Bare-metal : obligatoire pour Stratum 1
- Accès direct au récepteur GNSS (GPS, Galileo)
- Signal PPS via GPIO ou port série
- Précision sub-microseconde requise
- Interruptions matérielles sans virtualisation
Notre expérience : le pool NTP RDEM Systems
Chez RDEM Systems, nous opérons un pool NTP public qui combine les deux approches :
Architecture du pool ntp.rdem-systems.com
Raspberry Pi + GNSS
VM Proxmox + Chrony
Le Stratum 1 fournit la référence temporelle absolue. Les relais Stratum 2 en VM distribuent l'heure aux clients.
Cette architecture hybride nous permet de combiner la précision absolue du bare-metal GNSS avec la flexibilité et la redondance des VM Proxmox.
Vous pouvez vérifier la synchronisation de votre machine directement depuis notre site. Et pour la sécurisation NTP, consultez notre page sur NTS (Network Time Security) .
Bonnes pratiques pour NTP en VM Proxmox
Checklist opérationnelle
- Installer qemu-guest-agent dans la VM : permet à Proxmox de communiquer avec la VM (fsfreeze, shutdown propre)
- Chrony sur le host aussi : l'hyperviseur Proxmox doit lui-même être synchronisé — l'horloge matérielle fiable bénéficie à toutes les VM
- Monitorer l'offset : surveillez
chronyc tracking— un offset > 10ms est un signal d'alerte - Sources NTP fiables : privilégiez des Stratum 1 connus (PTB, NIST, votre propre GNSS) plutôt que le pool public seul
- Minimum 3 sources : Chrony peut détecter et exclure une source défaillante avec au moins 3 serveurs upstream
- Polling agressif en VM :
minpoll 4 maxpoll 6(16s–64s) compense le drift plus fréquent - Tester après live migration : vérifiez que Chrony se resynchronise en quelques secondes après un déplacement de VM
Tableau récapitulatif
| Scénario | Recommandation |
|---|---|
| NTP Stratum 2/3 public | VM Proxmox + Chrony — fiable et flexible |
| NTP Stratum 1 GNSS | Bare-metal obligatoire — accès PPS requis |
| NTP interne d'entreprise | VM largement suffisante |
| Trading haute fréquence | Bare-metal + PTP — précision sub-µs |
| Client NTP simple | VM, LXC ou bare-metal — tout convient |
| Démon NTP en LXC | Déconseillé — horloge partagée avec le host |
Questions fréquentes
Documentation officielle
Pour approfondir les concepts abordés dans cet article :
Articles connexes
Notre stratégie de sauvegarde 3-2-1
PBS, déduplication, verify jobs et protection ransomware sur 4 datacenters.
Migrer de VMware à Proxmox
Guide complet : méthodologie, outils et pièges à éviter.
Proxmox infogéré par RDEM Systems
Supervision, sauvegardes, mises à jour — on gère votre infrastructure.
Besoin d'une infra Proxmox synchronisée ?
Nous déployons et supervisons des serveurs NTP, configurons Chrony sur vos clusters Proxmox, et opérons un pool NTP public que vous pouvez utiliser librement.