it-swarm-pt.tech

A Máquina Hyper-V perde 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, executei a mesma VM. Os problemas de sincronização de tempo desapareceram (<100 ms de diferença 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 mostra menos de 100 ms de diferença.

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

Em 20 segundos, passou por mais de um segundo. Se eu redefinir manualmente para dentro de 1s, em alguns minutos ele estará de volta à deriva cerca de 2 segundos. Durante a noite, passou de ~ 2s para ~ 5s. O Linux VM dentro de S2 tem sincronização perfeita com 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

Eu 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 resolver isso? É a única máquina que está apresentando esse problema. Todas as outras máquinas (físicas e virtuais) estão bem.

Editar: Para esclarecer: O VM (AD1) tem integração desligada e sincroniza com time.nist.gov. AD1 está bem. É a máquina física S1 que pode não sincroniza com AD1 e muda completamente. Todos os outros servidores físicos são capazes de sincronizar com AD1 perfeitamente.

Atualizar Portanto, parece ser um problema de execução da VM. O relógio passa devagar com o VM desligado. Ligado, ele imediatamente começa a perder segundos. Eu mudei o VM para usar apenas metade dos recursos, e isso parece para ter atenuado um pouco, por agora. Obrigado!

10
MichaelGG

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

O convidado do Hyper-V obtém seu relógio inicialmente do Host (HYV1), mas como você tem a sincronização de tempo do Hyper-V desabilitada, ele obtém todas as atualizações de relógio do NIST (que está funcionando bem). Seu Linux VM não está integrado ao Hyper-V, então está recebendo o tempo do domínio, que também está funcionando bem. Suas outras máquinas físicas estão funcionando bem, é apenas um único servidor que está tendo 1 segundo de desvio a cada 20 segundos (o que é uma quantidade absurda de desvio). O tempo está passando muito mais rápido do que a sincronização da hora da rede pode zerar o relógio para a hora certa (que se bem me lembro ocorre a cada 8 horas).

Se você quiser descartar o Hyper-V como a causa do erro no S2, crie uma entrada de inicialização "sem hipervisor", reinicie sem o Hyper-V e veja se a variação 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

5
Sean Earp

O problema é com a implementação virtual das várias fontes de relógio (tsc, jiffies, acpi_pm, cmos_trc). A melhor maneira que encontrei de corrigir esse problema com o HyperV é desligar desligar o sincronismo do relógio fornecido pelo HyperV para sua máquina convidada e, em seguida, usar o adjtimex para ajustar a hora. Em um sistema operacional Ubuntu convidado, 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 a ambas as perguntas

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

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

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

isto 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 irá ressincronizar o tempo em sua máquina e o ntp deve ser capaz de mantê-lo em sincronia porque ele não deve flutuar muito mais.

3
Matt Keenan

Este parece ser um problema muito comum com 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 desabilitar qualquer sincronização de horário de integração

Espero que isso ajude.

2
rmwetmore

Estamos executando o Hyper-v no Core por um tempo. No início, tivemos problemas de sincronização de tempo ... Voltei para uma prática recomendada dos meus velhos tempos de Windows NT.

Eu olho para os servidores por sistema operacional. Crio um mestre Linux, roteador, Windows, Novell.

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

Cada servidor "mestre" é sincronizado com o roteador. O roteador para estrato. Então, cada servidor membro tem seu servidor mestre de SO e um secundário de um dos outros Mestres.

  • Linux para roteador e, em seguida, para Novell
  • Novell para roteador e, em seguida, para Windows
  • Windows para roteador e depois para Linux
  • Roteador para Stratum e, em seguida, para switch Core
  • Mudança do núcleo para Stratum e depois para o roteador

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

Esta é uma das primeiras coisas que faço quando chego a um novo trabalho é dedicar um tempo para mapear a rede e definir o tempo. Posso então apenas verificar aqui e ali e eliminar a sincronização de tempo como um problema daquele ponto em diante.

2
Thomas Denton

Pode parecer engraçado, mas aposto que você está executando uma configuração de multiprocessador. Existem problemas conhecidos de variação do relógio em alguns fabricantes tosse AMD tosse que acontecem com placas-mãe multi-core/multi-socket. Atividades pesadas de interrupção - como, digamos, rodar uma ou duas máquinas virtuais - pioram a situação. O desvio que você está experimentando soa muito suspeito como este.

Pelo que vale a pena, eu prefiro as ofertas da AMD em vez da Intel, então não tome isso como um golpe contra eles.

1
Avery Payne

O tempo muda para todos os lados nas VMs. Você realmente deseja ter certeza de que o servidor NTP servidor não está usando o relógio local em nenhuma instrução de 'servidor', pois o relógio local não é confiável. Uma coisa que fiz para ajudar é defina o atributo "maxpoll" para servidores em máquinas VMed. Isso força o serviço ntp a verificar 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 o quanto você precisa descer para manter o tempo relativamente confiável. 12 funciona para mim, mas cada ambiente é diferente.

1
sysadmin1138

Supondo que AD1 fosse um controlador de domínio, acho que o problema aqui pode estar relacionado à configuração do seu servidor Hyper-V a partir de uma de suas próprias VMs convidadas. É por isso que o problema foi embora quando você mudou para VMware: o servidor VMware não se sente obrigado a sincronizar seu relógio com um controlador de domínio do Windows.

1
Skyhawk