La machine Hyper-V dérive le temps partout, même avec NTP

Résolu Le problème était Hyper-V sur cette machine. J'ai supprimé Hyper-V, installé VMware Server, a exécuté la même machine virtuelle. Les problèmes de synchronisation temporelle ont disparu (<100 ms de différence après un jour).


Mon configuration est comme ceci:

HYV1 - HyperV machine (non domain) - sync irrelevant AD1 - VM AD server on HYV1, sync'd to time.nist.gov. HyperV time sync off. S1 - Physical machine, sync'd to domain. S2 - Physical machine running HyperV, sync'd to domain. V1 - Linux VM machine on S2, sync'd to AD1. No HyperV integration. 

AD1 et S1 ont une synchronisation fine – le diagramme à feuilles affiche moins de 100 ms de différence.

S2 dérive comme un fou. Voici un peu du stripchart contre AD1:

 18:33:22 d:+00.0010138so:+05.4101899s 18:33:24 d:+00.0010138so:+05.4319765s 18:33:26 d:+00.0000000so:+05.4788429s 18:33:28 d:+00.0000000so:+05.6089942s 18:33:30 d:+00.0010138so:+05.7240269s 18:33:32 d:+00.0000000so:+06.0421911s 18:33:34 d:+00.0081104so:+06.5613708s 18:33:37 d:+00.0000000so:+06.9096594s 18:33:39 d:+00.0000000so:+06.8867838s 18:33:41 d:+00.0010127so:+06.8936401s 

En 20 secondes, il a dérivé pendant une seconde. Si je le réinitialise manuellement dans les 1s, dans quelques minutes, il sera à nouveau dérivé environ 2 secondes. Dans la nuit, il est passé de ~ 2s à ~ 5s. La Linux VM à l'intérieur de S2 a une synchronisation parfaite avec AD1.

Voici la configuration:

 C:\Users\mgg>w32tm /dumpreg /subkey:Parameters Value Name Value Type Value Data ------------------------------------------------------------ ServiceDll REG_EXPAND_SZ %systemroot%\system32\w32time.dll ServiceMain REG_SZ SvchostEntry_W32Time ServiceDllUnloadOnStop REG_DWORD 1 Type REG_SZ NT5DS NtpServer REG_SZ ad01.mydomain ad02.mydomain C:\Users\mgg>w32tm /dumpreg /subkey:Config Value Name Value Type Value Data ----------------------------------------------------------- FrequencyCorrectRate REG_DWORD 4 PollAdjustFactor REG_DWORD 5 LargePhaseOffset REG_DWORD 50000000 SpikeWatchPeriod REG_DWORD 900 LocalClockDispersion REG_DWORD 9 HoldPeriod REG_DWORD 5 PhaseCorrectRate REG_DWORD 1 UpdateInterval REG_DWORD 30000 EventLogFlags REG_DWORD 2 AnnounceFlags REG_DWORD 5 TimeJumpAuditOffset REG_DWORD 28800 MinPollInterval REG_DWORD 2 MaxPollInterval REG_DWORD 8 MaxNegPhaseCorrection REG_DWORD -1 MaxPosPhaseCorrection REG_DWORD -1 MaxAllowedPhaseOffset REG_DWORD 300 

J'ai regardé le journal des événements, et en dehors des avertissements sur la synchronisation (après qu'il soit complètement synchronisé), il n'y a pas d'autres avertissements.

Comment puis-je résoudre le problème? C'est la seule machine à avoir ce problème. Toutes les autres machines (physiques et virtuelles) fonctionnent bien.

Modifier: Pour clarifier: La VM (AD1) a l'intégration désactivée et se synchronise avec time.nist.gov. AD1 est bien. C'est la machine physique S1 qui ne peut pas synchroniser avec AD1 et dérive partout. Tous les autres serveurs physiques sont en mesure de synchroniser correctement AD1.

Mise à jour Donc, il semble qu'il s'agisse d'exécuter la machine virtuelle. L'horloge glisse lentement avec la VM. Allumé, il commence immédiatement à perdre des secondes. Je swt le VM pour utiliser seulement la moitié des ressources, et cela semble l'avoir atténué légèrement, pour l'instant. Merci!

De votre description, il semble qu'il y ait un problème matériel réel avec le RTC ( http://en.wikipedia.org/wiki/Real-time_clock ) sur la carte mère du serveur S2.

L'invité Hyper-V obtient son horloge initialement à partir de l'hôte (HYV1), mais comme vous avez la synchronisation de temps Hyper-V désactivée, toutes les nouvelles mises à jour de l'horloge de NIST (qui fonctionnent bien) sont activées. Votre machine virtuelle Linux n'est pas intégrée à Hyper-V, ce qui fait qu'il est temps du domaine, qui fonctionne aussi bien. Vos autres machines physiques fonctionnent bien, c'est juste un serveur physique unique qui a une seconde de dérive toutes les 20 secondes (ce qui est une quantité folle de dérive). Le temps dérive beaucoup plus rapidement que la synchronisation du temps réseau peut réinitialiser l'horloge au bon moment (ce qui, si je me souviens bien, se déroule toutes les 8 heures).

Si vous souhaitez exclure Hyper-V comme cause de l'erreur sur S2, créez une entrée de démarrage "sans Hyperviseur", redémarrez sans Hyper-V et vérifiez si la dérive du temps persiste. Instructions ici: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Sean

Le problème concerne l'implémentation virtuelle des différentes sources d'horloge (tsc, jiffies, acpi_pm, cmos_trc). La meilleure façon de résoudre ce problème avec HyperV est d' éteindre la synchronisation d'horloge fournie par HyperV pour votre machine invitée, puis utilisez l'option adjtimex pour régler l'heure. Sur un système d'exploitation Ubuntu inventez …

 # rm /var/log/clocks.log # /etc/init.d/ntp-server stop # ntpdate ntp.ubuntu.com # hwclock -u --systohc # adjtimex -l -u -h ntp.ubuntu.com 

Et répondez non aux deux questions

 # while [ /bin/true ] ; do yes | adjtimex -l -u -h ntp.ubuntu.com ; sleep 60 ; done 

Laissez-le courir pendant quelques heures pour étalonner, appuyez sur Ctrl-C pour le quitter.

 # adjtimex -r -a -u -h ntp.ubuntu.com 

Cela fera une analyse des moindres carrés de votre horloge et trouvera le bon ajustement

 # ntpdate ntp.ubuntu.com # hwclock -u --systohc # /etc/init.d/ntp-server start 

Cela resynchronise l'heure de votre machine et ntp devrait pouvoir la synchroniser car elle ne devrait plus dériver.

Cela semble être un problème très commun avec VM. Voir les sites suivants:

http://www.vmwareinfo.com/2008/04/enabling-ntp-on-esx-servers.html

http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/6fff3eef-1b5b-4059-8618-22ab3f5c293c

Ma suggestion serait de synchroniser avec juste un serveur de temps externe et de désactiver toute synchronisation de temps d'intégration

Espérons que cela aide.

Nous avons exécuté Hyper-v sur Core pendant un certain temps. Au début, nous avons eu des problèmes de synchronisation du temps ….. Je suis retourné à la meilleure pratique de mes anciens jours Windows NT.

Je regarde les serveurs par OS. Je crée un Linux, un routeur, un Windows, un maître de Novell.

Vous pourriez ne pas avoir Novell maintenant mais nu avec moi.

Chaque serveur «maître» se synchronise sur le routeur. Le routeur à la strate. Ensuite, chaque serveur membre possède son serveur OS maître et un secondaire de l'un des autres maîtres.

  • Linux to Router, puis Novell
  • Novell to Router, puis Windows
  • Windows to router, puis Linux
  • Routeur à Stratum, puis à Core Switch
  • Core Switch to Stratum, puis à Router

Le dernier morceau de ce stratagy est … TOUT est un serveur de temps. S'il ne dispose pas d'un serveur de temps, il ne sera pas connecté au réseau. Du grille-pain pour passer au PBX du téléphone aux serveurs.

C'est l'une des premières choses que je fais quand je parviens à un nouveau travail, c'est de consacrer le temps nécessaire à la carte du réseau et à régler l'heure. Je peux alors le vérifier ici et là et éliminer la synchronisation du temps en tant que problème à partir de ce point.

Le temps dérive partout dans les machines virtuelles. Vous voulez vraiment vous assurer que le serveur NTP n'utilise pas l'horloge locale dans les instructions «serveur», car l'horloge locale est trop peu fiable. Une chose que j'ai faite pour aider est de définir l'attribut "maxpoll" pour les serveurs sur les machines VMed. Cela oblige le service ntp à vérifier avec ses horloges en amont beaucoup plus souvent que le défaut configuré, ce qui permet de le garder vrai.

 server [timeserver] maxpoll 12 

Essayez quelques paramètres pour voir à quelle distance vous devez obtenir pour garder le temps relativement fiable. 12 fonctionne pour moi, mais chaque environnement est différent.

Cela peut sembler drôle, mais je parie que vous exécutez une configuration multiprocesseur? On connaît des problèmes de dérive de l'horloge avec certains fabricants qui toussent la toux d' AMD qui se produisent avec les cartes mères multi-core / multi-socket. L'activité d'interruption lourde – comme dire, l'exécution d'une machine virtuelle ou deux – rend la dérive pire. La dérive que vous ressentez semble très méchante comme celle-ci.

Pour ce qu'il vaut, je préfère les offres d'AMD sur Intel, alors ne prenez pas cela comme un coup de foudre contre eux.

En supposant que AD1 était un contrôleur de domaine, je pense que le problème ici peut avoir été lié à votre serveur Hyper-V qui définit son temps à partir de l'une de ses machines virtuelles invitées. C'est pourquoi le problème est tombé lorsque vous avez changé vers VMware: le serveur VMware ne se sent pas obligé de synchroniser son horloge avec un contrôleur de domaine Windows.