Hyper-V Machine fa passare tutto il tempo, anche con NTP

Risolto Il problema era Hyper-V su quella macchina. Ho rimosso Hyper-V, installato VMware Server, eseguito la stessa VM. I problemi di sincronizzazione temporale sono andati via (differenza <100 ms dopo un giorno).

La mia configurazione è così:

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 e S1 hanno una sincronizzazione fine - il diagramma a strisce mostra una differenza inferiore a 100 ms.

S2 va alla deriva come un matto. Ecco un po 'del diagramma a strisce contro 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 

In 20 secondi, si trascinò per un secondo. Se lo ripristino manualmente entro 1 secondo, entro pochi minuti tornerà alla deriva per circa 2 secondi. Durante la notte è passato da ~ 2 a ~ 5 secondi. La VM Linux all'interno di S2 ha una sincronizzazione perfetta con AD1.

Ecco la configurazione:

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

Ho guardato il registro degli eventi e, a parte gli avvisi sulla sincronizzazione (dopo che è uscito dalla sincronizzazione), non ci sono altri avvisi.

Come posso risolvere questo problema? È l'unica macchina che ha questo problema. Tutte le altre macchine (fisiche e virtuali) stanno andando bene.

Modifica: per chiarire: la VM (AD1) ha l'integrazione disattivata e si sincronizza con time.nist.gov. AD1 va bene. È la macchina fisica S1 che non può sincronizzarsi con AD1 e va alla deriva dappertutto. Tutti gli altri server fisici sono in grado di sincronizzarsi bene con AD1.

Aggiornamento Quindi, sembra essere un problema nell'esecuzione della VM. L'orologio scivola lentamente a VM spento. Acceso, inizia immediatamente a perdere secondi. Ho utilizzato la VM per utilizzare solo metà delle risorse e questo sembra averlo leggermente mitigato, per ora. Grazie!

Dalla tua descrizione, sembra che ci sia un vero problema hardware con RTC ( http://en.wikipedia.org/wiki/Real-time_clock ) sulla scheda madre del server S2.

Il guest Hyper-V ottiene inizialmente l'orologio dall'host (HYV1), ma poiché la sincronizzazione dell'ora Hyper-V è disabilitata, ottiene tutti gli ulteriori aggiornamenti dell'orologio da NIST (che funziona correttamente). La tua VM Linux non è integrata con Hyper-V, quindi sta ricevendo il tempo dal dominio, che funziona anche bene. Le altre tue macchine fisiche funzionano bene, è solo un singolo server fisico che ha 1 secondo di deriva ogni 20 secondi (che è una quantità folle di deriva). Il tempo sta andando alla deriva molto più rapidamente di quanto la sincronizzazione dell'ora della rete possa ripristinare l'orologio al momento giusto (che se ricordo correttamente ha luogo ogni 8 ore).

Se si desidera escludere Hyper-V come causa dell'errore su S2, creare una voce di avvio "no Hypervisor", riavviare senza Hyper-V e vedere se la deriva temporale persiste. Istruzioni qui: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Sean

Il problema è con l'implementazione virtuale delle varie sorgenti di clock (tsc, jiffies, acpi_pm, cmos_trc). Il modo migliore che ho trovato per risolvere questo problema con HyperV è disattivare la sincronizzazione dell'orologio fornita da HyperV per il tuo computer guest, quindi utilizzare adjtimex per regolare l'ora. Su un SO guest Ubuntu fai questo ...

# 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

e rispondi No a entrambe le domande

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

lasciarlo funzionare per alcune ore per calibrare, premi Ctrl-C per uscire.

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

questo farà un'analisi dei minimi quadrati del tuo orologio e troverà la giusta regolazione

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

questo risincronizzerà il tempo sul tuo computer e ntp dovrebbe essere in grado di mantenerlo sincronizzato perché non dovrebbe più spostarsi troppo.

Questo sembra essere un problema molto comune con le macchine virtuali. Vedi i seguenti siti Web:

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

Il mio suggerimento sarebbe di sincronizzarsi con un solo time server esterno e disabilitare qualsiasi sincronizzazione del tempo di integrazione

Speriamo che questo aiuti.

Abbiamo eseguito Hyper-v su Core per un po '. Inizialmente abbiamo avuto problemi di sincronizzazione temporale ..... Sono tornato alle migliori pratiche dai miei vecchi giorni di Windows NT.

Guardo i server per sistema operativo. Creo un master Linux, Router, Windows, Novell.

Potresti non avere Novell ora, ma sopportare con me.

Ogni server "master" si sincronizza con il router. Il router per stratum. Quindi ogni server membro ha il suo server OS principale e un secondario di uno degli altri master.

• Linux al router, quindi a Novell
• Novell su router, quindi su Windows
• Da Windows a router, quindi a Linux
• Router su Stratum, quindi su Switch Core
• Core Passa a Stratum, quindi a Router

L'ultimo pezzo di questa stratagemma è ... TUTTO ha un time server. Se non ha un time server, non verrà collegato alla rete. Dal tostapane per passare al telefono PBX ai server.

Questa è una delle prime cose che faccio quando arrivo a un nuovo lavoro è passare il tempo per mappare la rete e impostare il tempo. Posso quindi controllarlo qua e là ed eliminare la sincronizzazione temporale come problema da quel momento in poi.

Il tempo si sposta dappertutto nelle macchine virtuali. Vuoi davvero assicurarti che il server NTP non stia utilizzando l'orologio locale in nessuna istruzione "server", poiché l'orologio locale è troppo inaffidabile. Una cosa che ho fatto per aiutare è impostare l'attributo "maxpoll" per i server su macchine VMed. Ciò impone al servizio ntp di verificare con i suoi orologi upstream molto più spesso rispetto al valore predefinito configurato, il che aiuta a mantenerlo vero.

server [timeserver] maxpoll 12

Prova alcune impostazioni per vedere quanto devi fare per mantenere il tempo relativamente affidabile. 12 funziona per me, ma ogni ambiente è diverso.

Può sembrare divertente, ma scommetto che stai eseguendo una configurazione a più processori? Ci sono noti problemi di deriva dell'orologio con alcuni produttori di tosse AMD tosse che si verificano con schede madri multi-core / multi-socket. Una forte attività di interruzione - come dire, eseguire una o due macchine virtuali - peggiora la deriva. La deriva che stai vivendo suona in modo molto sospetto come questo.

Per quello che vale, preferisco le offerte di AMD rispetto a Intel, quindi non prenderlo a bussare a loro.

Supponendo che AD1 fosse un controller di dominio, penso che il problema qui potrebbe essere stato correlato al tuo server Hyper-V che imposta il suo orario da una delle sue macchine virtuali guest. Ecco perché il problema è scomparso quando sei passato a VMware: il server VMware non si sente obbligato a sincronizzare il suo orologio con un controller di dominio Windows.