10 votes

La machine Hyper-V dérive l'heure partout, même avec NTP

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


Ma configuration est la suivante :

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 sont bien synchronisés - le graphique montre moins de 100ms de différence.

Le S2 dérive comme un fou. Voici un extrait du graphique en bande contre AD1 :

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

En 20 secondes, il a dérivé d'une seconde. Si je le réinitialise manuellement à 1s près, au bout de quelques minutes, il dérive à nouveau d'environ 2 secondes. Pendant la nuit, elle est passée de ~2s à ~5s. La VM Linux dans S2 est parfaitement synchronisée 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 à part les avertissements concernant la synchronisation (après qu'elle soit très désynchronisée), il n'y a pas d'autres avertissements.

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

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

Mise à jour Il semble donc qu'il s'agisse d'un problème d'exécution de la VM. L'horloge glisse lentement avec la VM éteinte. Lorsqu'elle est allumée, elle commence immédiatement à perdre des secondes. J'ai modifié la VM pour qu'elle n'utilise que la moitié des ressources, et cela semble avoir légèrement atténué le problème, pour le moment. Merci.

5voto

David Crow Points 7704

D'après 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 reçoit son horloge initialement de l'hôte (HYV1), mais comme vous avez désactivé la synchronisation de l'heure Hyper-V, il reçoit toutes les mises à jour ultérieures de l'horloge du NIST (qui fonctionne bien). Votre VM Linux n'est pas intégrée à Hyper-V, elle reçoit donc l'heure du domaine, ce qui fonctionne également très bien. Vos autres machines physiques fonctionnent bien, il n'y a qu'un seul serveur physique qui a une dérive d'une seconde toutes les 20 secondes (ce qui est une quantité folle de dérive). L'heure dérive beaucoup plus vite que la synchronisation de l'heure du réseau ne peut remettre l'horloge à l'heure (ce qui, si je me souviens bien, a lieu toutes les 8 heures).

Si vous voulez 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 voyez si la dérive temporelle persiste. Instructions ici : http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Sean

0 votes

OK, je vais essayer.

0 votes

OK, j'ai arrêté la VM (je n'ai pas désactivé HyperV). L'horloge est bien meilleure maintenant. Après environ 3 minutes, elle n'a perdu qu'environ 100 ms. Elle en perd encore, mais beaucoup moins qu'avant. Dès que j'allume la VM, elle devient folle. Il perd 1 seconde en quelques secondes. Peut-être parce que la VM n'a pas de services d'intégration ?

0 votes

Michael- Cela peut sembler hors sujet, mais exécutez-vous une application multimédia quelconque sur la partition mère de S2 ? -Sean

3voto

Le problème vient de l'implémentation virtuelle des différentes sources d'horloge (tsc, jiffies, acpi_pm, cmos_trc). La meilleure façon que j'ai trouvée pour résoudre ce problème avec HyperV est d'activer l'option off la synchronisation de l'horloge fournie par HyperV pour votre machine invitée, puis utilisez adjtimex pour ajuster l'heure. Sur un OS invité Ubuntu, faites ceci...

# 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épondre Non aux deux questions

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

laissez-le fonctionner pendant quelques heures pour le calibrer, appuyez sur Ctrl-C pour le quitter.

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

ceci 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

Ceci va resynchroniser l'heure sur votre machine et ntp devrait alors être capable de la maintenir synchronisée car elle ne devrait plus trop dériver.

2voto

rmwetmore Points 432

Cela semble être un problème très courant avec les VM. Consultez les sites Web 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

Je vous suggère de vous synchroniser avec un serveur de temps externe et de désactiver toute synchronisation du temps d'intégration.

J'espère que cela vous aidera.

0 votes

C'est exactement ce que j'ai fait. L'intégration de la VM (AD1) est désactivée et se synchronise avec time.nist.gov. AD1 fonctionne bien. C'est la machine physique S1 qui perd la synchronisation avec AD1.

0 votes

Comme le dit cet homme, il faut régler MaxAllowedPhaseOffset sur 1. jaylee.org/post/2009/10/14/

2voto

baldy Points 2922

Nous utilisons Hyper-v sur Core depuis un certain temps. Au début, nous avons eu des problèmes de synchronisation temporelle...... Je suis revenu à une meilleure pratique de mes vieux jours sous Windows NT.

Je regarde les serveurs par système d'exploitation. Je crée un master Linux, Router, Windows, Novell.

Vous n'avez peut-être pas Novell maintenant, mais soyez indulgent avec moi.

Chaque serveur "maître" se synchronise avec le routeur. Le routeur à la strate. Ensuite, chaque serveur membre a son serveur OS maître et un secondaire d'un des autres maîtres.

  • Linux vers Router, puis vers Novell
  • Novell vers Router, puis vers Windows
  • Windows vers le routeur, puis vers Linux
  • Routeur vers Stratum, puis vers Core switch
  • Core Switch vers Stratum, puis vers Router

Le dernier élément de cette stratégie est... TOUT a un serveur de temps. S'il n'a pas de serveur de temps, il ne sera pas branché sur le réseau. Du grille-pain au commutateur en passant par le PBX du téléphone et les serveurs.

C'est l'une des premières choses que je fais lorsque j'arrive dans un nouveau poste : prendre le temps de cartographier le réseau et de fixer l'heure. Je peux ensuite le vérifier ici et là et éliminer la synchronisation de l'heure comme un problème à partir de ce moment-là.

0 votes

Hmm, je vais essayer d'ajouter un secondaire manuel et voir si ça aide. Mais tout le reste fonctionne bien -- seule cette machine physique dérive.

0 votes

Quel type de machine est-ce ? Dell/HP/IBM - Autre ? J'ai eu des ordinateurs Dell qui avaient toujours besoin d'être réglés.

0 votes

Dell PowerEdge 850 avec un Pentium D920 à l'intérieur (ou quelque chose comme ça -- 2.8GHz, fait Intel VT.)

1voto

sysadmin1138 Points 129885

Le temps dérive dans toutes les directions dans les VM. Il faut vraiment s'assurer que le serveur NTP n'utilise pas l'horloge locale dans les instructions "server", 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 la valeur par défaut configurée, ce qui aide à maintenir l'horloge.

server [timeserver] maxpoll 12

Essayez quelques réglages pour voir jusqu'où vous devez descendre pour que le temps reste relativement fiable. 12 fonctionne pour moi, mais chaque environnement est différent.

0 votes

J'ai essayé avec un temps de sondage de 2 ou 4 (16 secondes). Il y a toujours une dérive insensée.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X