O Hyper-V Machine troca o tempo todo, mesmo com o NTP

Question

Resolvido O problema era o Hyper-V naquela máquina. Eu removi o Hyper-V, instalei o VMware Server, executei a mesma VM. Os problemas de sincronização de tempo foram embora (diferença de <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 mostra menos de 100 ms de diferença.

S2 flutua 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, ele passou por um segundo. Se eu redefinir manualmente para dentro de 1s, dentro de alguns minutos ele estará de volta à deriva cerca de 2 segundos. Durante a noite, passou de ~ 2s para ~ 5s. A VM do Linux dentro do S2 tem uma 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

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

Como posso resolver isso? É 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 sincroniza com time.nist.gov. AD1 está bem. É a máquina física S1 que não pode sincronizar com AD1 e deriva todo. Todos os outros servidores físicos são capazes de sincronizar com AD1 muito bem.

Atualizar Então, parece ser um problema de executar a VM. O relógio desliza lentamente com a VM desligada. Ligado, imediatamente começa a perder segundos. Eu mudei a VM para usar apenas metade dos recursos, e isso parece ter diminuído um pouco, por enquanto. Obrigado!

    

Answer 1

A partir de sua descrição, parece que há um problema real de hardware com o RTC ( link ) no placa mãe do servidor S2.

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

Se você quiser excluir o Hyper-V como causa do erro no S2, crie uma entrada de inicialização "sem hipervisor", reinicialize sem o Hyper-V e verifique se o desvio de horário persiste. Instruções aqui: link

-Sean

    

Answer 2

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 para corrigir esse problema com o HyperV é desativar o a sincronização de relógio fornecida pelo HyperV para sua máquina convidada e, em seguida, usar o adjtimex para ajustar a hora. Em um sistema operacional 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 isso para funcionar 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 correto

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

isso irá ressincronizar o tempo na sua máquina e o ntp deverá então mantê-lo em sincronia, porque ele não deve se movimentar muito mais.

    

Answer 3

Este parece ser um problema muito comum em VMs. Veja os seguintes sites:

link

link

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

Espero que isso ajude.

    

Answer 4

Temos usado o Hyper-v no Core por um tempo. No começo, tivemos problemas de sincronização de tempo ..... Voltei para uma prática recomendada dos meus antigos dias do Windows NT.

Eu vejo os servidores pelo sistema operacional. Eu crio um mestre Linux, Router, Windows, Novell.

Você pode não ter o Novell agora, mas apenas comigo.

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

• Linux para o roteador, depois para o Novell
• Novell para roteador e, em seguida, para o Windows
• do Windows para o roteador e, em seguida, para o Linux
• Roteador para Stratum e, em seguida, para Core switch
• Core Switch to Stratum, depois para o roteador

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

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

    

Answer 5

O tempo varia em todo o lugar nas VMs. Você realmente quer ter certeza de que o servidor NTP não está usando o relógio local em nenhuma instrução 'servidor', pois o relógio local é muito pouco confiável. Uma coisa que fiz para ajudar é definir o atributo "maxpoll" para servidores em máquinas com VM. Isso força o serviço ntp a verificar com seus clocks upstream muito mais frequentemente do que o padrão configurado, o que ajuda a mantê-lo verdadeiro.

server [timeserver] maxpoll 12

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

    

Answer 6

Isso pode parecer engraçado, mas aposto que você está executando uma configuração com vários processadores? Há problemas conhecidos de desvio do relógio com certos fabricantes tosse AMD tosse que acontece com placas-mãe multi-core / multi-socket. Uma atividade pesada de interrupção - como, digamos, executar uma máquina virtual ou duas - piora a tendência. O drift que você está experimentando soa muito suspeito desse jeito.

Por que vale a pena, eu prefiro as ofertas da AMD sobre a Intel, então não tome isso como uma pancada contra eles.

    

Answer 7

Supondo que o AD1 era um controlador de domínio, acho que o problema aqui pode estar relacionado ao momento em que seu servidor Hyper-V definiu seu tempo a partir 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 compelido a sincronizar seu relógio com um controlador de domínio do Windows.