Dois-je exécuter un serveur NTP dans chaque machine virtuelle?

Les invités ne pouvaient-ils pas hériter en quelque sorte de l'heure système de l'hôte?

Il semble un peu inutile d'exécuter le même démon pour obtenir plusieurs fois les mêmes résultats sur la même machine, mais je n'ai rien trouvé de lié au temps lors de la lecture d'articles KVM ou Xen. D'après ce que je comprends, l'invité obtient l'heure de l'hôte au démarrage, mais il peut ensuite s'écarter. Est-ce exact ?

C'est correct. Il convient de noter que non seulement le temps "peut" s'éloigner, mais qu'il s'éloignera du fait que les intervalles entre les interruptions de la minuterie (sur lesquelles le chronométrage sur le système d'exploitation est souvent basé) sont étirés et compressés comme l'hyperviseur le jugerait bon.

Une solution de contournement couramment utilisée sur la plupart des plates-formes de virtualisation (services d'intégration Hyper-V, outils VMWare) exécute un démon sur l'invité qui synchronise périodiquement les horloges avec l'hôte VM. Comme indiqué par Hauke ​​dans un commentaire à votre question, KVM fournit en outre une horloge paravirtualisée qui aurait besoin du pilote respectif chargé sur le système d'exploitation invité pour fonctionner.

Chronométrage dans les machines virtuelles VMWare (vmware.com)
Synchronisation de l'horloge des invités KVM (s19n.net)

Dans un monde parfait, vos invités VM garderaient un temps parfait, ou au moins aussi parfait que l'hôte le leur fournit. Malheureusement, nous ne vivons pas dans un monde parfait.

Sur la base de mon expérience avec pratiquement tous les hyperviseurs connus de l'homme, je lance toujours un client NTP sur des machines virtuelles, sans exception. Ma configuration habituelle est ntpd avec l'option -g, ou ntpdate commençant juste avant pour les anciens systèmes, pour faire avancer l'horloge (qui peut être loin d'être synchronisée au démarrage du système).

KVM a une configuration presque parfaite, avec son horloge en temps réel paravirtualisée ; les invités avec le pilote approprié (tout Linux récent, au moins) garderont le temps ainsi que l'hôte. Mais les choses tournent mal ici: par exemple, l'hôte peut ne pas exécuter NTP, l'hôte peut avoir un fuseau horaire incorrect, l'horloge de l'hôte peut être tout simplement fausse, etc.

VMware et Hyper-V se situent au milieu. Chacun a un outil destiné à être exécuté sur l'invité qui synchronise l'horloge avec l'hôte périodiquement, mais là encore, il est vulnérable à tout problème existant avec l'horloge de l'hôte.

Les invités sur mon serveur Hyper-V de test ont également présenté un comportement étrange: même avec les services d'intégration, l'horloge invité dériverait plus vite que 500 ppm, empêchant ntpd de fonctionner ( il considère l'horloge comme folle si elle dérive plus vite que cela ). J'ai dû passer ces invités en chrony , ce qui permet d'ajuster cette valeur .

Xen est le pire à cet égard; il n'a absolument aucune synchronisation et l'exécution de NTP dans les invités est à peu près nécessaire. (On me dit que les versions très récentes de Xen ont une sorte de synchronisation mais ne l'ont pas encore personnellement utilisé.)

Les choses empirent simplement si l'hyperviseur hôte n'est pas sous votre contrôle, comme un cloud public. Vous êtes à la merci du fournisseur en ce qui concerne l'horloge hôte, et s'il ne fait pas preuve de diligence pour la maintenir synchronisée, vous perdez.

Avec tout cela, exécuter des clients NTP dans vos machines virtuelles est à peu près nécessaire si vous avez besoin d'une horloge semi-précise. NB: Si vous exécutez des machines virtuelles Windows, procurez-vous un client NTP tiers qui ajuste l'horloge en continu; la mauvaise excuse pour un client fourni avec Windows ne règle l'horloge qu'une fois par semaine , ce qui est tout à fait ridicule.

Je recommanderais d'utiliser NTP car il est bien connu et existe depuis longtemps. Le réglage de l'horloge n'est pas anodin. NTP a résolu ce problème.

La ligne officielle de VMware consiste à utiliser un mécanisme, NTP étant préféré car il est plus fin et prend des mesures plus petites pour régler l'heure. La solution VMware interne prend des mesures plus importantes. Lorsque vous exécutez les deux, ils pourraient se battre. La solution interne VMware franchit une étape importante, puis NTP l'ajuste et la reprend un peu.

Dans la pratique, cependant, nous courons les deux en même temps et je n'ai pas encore vu de problème.

$ ntpq   
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
something.org  172.2.1.5          2 u   57   64  377    1.597   -2.409   5.952


$  vmware-toolbox-cmd  timesync status
Enabled


$ vmware-toolbox-cmd help timesync
timesync: functions for controlling time synchronization on the guest OS
Usage: vmware-toolbox-cmd timesync <subcommand>

Subcommands:
  enable: enable time synchronization
  disable: disable time synchronization
  status: print the time synchronization status