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, exécuté la même machine virtuelle. Les problèmes de synchronisation de l'heure ont disparu (<100 ms de différence après une journée).

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 ont une synchronisation fine - le diagramme à bandes montre une différence inférieure à 100 ms.

S2 dérive comme un fou. Voici un peu du diagramme à barres 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é en une seconde. Si je le réinitialise manuellement en moins de 1 seconde, en quelques minutes, il reviendra à la dérive pendant environ 2 secondes. Du jour au lendemain, il est passé de ~ 2s à ~ 5s. La machine virtuelle Linux à l'intérieur de 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 sur la synchronisation (après qu'il se soit complètement désynchronisé), il n'y a pas d'autres avertissements.

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

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

Mise à jour Donc, il semble que ce soit un problème d'exécution de la machine virtuelle. L'horloge glisse lentement avec la VM éteinte. Allumé, il commence immédiatement à perdre des secondes. J'ai échangé la machine virtuelle pour n'utiliser que la moitié des ressources, et cela semble l'avoir légèrement atténuée, pour l'instant. Merci!

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'hôte Hyper-V reçoit son horloge initialement de l'hôte (HYV1), mais comme la synchronisation de l'heure Hyper-V est désactivée, il obtient toutes les autres mises à jour de l'horloge du NIST (qui fonctionne bien). Votre machine virtuelle Linux n'est pas intégrée à Hyper-V, il est donc temps pour le domaine, qui fonctionne également très bien. Vos autres machines physiques fonctionnent bien, c'est juste un serveur physique unique qui a 1 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 de l'heure du réseau peut réinitialiser l'horloge au bon moment (qui si je me souviens bien a lieu 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 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

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 de désactiver la synchronisation d'horloge fournie par HyperV pour votre machine invitée, puis d'utiliser adjtimex pour régler l'heure. Sur un OS invité Ubuntu, procédez comme suit ...

# 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 fonctionner pendant quelques heures pour calibrer, 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 réglage

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

cela resynchronisera l'heure sur votre machine et ntp devrait alors être capable de le garder synchronisé car il ne devrait plus trop dériver.

Cela semble être un problème très courant avec les machines virtuelles. 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

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

J'espère que cela aide.

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

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

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

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

• Linux au routeur, puis à Novell
• Novell au routeur, puis à Windows
• Windows au routeur, puis à Linux
• Routeur vers Stratum, puis vers commutateur Core
• Commutateur principal vers Stratum, puis vers routeur

Le dernier morceau de cette stratagie est ... TOUT a un serveur de temps. S'il n'a pas de serveur horaire, il ne sera pas connecté au réseau. Du grille-pain pour passer du PBX téléphonique aux serveurs.

C'est l'une des premières choses que je fais lorsque j'arrive à un nouvel emploi, c'est de passer du temps à cartographier le réseau et à régler 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.

Le temps dérive partout dans les VM. Vous voulez vraiment vous 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 fait pour vous aider est de définir l'attribut "maxpoll" pour les serveurs sur les machines VMed. Cela force le service ntp à vérifier avec ses horloges en amont beaucoup plus souvent que la valeur par défaut configurée, ce qui aide à le maintenir vrai.

server [timeserver] maxpoll 12

Essayez quelques paramètres pour voir jusqu'où vous devez descendre 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? Il y a des problèmes connus horloge dérive avec certains fabricants toux AMD toux qui se produisent avec multi-core / cartes mères multi-socket. Une activité d'interruption intense - comme, par exemple, l'exécution d'une ou deux machines virtuelles - aggrave la dérive. La dérive que vous rencontrez sonne de manière très suspecte .

Pour ce que ça vaut, je préfère les offres d'AMD à Intel, alors ne prenez pas cela comme un coup contre eux.

En supposant qu'AD1 était un contrôleur de domaine, je pense que le problème ici peut être lié à votre serveur Hyper-V définissant son heure à partir de l'une de ses propres machines virtuelles invitées. C'est pourquoi le problème a disparu lorsque vous êtes passé à VMware: le serveur VMware ne se sent pas obligé de synchroniser son horloge avec un contrôleur de domaine Windows.