La máquina Hyper-V desplaza el tiempo por todas partes, incluso con NTP

Resuelto El problema era Hyper-V en esa máquina. Eliminé Hyper-V, instalé VMware Server, ejecuté la misma VM. Los problemas de sincronización horaria desaparecieron (<100 ms de diferencia después de un día).

Mi configuración es así:

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 y S1 tienen sincronización fina: el diagrama de tira muestra menos de 100 ms de diferencia.

S2 va a la deriva como un loco. Aquí hay un poco del diagrama de tira contra 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 segundos, se desvió más de un segundo. Si lo restablezco manualmente en 1 segundo, en unos minutos volverá a la deriva unos 2 segundos. Durante la noche pasó de ~ 2s a ~ 5s. La máquina virtual Linux dentro de S2 tiene una sincronización perfecta con AD1.

Aquí está la configuración:

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

Miré el registro de eventos y, aparte de las advertencias sobre la sincronización (después de que se sale de la sincronización), no hay otras advertencias.

¿Cómo puedo solucionar este problema? Es la única máquina que tiene este problema. Todas las otras máquinas (físicas y virtuales) están funcionando bien.

Editar: Para aclarar: la VM (AD1) tiene la integración desactivada y se sincroniza con time.nist.gov. AD1 está bien. Es la máquina física S1 que no puede sincronizarse con AD1 y se desplaza por todas partes. Todos los demás servidores físicos pueden sincronizarse con AD1 perfectamente.

Actualización Por lo tanto, parece ser un problema al ejecutar la VM. El reloj se desliza lentamente con la VM apagada. Encendido, inmediatamente comienza a perder segundos. Cambié la VM para usar solo la mitad de los recursos, y eso parece haberlo mitigado ligeramente, por ahora. ¡Gracias!

Según su descripción, parece que hay un problema real de hardware con el RTC ( http://en.wikipedia.org/wiki/Real-time_clock ) en la placa base del servidor S2.

El invitado de Hyper-V obtiene su reloj inicialmente desde el host (HYV1), pero como tiene la sincronización de tiempo de Hyper-V deshabilitada, obtiene todas las actualizaciones de reloj adicionales de NIST (que está funcionando bien). Su máquina virtual Linux no está integrada con Hyper-V, por lo que está obteniendo su tiempo del dominio, que también funciona bien. Sus otras máquinas físicas funcionan bien, es solo un servidor físico que tiene 1 segundo de deriva cada 20 segundos (lo cual es una gran cantidad de deriva). El tiempo se mueve mucho más rápido de lo que la sincronización de tiempo de la red puede restablecer el reloj a la hora correcta (que si recuerdo correctamente se lleva a cabo cada 8 horas).

Si desea descartar Hyper-V como causa del error en S2, cree una entrada de inicio "sin hipervisor", reinicie sin Hyper-V y vea si la deriva del tiempo persiste. Instrucciones aquí: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Sean

El problema está en la implementación virtual de las diversas fuentes de reloj (tsc, jiffies, acpi_pm, cmos_trc). La mejor manera que he encontrado para solucionar este problema con HyperV es desactivar la sincronización de reloj proporcionada por HyperV para su máquina invitada, luego usar adjtimex para ajustar la hora. En un sistema operativo invitado Ubuntu, haga esto ...

# 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

y responda No a ambas preguntas

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

deje que se ejecute durante unas horas para calibrar, presione Ctrl-C para salir.

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

esto hará un análisis de mínimos cuadrados de su reloj y encontrará el ajuste correcto

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

esto volverá a sincronizar el tiempo en su máquina y ntp debería poder mantenerlo sincronizado porque ya no debería desviarse demasiado.

Esto parece ser un problema muy común con las máquinas virtuales. Ver los siguientes sitios 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

Mi sugerencia sería sincronizar solo con un servidor de tiempo externo y desactivar cualquier sincronización de tiempo de integración

Espero que esto ayude.

Llevamos un tiempo ejecutando Hyper-v en Core. Al principio tuvimos problemas de sincronización de tiempo ... Volví a una práctica recomendada de mis viejos días de Windows NT.

Miro los servidores por sistema operativo. Creo un maestro Linux, Router, Windows, Novell.

Puede que no tenga Novell ahora, pero tenga paciencia conmigo.

Cada servidor "maestro" se sincroniza con el enrutador. El enrutador al estrato. Luego, cada servidor miembro tiene su servidor maestro OS y un secundario de uno de los otros Maestros.

• Linux al enrutador, luego a Novell
• Novell al enrutador, luego a Windows
• Windows al enrutador, luego a Linux
• Router a Stratum, luego a Core switch
• Interruptor central al estrato, luego al enrutador

La última parte de esta estrategia es ... TODO tiene un servidor de tiempo. Si no tiene un servidor horario, no se conectará a la red. De tostadora para cambiar a teléfono PBX a servidores.

Esta es una de las primeras cosas que hago cuando llego a un nuevo trabajo: pasar el tiempo para mapear la red y establecer el tiempo. Entonces puedo verificarlo aquí y allá y eliminar la sincronización de tiempo como un problema a partir de ese momento.

El tiempo se desplaza por todas partes en máquinas virtuales. Realmente desea asegurarse de que el servidor NTP no esté usando el reloj local en ninguna declaración de 'servidor', ya que el reloj local no es confiable. Una cosa que he hecho para ayudar es establecer el atributo "maxpoll" para servidores en máquinas VMed. Esto obliga al servicio ntp a verificar con sus relojes ascendentes con mucha más frecuencia que el valor predeterminado configurado, lo que ayuda a mantenerlo verdadero.

server [timeserver] maxpoll 12

Pruebe algunas configuraciones para ver qué tan lejos necesita llegar para mantener el tiempo relativamente confiable. 12 funciona para mí, pero cada entorno es diferente.

Esto puede sonar gracioso, pero ¿apuesto a que está ejecutando una configuración de multiprocesador? Hay problemas conocidos de reloj de deriva con ciertos fabricantes tos AMD tos que suceden con las placas multi-core / multi-socket. La fuerte actividad de interrupción, como decir, ejecutar una máquina virtual o dos, empeora la deriva. La deriva que estás experimentando suena muy sospechosamente así.

Por lo que vale, prefiero las ofertas de AMD a Intel, así que no tomes esto como un golpe contra ellos.

Suponiendo que AD1 era un controlador de dominio, creo que el problema aquí puede haber estado relacionado con su servidor Hyper-V configurando su tiempo desde una de sus propias máquinas virtuales invitadas. Es por eso que el problema desapareció cuando se cambió a VMware: el servidor VMware no se siente obligado a sincronizar su reloj con un controlador de dominio de Windows.