Pourquoi NTP reste nécessaire dans les machines virtuelles malgré les agents invités et les horloges paravirtualisées

Ce que c'est

Plusieurs mécanismes influent sur la notion du temps d'un invité dans une VM. Sous KVM, la documentation du noyau sur la gestion du temps décrit kvmclock (kvmclock/kvm-clock) comme une source d'horloge (clocksource) paravirtualisée que le noyau invité peut utiliser au lieu d'émuler une horloge matérielle par logiciel. Cela réduit la dérive et la surcharge dues à l'interception et à l'émulation du matériel de temporisation. QEMU propose par ailleurs le QEMU Guest Agent (qemu-ga), un démon installé dans l'invité qui permet à l'hôte de lui envoyer des commandes via un canal virtio-serial. C'est un canal de gestion, pas une source d'horloge, même s'il peut mettre l'horloge de l'invité à l'heure une fois sur demande (virsh domtime <domain> --sync, qui lit l'heure dans la RTC de l'invité). Hyper-V fournit ses propres services d'intégration, parmi lesquels un service de synchronisation de l'heure (vmictimesync) qui synchronise l'horloge de l'invité sur celle de l'hôte.

Pourquoi c'est important

Aucun de ces mécanismes ne remplace un client de synchronisation de l'heure (chronyd, systemd-timesyncd ou le service Windows Time) exécuté dans l'invité :

• kvmclock améliore la qualité et la stabilité de la source d'horloge dont dispose le noyau invité ; il ne synchronise pas l'invité sur l'heure réelle, et l'horloge peut encore dériver, notamment lors de migrations de l'hôte, de mises en veille/reprises de l'hôte ou d'une forte contention CPU sur l'hôte qui retarde l'exécution effective du processeur virtuel de l'invité.
• Le QEMU Guest Agent peut recaler l'horloge en une fois lorsqu'on le lui demande (par exemple après une reprise), mais il n'asservit pas l'horloge en continu.
• Le composant de synchronisation de l'heure de Hyper-V suit l'horloge de l'hôte : l'invité n'est donc pas plus précis que l'hôte. L'hôte a lui-même besoin d'une bonne source de temps, et l'invité tire toujours profit de son propre service de temps (Windows Time, chronyd ou systemd-timesyncd).

Comment l'appliquer

• Maintenez un client NTP/chrony (ou Windows Time) actif et correctement configuré dans chaque invité, quels que soient l'hyperviseur et les outils invités installés.
• Après une migration de l'hôte, une restauration de snapshot ou la reprise d'une VM en pause ou suspendue, attendez-vous à un saut de l'heure de l'invité jusqu'à ce que le client interne la corrige. Vérifiez l'état du service (chronyc tracking, w32tm /query /status) après de tels événements plutôt que de supposer la continuité.
• Vérifiez quelle clocksource un invité Linux utilise réellement : cat /sys/devices/system/clocksource/clocksource0/current_clocksource (en général kvm-clock sur les invités KVM ; les noyaux invités récents peuvent préférer tsc lorsque l'hôte expose un TSC invariant stable). cat /sys/devices/system/clocksource/clocksource0/available_clocksource liste les alternatives.
• Considérez les indications de temps fournies par l'hôte (service d'intégration de synchronisation de l'heure de Hyper-V, équivalent de VMware) comme une couche de correction grossière, à côté du service de temps propre à l'invité. Consultez les recommandations de l'éditeur de l'hyperviseur pour les rôles particuliers, comme les contrôleurs de domaine virtualisés, où les deux sources peuvent entrer en conflit.

Pièges

• Désactiver le client NTP de l'invité au motif que « l'hyperviseur gère l'heure », puis constater des échecs de validation de certificats, de Kerberos ou de corrélation de journaux après une migration ou une reprise.
• Supposer que kvmclock suffit à garder l'heure réelle exacte : c'est une propriété de la source d'horloge, pas un protocole de synchronisation.