A máquina Hyper-V desvia o tempo todo, mesmo com NTP

Resolvido O problema era o Hyper-V nessa máquina. Eu removi o Hyper-V, instalei o VMware Server e executei a mesma VM. Os problemas de sincronização de tempo desapareceram (diferença <100 ms após um dia).

Minha configuração é assim:

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 têm sincronização fina - o gráfico de strip mostra menos de 100ms de diferença.

S2 deriva como um louco. Aqui está um pouco do stripchart contra o 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 

Em 20 segundos, flutuou mais de um segundo. Se eu redefini-lo manualmente para 1s, em alguns minutos ele voltará à deriva cerca de 2 segundos. Durante a noite passou de ~ 2s para ~ 5s. A VM do Linux dentro do S2 possui sincronização perfeita com o AD1.

Aqui está a configuração:

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

Olhei para o log de eventos e, além dos avisos sobre sincronização (depois que fica fora de sincronia), não há outros avisos.

Como posso solucionar esse problema? É a única máquina que está tendo esse problema. Todas as outras máquinas (físicas e virtuais) estão indo bem.

Editar: para esclarecer: A VM (AD1) tem a integração desativada e sincronizada com time.nist.gov. AD1 está bem. É a máquina física S1 que não pode sincronizar com o AD1 e se desloca por todo o lado. Todos os outros servidores físicos são capazes de sincronizar com o AD1 muito bem.

Atualizar Portanto, parece ser um problema de execução da VM. O relógio desliza lentamente com a VM desligada. Ligado, ele imediatamente começa a perder segundos. Troquei a VM para usar apenas metade dos recursos, e isso parece ter mitigado um pouco, por enquanto. Obrigado!

Pela sua descrição, parece que há um problema real de hardware com o RTC ( http://en.wikipedia.org/wiki/Real-time_clock ) na placa-mãe do servidor S2.

O convidado do Hyper-V obtém o relógio inicialmente do host (HYV1), mas como a sincronização de horário do Hyper-V está desativada, ele recebe todas as atualizações adicionais do NIST (que está funcionando bem). Sua VM do Linux não está integrada ao Hyper-V, portanto, está chegando a hora do domínio, que também está funcionando bem. Suas outras máquinas físicas estão funcionando bem, é apenas um servidor físico que está tendo 1 segundo de desvio a cada 20 segundos (o que é uma quantidade louca de desvio). O tempo está mudando muito mais rápido do que a sincronização da hora da rede pode redefinir o relógio para a hora certa (que, se bem me lembro, ocorre a cada 8 horas).

Se você deseja descartar o Hyper-V como causa do erro no S2, crie uma entrada de inicialização "no Hypervisor", reinicie sem o Hyper-V e verifique se o desvio de tempo persiste. Instruções aqui: http://blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-Sean

O problema está na implementação virtual das várias fontes de clock (tsc, jiffies, acpi_pm, cmos_trc). A melhor maneira que encontrei para corrigir esse problema com o HyperV é desativar a sincronização do relógio fornecida pelo HyperV para o seu computador convidado e, em seguida, usar o adjtimex para ajustar a hora. Em um SO convidado do Ubuntu, faça isso ...

# 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 responda Não às duas perguntas

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

deixe que funcione por algumas horas para calibrar, pressione Ctrl-C para sair.

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

isso fará uma análise dos mínimos quadrados do seu relógio e encontrará o ajuste certo

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

isso ressincronizará o tempo na sua máquina e o ntp poderá mantê-lo sincronizado, porque não deve ficar muito à deriva.

Esse parece ser um problema muito comum nas VMs. Veja os seguintes sites:

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

Minha sugestão seria sincronizar apenas com um servidor de horário externo e desativar qualquer sincronização de horário de integração

Espero que isso ajude.

Estamos executando o Hyper-v no Core há um tempo. No começo, tínhamos problemas de sincronização de tempo ..... Voltei a uma prática recomendada nos meus velhos dias do Windows NT.

Eu olho para os servidores pelo sistema operacional. Eu crio um mestre Linux, Roteador, Windows, Novell.

Você pode não ter a Novell agora, mas tenha paciência comigo.

Cada servidor "mestre" é sincronizado com o roteador. O roteador para o estrato. Em seguida, cada servidor membro tem seu servidor SO principal e um secundário de um dos outros mestres.

• Linux para roteador e depois para Novell
• Novell to Router e depois para Windows
• Windows para roteador, depois para Linux
• Roteador para Stratum e, em seguida, para Core switch
• Alterne para Stratum e depois para Roteador

A última parte dessa estratégia é ... TUDO tem um servidor de horário. Se ele não tiver um servidor de horário, ele não será conectado à rede. Da torradeira para mudar para PBX do telefone para servidores.

Essa é uma das primeiras coisas que faço quando chego a um novo trabalho: gastar tempo para mapear a rede e definir o horário. Posso então verificar aqui e ali e eliminar a sincronização de tempo como um problema a partir desse momento.

O tempo passa por todo o lugar nas VMs. Você realmente deseja garantir que o servidor NTP não esteja usando o relógio local em nenhuma instrução 'server', pois o relógio local não é confiável. Uma coisa que fiz para ajudar é definir o atributo "maxpoll" para servidores em máquinas VMed. Isso força o serviço ntp a verificar com seus relógios upstream com muito mais frequência do que o padrão configurado, o que ajuda a mantê-lo verdadeiro.

server [timeserver] maxpoll 12

Experimente algumas configurações para ver até que ponto você precisa para manter o tempo relativamente confiável. 12 funciona para mim, mas cada ambiente é diferente.

Isso pode parecer engraçado, mas aposto que você está executando uma instalação com vários processadores? Existem problemas conhecidos relógio de deriva com certos fabricantes tosse AMD tosse que acontecem com placas-mãe multi-core / multi-socket. A atividade pesada de interrupção - como, por exemplo, rodar uma máquina virtual ou duas - piora a situação. A tendência que você está enfrentando parece muito suspeita assim.

Pelo que vale, prefiro as ofertas da AMD à Intel, por isso não tome isso como uma batida contra elas.

Supondo que o AD1 fosse um controlador de domínio, acho que o problema aqui pode ter sido relacionado ao fato de o servidor Hyper-V definir o horário de uma de suas próprias VMs convidadas. É por isso que o problema desapareceu quando você mudou para o VMware: o servidor VMware não se sente obrigado a sincronizar seu relógio com um controlador de domínio do Windows.